fix(ios): static SQLCipher pods, strip system SQLite, refresh deps

- Podfile: use static frameworks; post_install/post_integrate hooks to
  avoid mixing Apple libsqlite3/SQLite headers with SQLCipher (including
  stripping aggregate Pods-App xcconfig flags for Swift explicit modules).
- Xcode: enable CLANG_ENABLE_MODULES; replace CocoaPods “Embed Pods
  Frameworks” phase with “Copy Pods Resources”; minor project file hygiene.
- Pods: SQLCipher 4.10.0, ZIPFoundation patch bump; Podfile.lock updated.
- package.json: allow patch updates for @capacitor-community/sqlite (^6.0.2);
  regenerate package-lock.json.
- Info.plist: reorder keys only (same URL scheme, background modes, BG tasks,
  notification alert style).

.cursor-markdown-rules.md

@@ -181,26 +181,26 @@ Brief description of the document's purpose and scope.
 ### Check Single File
 
 ```bash
-npx markdownlint docs/filename.md
+npx markdownlint doc/filename.md
 ```
 
 ### Check All Documentation
 
 ```bash
-npx markdownlint docs/
+npx markdownlint doc/
 ```
 
 ### Auto-fix Common Issues
 
 ```bash
 # Remove trailing spaces
-sed -i 's/[[:space:]]*$//' docs/filename.md
+sed -i 's/[[:space:]]*$//' doc/filename.md
 
 # Remove multiple blank lines
-sed -i '/^$/N;/^\n$/D' docs/filename.md
+sed -i '/^$/N;/^\n$/D' doc/filename.md
 
 # Add newline at end if missing
-echo "" >> docs/filename.md
+echo "" >> doc/filename.md
 ```
 
 ## Common Patterns

.cursor/rules/README.md

@@ -269,7 +269,7 @@ The workflow system integrates seamlessly with existing development practices:
    your task
 4. **Meta-Rules**: Use workflow-specific meta-rules for specialized tasks
    - **Documentation**: Use `meta_documentation.mdc` for all documentation work
-   - **Getting Started**: See `docs/meta_rule_usage_guide.md` for comprehensive usage instructions
+   - **Getting Started**: See `doc/meta_rule_usage_guide.md` for comprehensive usage instructions
 5. **Cross-References**: All files contain updated cross-references to
    reflect the new structure
 6. **Validation**: All files pass markdown validation and maintain

.cursor/rules/app/timesafari_platforms.mdc

@@ -122,11 +122,11 @@ npm run lint-fix
 
 ## Resources
 
-- **Testing**: `docs/migration-testing/`
+- **Testing**: `doc/migration-testing/`
 
-- **Architecture**: `docs/architecture-decisions.md`
+- **Architecture**: `doc/architecture-decisions.md`
 
-- **Build Context**: `docs/build-modernization-context.md`
+- **Build Context**: `doc/build-modernization-context.md`
 
 ---
 

.cursor/rules/development/research_diagnostic.mdc

@@ -122,9 +122,9 @@ Copy/paste and fill:
 
 - `src/...`
 
-- ADR: `docs/adr/xxxx-yy-zz-something.md`
+- ADR: `doc/adr/xxxx-yy-zz-something.md`
 
-- Design: `docs/...`
+- Design: `doc/...`
 
 ## Competence Hooks
 
@@ -230,7 +230,7 @@ Before proposing solutions, trace the actual execution path:
 
   attach during service/feature investigations
 
-- `docs/adr/**` — attach when editing ADRs
+- `doc/adr/**` — attach when editing ADRs
 
 ## Referenced Files
 

.env.development

@@ -6,10 +6,13 @@ VITE_LOG_LEVEL=debug
 # iOS doesn't like spaces in the app title.
 TIME_SAFARI_APP_TITLE="TimeSafari_Dev"
 VITE_APP_SERVER=http://localhost:8080
-# This is the claim ID for actions in the BVC project, with the JWT ID on this environment (not
-
 
+# This is the claim ID for actions in the BVC project, with the JWT ID on the environment
+# test server
 VITE_BVC_MEETUPS_PROJECT_CLAIM_ID=https://endorser.ch/entity/01HWE8FWHQ1YGP7GFZYYPS272F
+# production server
+#VITE_BVC_MEETUPS_PROJECT_CLAIM_ID=https://endorser.ch/entity/01GXYPFF7FA03NXKPYY142PY4H
+
 VITE_DEFAULT_ENDORSER_API_SERVER=http://localhost:3000
 # Using shared server by default to ease setup, which works for shared test users.
 VITE_DEFAULT_IMAGE_API_SERVER=https://test-image-api.timesafari.app

.gitignore

@@ -16,6 +16,9 @@ myenv
 .env.local
 .env.*.local
 
+# npm configuration with sensitive tokens
+.npmrc
+
 # Log filesopenssl dgst -sha256 -verify public.pem -signature <(echo -n "$signature") "$signing_input"
 npm-debug.log*
 yarn-debug.log*

.husky/_/husky.sh

@@ -1,40 +1,9 @@
+echo "husky - DEPRECATED
+
+Please remove the following two lines from $0:
+
 #!/usr/bin/env sh
-#
-# Husky Helper Script
-# This file is sourced by all Husky hooks
-#
-if [ -z "$husky_skip_init" ]; then
-  debug () {
-    if [ "$HUSKY_DEBUG" = "1" ]; then
-      echo "husky (debug) - $1"
-    fi
-  }
+. \"\$(dirname -- \"\$0\")/_/husky.sh\"
 
-  readonly hook_name="$(basename -- "$0")"
-  debug "starting $hook_name..."
-
-  if [ "$HUSKY" = "0" ]; then
-    debug "HUSKY env variable is set to 0, skipping hook"
-    exit 0
-  fi
-
-  if [ -f ~/.huskyrc ]; then
-    debug "sourcing ~/.huskyrc"
-    . ~/.huskyrc
-  fi
-
-  readonly husky_skip_init=1
-  export husky_skip_init
-  sh -e "$0" "$@"
-  exitCode="$?"
-
-  if [ $exitCode != 0 ]; then
-    echo "husky - $hook_name hook exited with code $exitCode (error)"
-  fi
-
-  if [ $exitCode = 127 ]; then
-    echo "husky - command not found in PATH=$PATH"
-  fi
-
-  exit $exitCode
-fi
+They WILL FAIL in v10.0.0
+"

.npmrc

@@ -1 +0,0 @@
-@jsr:registry=https://npm.jsr.io

BUILDING.md

@@ -196,7 +196,7 @@ cp .env.example .env.development
 
 - Node.js 18+ and npm
 - Git
-- For mobile builds: Xcode (macOS) or Android Studio
+- For mobile builds: Xcode (macOS) or Android Studio (or Android SDK Command Line Tools for Android emulator only; see [Android Emulator Without Android Studio](#android-emulator-without-android-studio-command-line-only))
 - For desktop builds: Additional build tools based on your OS
 
 ## Forks
@@ -366,7 +366,7 @@ rsync -azvu -e "ssh -i ~/.ssh/..." dist ubuntutest@test.timesafari.app:time-safa
 
 - For prod, you can do the same with `build:web:prod` instead.
 
-... or log onto the server (though the build step can stay on "rendering chunks" for a long while):
+Here are instructions directly on the server, but the build step can stay on "rendering chunks" for a long time and it basically hangs any other access to the server. In fact, last time it was killed: "Failed after 482 seconds (exit code: 137)" Maybe use `nice`?
 
 - `pkgx +npm sh`
 
@@ -376,7 +376,7 @@ rsync -azvu -e "ssh -i ~/.ssh/..." dist ubuntutest@test.timesafari.app:time-safa
 
 - Back up the time-safari/dist folder & deploy: `mv time-safari/dist time-safari-dist-prev-2 && mv crowd-funder-for-time-pwa/dist time-safari/`
 
-- Record the new hash in the changelog. Edit package.json to increment version &
+Be sure to record the new hash in the changelog. Edit package.json to increment version &
 add "-beta", `npm install`, commit, and push. Also record what version is on production.
 
 ## Docker Deployment
@@ -1047,7 +1047,7 @@ npx cap sync electron
 - Package integrity verification
 - Rollback capabilities
 
-For detailed documentation, see [docs/electron-build-patterns.md](docs/electron-build-patterns.md).
+For detailed documentation, see [doc/electron-build-patterns.md](doc/electron-build-patterns.md).
 
 ## Mobile Builds (Capacitor)
 
@@ -1140,7 +1140,7 @@ export GEM_PATH=$shortened_path
 ##### 1. Bump the version in package.json & CHANGELOG.md for `MARKETING_VERSION`, then `grep CURRENT_PROJECT_VERSION ios/App/App.xcodeproj/project.pbxproj` and add 1 for the numbered version here:
 
 ```bash
-cd ios/App && xcrun agvtool new-version 50 && perl -p -i -e "s/MARKETING_VERSION = .*;/MARKETING_VERSION = 1.1.5;/g" App.xcodeproj/project.pbxproj && cd -
+cd ios/App && xcrun agvtool new-version 65 && perl -p -i -e "s/MARKETING_VERSION = .*;/MARKETING_VERSION = 1.3.8;/g" App.xcodeproj/project.pbxproj && cd -
 # Unfortunately this edits Info.plist directly.
 #xcrun agvtool new-marketing-version 0.4.5
 ```
@@ -1181,7 +1181,128 @@ npm run build:ios:prod
 
 ### Android Build
 
-Prerequisites: Android Studio with Java SDK installed
+Prerequisites: Android Studio with Java SDK installed (or **Android SDK Command Line Tools** only — see [Android Emulator Without Android Studio](#android-emulator-without-android-studio-command-line-only) below).
+
+#### Android Emulator Without Android Studio (Command-Line Only)
+
+You can build and run the app on an Android emulator using only the **Android SDK Command Line Tools** (no Android Studio). The project uses **API 36** (see `android/variables.gradle`: `compileSdkVersion` / `targetSdkVersion`).
+
+##### 1. Environment
+
+Set your SDK location and PATH (e.g. in `~/.zshrc` or `~/.bashrc`):
+
+```bash
+# macOS default SDK location
+export ANDROID_HOME=$HOME/Library/Android/sdk
+# or: export ANDROID_HOME=$HOME/Android/Sdk
+
+export PATH=$PATH:$ANDROID_HOME/emulator
+export PATH=$PATH:$ANDROID_HOME/platform-tools
+export PATH=$PATH:$ANDROID_HOME/cmdline-tools/latest/bin
+export PATH=$PATH:$ANDROID_HOME/build-tools/34.0.0
+```
+
+Reload your shell (e.g. `source ~/.zshrc`), then verify:
+
+```bash
+adb version
+emulator -version
+avdmanager list
+```
+
+##### 2. Install SDK components
+
+Install platform tools, build tools, platform, and emulator:
+
+```bash
+sdkmanager "platform-tools"
+sdkmanager "build-tools;34.0.0"
+sdkmanager "platforms;android-36"
+sdkmanager "emulator"
+```
+
+##### 3. Install system image and create AVD
+
+**Mac Silicon (Apple M1/M2/M3)** — use **ARM64** for native performance:
+
+```bash
+# System image (API 36 matches the project)
+sdkmanager "system-images;android-36;google_apis;arm64-v8a"
+
+# Create AVD
+avdmanager create avd \
+  --name "TimeSafari_Emulator" \
+  --package "system-images;android-36;google_apis;arm64-v8a" \
+  --device "pixel_7"
+```
+
+**Intel Mac (x86_64):**
+
+```bash
+sdkmanager "system-images;android-36;google_apis;x86_64"
+
+avdmanager create avd \
+  --name "TimeSafari_Emulator" \
+  --package "system-images;android-36;google_apis;x86_64" \
+  --device "pixel_7"
+```
+
+List AVDs: `avdmanager list avd`
+
+##### 4. Start the emulator
+
+```bash
+# Start in background (Mac Silicon or Intel)
+emulator -avd TimeSafari_Emulator -gpu host -no-audio &
+
+# Optional: wait until booted
+adb wait-for-device
+while [ "$(adb shell getprop sys.boot_completed 2>/dev/null)" != "1" ]; do sleep 2; done
+```
+
+If you have limited RAM, use reduced resources:
+
+```bash
+emulator -avd TimeSafari_Emulator -no-audio -memory 2048 -cores 2 -gpu swiftshader_indirect &
+```
+
+Check device: `adb devices`
+
+##### 5. Build the app
+
+From the project root:
+
+```bash
+npm run build:android
+# or: npm run build:android:debug
+```
+
+The debug APK is produced at:  
+`android/app/build/outputs/apk/debug/app-debug.apk`
+
+##### 6. Install and launch on the emulator
+
+With the emulator running:
+
+```bash
+adb install -r android/app/build/outputs/apk/debug/app-debug.apk
+adb shell am start -n app.timesafari.app/app.timesafari.MainActivity
+```
+
+##### One-shot build and run
+
+To build and run in one go (emulator or device must already be running):
+
+```bash
+npm run build:android:debug:run   # debug build, install, launch
+# or
+npm run build:android:test:run   # test env build, install, launch
+```
+
+##### Reference
+
+- Emulator troubleshooting and options: [doc/android-emulator-deployment-guide.md](doc/android-emulator-deployment-guide.md)
+- **Physical device testing**: [doc/android-physical-device-guide.md](doc/android-physical-device-guide.md)
 
 #### Android Build Commands
 
@@ -1298,8 +1419,8 @@ The recommended way to build for Android is using the automated build script:
 ##### 1. Bump the version in package.json, then update these versions & run:
 
 ```bash
-perl -p -i -e 's/versionCode .*/versionCode 50/g' android/app/build.gradle
-perl -p -i -e 's/versionName .*/versionName "1.1.5"/g' android/app/build.gradle
+perl -p -i -e 's/versionCode .*/versionCode 66/g' android/app/build.gradle
+perl -p -i -e 's/versionName .*/versionName "1.4.1"/g' android/app/build.gradle
 ```
 
 ##### 2. Build
@@ -1688,11 +1809,13 @@ npm run build:android:assets
 
 ## Additional Resources
 
-- [Electron Build Patterns](docs/electron-build-patterns.md)
-- [iOS Build Scripts](docs/ios-build-scripts.md)
-- [Android Build Scripts](docs/android-build-scripts.md)
-- [Web Build Scripts](docs/web-build-scripts.md)
-- [Build Troubleshooting](docs/build-troubleshooting.md)
+- [Electron Build Patterns](doc/electron-build-patterns.md)
+- [iOS Build Scripts](doc/ios-build-scripts.md)
+- [Android Build Scripts](doc/android-build-scripts.md)
+- [Android Physical Device Guide](doc/android-physical-device-guide.md)
+- [Android Emulator Deployment Guide](doc/android-emulator-deployment-guide.md)
+- [Web Build Scripts](doc/web-build-scripts.md)
+- [Build Troubleshooting](doc/build-troubleshooting.md)
 
 ---
 
@@ -2315,7 +2438,7 @@ export async function createBuildConfig(platform: string): Promise<UserConfig> {
     resolve: {
       alias: {
         '@': path.resolve(__dirname, 'src'),
-        '@nostr/tools': path.resolve(__dirname, 'node_modules/@nostr/tools'),
+        'nostr-tools': path.resolve(__dirname, 'node_modules/nostr-tools'),
         'path': path.resolve(__dirname, './src/utils/node-modules/path.js'),
         'fs': path.resolve(__dirname, './src/utils/node-modules/fs.js'),
         'crypto': path.resolve(__dirname, './src/utils/node-modules/crypto.js'),
@@ -2324,7 +2447,7 @@ export async function createBuildConfig(platform: string): Promise<UserConfig> {
     },
     optimizeDeps: {
       include: [
-        '@nostr/tools',
+        'nostr-tools',
         '@jlongster/sql.js',
         'absurd-sql',
         // ... additional dependencies
@@ -2349,7 +2472,7 @@ export async function createBuildConfig(platform: string): Promise<UserConfig> {
 **Path Aliases**:
 
 - `@`: Points to `src/` directory
-- `@nostr/tools`: Nostr tools library
+- `nostr-tools`: Nostr tools library
 - `path`, `fs`, `crypto`: Node.js polyfills for browser
 
 ### B.2 vite.config.web.mts
@@ -2489,7 +2612,7 @@ export default defineConfig(async () => {
         output: {
           manualChunks: {
             vendor: ["vue", "vue-router", "@vueuse/core"],
-            crypto: ["@nostr/tools", "crypto-js"],
+            crypto: ["nostr-tools", "crypto-js"],
             ui: ["@fortawesome/vue-fontawesome"]
           }
         }

CHANGELOG.md

@@ -6,6 +6,44 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
 and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
 
+## [1.3.8] - 2026
+### Added
+- Device wake-up for notifications
+
+
+## [1.3.7]
+### Added
+- Attendee exclusion and do-not-pair groups for meeting matching.
+### Fixed
+- Contact deep-links clicked or pasted act consistenly
+
+
+## [1.3.5] - 2026.02.22
+### Fixed
+- SQL error on startup (contact_labels -> contacts foreign key)
+### Added
+- Ability to toggle embeddings on list of contacts
+
+
+## [1.3.3] - 2026.02.17
+### Added
+- People can be marked as vector-embeddings users.
+- People can be matched during a meeting.
+### Fixed
+- Problem hiding new contacts in feed
+
+
+## [1.1.6] - 2026.01.21
+### Added
+- Labels on contacts
+- Ability to switch giver & recipient on the gift-details page
+### Changed
+- Invitations now must be explicitly accepted.
+### Fixed
+- Show all starred projects.
+- Incorrect contacts as "most recent" on gift-details page
+
+
 ## [1.1.5] - 2025.12.28
 ### Fixed
 - Incorrect prompts in give-dialog on a project or offer

CODE_QUALITY_DEEP_ANALYSIS.md

@@ -27,7 +27,7 @@ Large Components (>500 lines): 5 components (12.5%)
 ├── GiftedDialog.vue (670 lines) ⚠️ HIGH PRIORITY  
 ├── PhotoDialog.vue (669 lines) ⚠️ HIGH PRIORITY
 ├── PushNotificationPermission.vue (660 lines) ⚠️ HIGH PRIORITY
-└── MembersList.vue (550 lines) ⚠️ MODERATE PRIORITY
+└── MeetingMembersList.vue (550 lines) ⚠️ MODERATE PRIORITY
 
 Medium Components (200-500 lines): 12 components (30%)
 ├── GiftDetailsStep.vue (450 lines)

README.md

@@ -15,10 +15,31 @@ Quick start:
 
 ```bash
 npm install
-npm run build:web:serve -- --test
 ```
 
-To be able to take action on the platform: go to [the test page](http://localhost:8080/test) and click "Become User 0".
+### Web
+
+```bash
+npm run build:web:dev
+```
+
+Then go to [the test page](http://localhost:8080/test) and click "Become User 0" to take action on the platform.
+
+### Android
+
+```bash
+npm run build:android:test:run
+```
+
+Assumes ADB is installed; see [Android Build](BUILDING.md#android-build) for SDK, emulator, and `PATH` setup.
+
+### iOS
+
+```bash
+npm run build:ios:studio
+```
+
+Assumes Xcode and Xcode Command Line Tools are installed.
 
 See [BUILDING.md](BUILDING.md) for comprehensive build instructions for all platforms (Web, Electron, iOS, Android, Docker).
 

android/app/build.gradle

@@ -27,12 +27,18 @@ if (!project.ext.MY_KEYSTORE_FILE) {
 android {
     namespace 'app.timesafari'
     compileSdk rootProject.ext.compileSdkVersion
+
+    compileOptions {
+        sourceCompatibility JavaVersion.VERSION_17
+        targetCompatibility JavaVersion.VERSION_17
+    }
+
     defaultConfig {
         applicationId "app.timesafari.app"
         minSdkVersion rootProject.ext.minSdkVersion
         targetSdkVersion rootProject.ext.targetSdkVersion
-        versionCode 50
-        versionName "1.1.5"
+        versionCode 66
+        versionName "1.4.1"
         testInstrumentationRunner "androidx.test.runner.AndroidJUnitRunner"
         aaptOptions {
              // Files and dirs to omit from the packaged assets dir, modified to accommodate modern web apps.
@@ -101,6 +107,20 @@ dependencies {
     implementation project(':capacitor-android')
     implementation project(':capacitor-community-sqlite')
     implementation "androidx.biometric:biometric:1.2.0-alpha05"
+
+    // Daily Notification Plugin dependencies
+    implementation "androidx.room:room-runtime:2.6.1"
+    implementation "androidx.work:work-runtime-ktx:2.9.0"
+    implementation "org.jetbrains.kotlinx:kotlinx-coroutines-android:1.7.3"
+    annotationProcessor "androidx.room:room-compiler:2.6.1"
+
+    // Capacitor annotation processor for automatic plugin discovery
+    annotationProcessor project(':capacitor-android')
+
+    // Additional dependencies for notification plugin
+    implementation 'androidx.lifecycle:lifecycle-service:2.7.0'
+    implementation 'com.google.code.gson:gson:2.10.1'
+
     testImplementation "junit:junit:$junitVersion"
     androidTestImplementation "androidx.test.ext:junit:$androidxJunitVersion"
     androidTestImplementation "androidx.test.espresso:espresso-core:$androidxEspressoCoreVersion"

android/app/capacitor.build.gradle

@@ -18,6 +18,7 @@ dependencies {
     implementation project(':capacitor-share')
     implementation project(':capacitor-status-bar')
     implementation project(':capawesome-capacitor-file-picker')
+    implementation project(':timesafari-daily-notification-plugin')
 
 }
 

android/app/src/main/AndroidManifest.xml

@@ -1,10 +1,12 @@
 <?xml version="1.0" encoding="utf-8" ?>
 <manifest xmlns:android="http://schemas.android.com/apk/res/android">
     <application
+        android:name=".TimeSafariApplication"
         android:allowBackup="true"
         android:icon="@mipmap/ic_launcher"
         android:label="@string/app_name"
         android:roundIcon="@mipmap/ic_launcher_round"
+        android:networkSecurityConfig="@xml/network_security_config"
         android:supportsRtl="true"
         android:theme="@style/AppTheme">
         <activity
@@ -43,6 +45,43 @@
             </intent-filter>
         </activity>
 
+        <!-- Daily Notification Plugin Receivers (must be inside application) -->
+        <!-- DailyNotificationReceiver: Handles alarm-triggered notifications -->
+        <!-- Note: exported="true" allows AlarmManager to trigger this receiver -->
+        <receiver
+            android:name="org.timesafari.dailynotification.DailyNotificationReceiver"
+            android:enabled="true"
+            android:exported="false">
+            <intent-filter>
+                <action android:name="org.timesafari.daily.NOTIFICATION" />
+            </intent-filter>
+        </receiver>
+
+        <!-- NotifyReceiver: Handles notification delivery -->
+        <receiver
+            android:name="org.timesafari.dailynotification.NotifyReceiver"
+            android:enabled="true"
+            android:exported="false"
+        />
+
+        <!-- BootReceiver: reschedule daily notification after device restart.
+             Two intent-filters: BOOT_COMPLETED has no Uri, so must not share a filter with <data scheme="package"/> or the boot broadcast never matches. -->
+        <receiver
+            android:name="org.timesafari.dailynotification.BootReceiver"
+            android:enabled="true"
+            android:exported="true"
+            android:directBootAware="true">
+            <intent-filter android:priority="1000">
+                <action android:name="android.intent.action.LOCKED_BOOT_COMPLETED" />
+                <action android:name="android.intent.action.BOOT_COMPLETED" />
+            </intent-filter>
+            <intent-filter android:priority="1000">
+                <action android:name="android.intent.action.MY_PACKAGE_REPLACED" />
+                <action android:name="android.intent.action.PACKAGE_REPLACED" />
+                <data android:scheme="package" />
+            </intent-filter>
+        </receiver>
+
         <provider
             android:name="androidx.core.content.FileProvider"
             android:authorities="${applicationId}.fileprovider"
@@ -59,4 +98,14 @@
     <uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" />
     <uses-permission android:name="android.permission.CAMERA" />
     <uses-feature android:name="android.hardware.camera" android:required="true" />
+
+    <!-- Daily Notification Plugin Permissions -->
+    <uses-permission android:name="android.permission.POST_NOTIFICATIONS" />
+    <uses-permission android:name="android.permission.SCHEDULE_EXACT_ALARM" />
+    <uses-permission android:name="android.permission.RECEIVE_BOOT_COMPLETED" />
+    <uses-permission android:name="android.permission.WAKE_LOCK" />
+    <uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" />
+    <uses-permission android:name="android.permission.FOREGROUND_SERVICE" />
+    <uses-permission android:name="android.permission.SYSTEM_ALERT_WINDOW" />
+    <uses-permission android:name="android.permission.REQUEST_IGNORE_BATTERY_OPTIMIZATIONS" />
 </manifest>

android/app/src/main/assets/capacitor.config.json

@@ -42,6 +42,31 @@
 				"biometricTitle": "Biometric login for TimeSafari"
 			},
 			"electronIsEncryption": false
+		},
+		"DailyNotification": {
+			"debugMode": true,
+			"enableNotifications": true,
+			"timesafariConfig": {
+				"activeDid": "",
+				"endpoints": {
+					"projectsLastUpdated": "https://api.endorser.ch/api/v2/report/plansLastUpdatedBetween"
+				},
+				"starredProjectsConfig": {
+					"enabled": true,
+					"starredPlanHandleIds": [],
+					"fetchInterval": "0 8 * * *"
+				}
+			},
+			"networkConfig": {
+				"timeout": 30000,
+				"retryAttempts": 3,
+				"retryDelay": 1000
+			},
+			"contentFetch": {
+				"enabled": true,
+				"schedule": "0 8 * * *",
+				"fetchLeadTimeMinutes": 5
+			}
 		}
 	},
 	"ios": {

android/app/src/main/assets/capacitor.plugins.json

@@ -35,6 +35,10 @@
 		"pkg": "@capawesome/capacitor-file-picker",
 		"classpath": "io.capawesome.capacitorjs.plugins.filepicker.FilePickerPlugin"
 	},
+	{
+		"pkg": "@timesafari/daily-notification-plugin",
+		"classpath": "org.timesafari.dailynotification.DailyNotificationPlugin"
+	},
 	{
 		"pkg": "SafeArea",
 		"classpath": "app.timesafari.safearea.SafeAreaPlugin"

android/app/src/main/java/app/timesafari/MainActivity.java

@@ -67,6 +67,14 @@ public class MainActivity extends BridgeActivity {
         // Register SharedImage plugin
         registerPlugin(SharedImagePlugin.class);
         
+        // Register DailyNotification plugin
+        // Plugin is written in Kotlin but compiles to Java-compatible bytecode
+        registerPlugin(org.timesafari.dailynotification.DailyNotificationPlugin.class);
+
+        // Register native content fetcher for API-driven daily notifications (Endorser.ch)
+        org.timesafari.dailynotification.DailyNotificationPlugin.setNativeFetcher(
+            new TimeSafariNativeFetcher(this));
+        
         // Initialize SQLite
         //registerPlugin(SQLite.class);
         

android/app/src/main/java/app/timesafari/TimeSafariApplication.java

@@ -0,0 +1,27 @@
+package app.timesafari;
+
+import android.app.Application;
+import android.content.Context;
+import android.util.Log;
+import org.timesafari.dailynotification.DailyNotificationPlugin;
+import org.timesafari.dailynotification.NativeNotificationContentFetcher;
+
+public class TimeSafariApplication extends Application {
+
+    private static final String TAG = "TimeSafariApplication";
+
+    @Override
+    public void onCreate() {
+        super.onCreate();
+
+        Log.i(TAG, "Initializing TimeSafari notifications");
+
+        // Register native fetcher with application context
+        Context context = getApplicationContext();
+        NativeNotificationContentFetcher fetcher =
+            new TimeSafariNativeFetcher(context);
+        DailyNotificationPlugin.setNativeFetcher(fetcher);
+
+        Log.i(TAG, "Native fetcher registered");
+    }
+}

android/app/src/main/java/app/timesafari/TimeSafariNativeFetcher.java

@@ -0,0 +1,395 @@
+package app.timesafari;
+
+import android.content.Context;
+import android.content.SharedPreferences;
+import android.util.Log;
+
+import androidx.annotation.NonNull;
+import androidx.annotation.Nullable;
+
+import com.google.gson.Gson;
+import com.google.gson.JsonArray;
+import com.google.gson.JsonObject;
+import com.google.gson.JsonParser;
+
+import org.timesafari.dailynotification.FetchContext;
+import org.timesafari.dailynotification.NativeNotificationContentFetcher;
+import org.timesafari.dailynotification.NotificationContent;
+
+import java.io.BufferedReader;
+import java.io.IOException;
+import java.io.InputStream;
+import java.io.InputStreamReader;
+import java.io.OutputStream;
+import java.net.HttpURLConnection;
+import java.net.URL;
+import java.nio.charset.StandardCharsets;
+import java.util.ArrayList;
+import java.util.Collections;
+import java.util.HashMap;
+import java.util.List;
+import java.util.Map;
+import java.util.concurrent.CompletableFuture;
+
+/**
+ * Native content fetcher for API-driven daily notifications.
+ * Calls Endorser.ch plansLastUpdatedBetween with configured credentials and
+ * starred plan IDs (from plugin's updateStarredPlans), then returns notification content.
+ */
+public class TimeSafariNativeFetcher implements NativeNotificationContentFetcher {
+
+    private static final String TAG = "TimeSafariNativeFetcher";
+    private static final String ENDORSER_ENDPOINT = "/api/v2/report/plansLastUpdatedBetween";
+    private static final int CONNECT_TIMEOUT_MS = 10000;
+    private static final int READ_TIMEOUT_MS = 15000;
+    private static final int MAX_RETRIES = 3;
+    /** Max chars of response body logged at DEBUG (avoids huge log lines). */
+    private static final int MAX_RESPONSE_BODY_LOG_CHARS = 4096;
+    private static final int RETRY_DELAY_MS = 1000;
+
+    // Must match plugin's SharedPreferences name and keys (DailyNotificationPlugin / TimeSafariIntegrationManager)
+    private static final String PREFS_NAME = "daily_notification_timesafari";
+    private static final String KEY_STARRED_PLAN_IDS = "starredPlanIds";
+    private static final String KEY_LAST_ACKED_JWT_ID = "last_acked_jwt_id";
+
+    private final Gson gson = new Gson();
+    private final Context appContext;
+    private final SharedPreferences prefs;
+
+    private volatile String apiBaseUrl;
+    private volatile String activeDid;
+    private volatile String jwtToken;
+    /** Distinct JWTs from configureNativeFetcher `jwtTokens`; null = use jwtToken only. */
+    @Nullable
+    private List<String> jwtTokenPool;
+
+    public TimeSafariNativeFetcher(Context context) {
+        this.appContext = context.getApplicationContext();
+        this.prefs = appContext.getSharedPreferences(PREFS_NAME, Context.MODE_PRIVATE);
+    }
+
+    @Override
+    public void configure(String apiBaseUrl, String activeDid, String jwtToken) {
+        configure(apiBaseUrl, activeDid, jwtToken, null);
+    }
+
+    @Override
+    public void configure(
+            String apiBaseUrl,
+            String activeDid,
+            String jwtToken,
+            @Nullable List<String> jwtTokenPool) {
+        this.apiBaseUrl = apiBaseUrl;
+        this.activeDid = activeDid;
+        this.jwtToken = jwtToken;
+        this.jwtTokenPool =
+                jwtTokenPool != null && !jwtTokenPool.isEmpty()
+                        ? new ArrayList<>(jwtTokenPool)
+                        : null;
+        int starredCount = getStarredPlanIds().size();
+        Log.i(
+                TAG,
+                "Configured with API: "
+                        + apiBaseUrl
+                        + ", starredPlanIds count="
+                        + starredCount
+                        + (this.jwtTokenPool != null
+                                ? ", jwtPoolSize=" + this.jwtTokenPool.size()
+                                : ""));
+    }
+
+    /** One pool entry per UTC day (epoch day mod pool size); else primary jwtToken. */
+    private String selectBearerTokenForRequest() {
+        List<String> pool = jwtTokenPool;
+        if (pool == null || pool.isEmpty()) {
+            return jwtToken;
+        }
+        long epochDay = System.currentTimeMillis() / (24L * 60 * 60 * 1000);
+        int idx = (int) (epochDay % pool.size());
+        String t = pool.get(idx);
+        if (t == null || t.isEmpty()) {
+            return jwtToken;
+        }
+        Log.i(TAG, "Bearer from JWT pool: index=" + idx + " of " + pool.size());
+        return t;
+    }
+
+    @NonNull
+    @Override
+    public CompletableFuture<List<NotificationContent>> fetchContent(@NonNull FetchContext fetchContext) {
+        Long scheduled = fetchContext.scheduledTime;
+        Log.i(
+                TAG,
+                "fetchContent START trigger="
+                        + fetchContext.trigger
+                        + " scheduledTime="
+                        + (scheduled != null ? scheduled : "null")
+                        + " callerThread="
+                        + Thread.currentThread().getName());
+        Log.d(TAG, "Fetching notification content, trigger: " + fetchContext.trigger);
+        return fetchContentWithRetry(fetchContext, 0);
+    }
+
+    private CompletableFuture<List<NotificationContent>> fetchContentWithRetry(
+            @NonNull FetchContext context, int retryCount) {
+        return CompletableFuture.supplyAsync(() -> {
+            try {
+                Log.i(TAG, "fetchContent worker thread=" + Thread.currentThread().getName());
+                String bearer = selectBearerTokenForRequest();
+                if (apiBaseUrl == null || activeDid == null || bearer == null || bearer.isEmpty()) {
+                    Log.e(TAG, "Not configured. Call configureNativeFetcher() from TypeScript first.");
+                    return Collections.emptyList();
+                }
+
+                String urlString = apiBaseUrl + ENDORSER_ENDPOINT;
+                URL url = new URL(urlString);
+                HttpURLConnection connection = (HttpURLConnection) url.openConnection();
+                connection.setConnectTimeout(CONNECT_TIMEOUT_MS);
+                connection.setReadTimeout(READ_TIMEOUT_MS);
+                connection.setRequestMethod("POST");
+                connection.setRequestProperty("Content-Type", "application/json");
+                connection.setRequestProperty("Authorization", "Bearer " + bearer);
+                connection.setDoOutput(true);
+
+                Map<String, Object> requestBody = new HashMap<>();
+                List<String> planIds = getStarredPlanIds();
+                requestBody.put("planIds", planIds);
+                String afterId = getLastAcknowledgedJwtId();
+                if (afterId == null || afterId.isEmpty()) {
+                    afterId = "0";
+                }
+                requestBody.put("afterId", afterId);
+                Log.i(
+                        TAG,
+                        "POST "
+                                + ENDORSER_ENDPOINT
+                                + " planCount="
+                                + planIds.size()
+                                + " afterId="
+                                + (afterId.length() > 12 ? afterId.substring(0, 12) + "…" : afterId));
+
+                String jsonBody = gson.toJson(requestBody);
+                try (OutputStream os = connection.getOutputStream()) {
+                    byte[] input = jsonBody.getBytes(StandardCharsets.UTF_8);
+                    os.write(input, 0, input.length);
+                }
+
+                int responseCode = connection.getResponseCode();
+                Log.i(TAG, "HTTP response code: " + responseCode);
+
+                if (responseCode == 200) {
+                    StringBuilder response = new StringBuilder();
+                    try (BufferedReader reader = new BufferedReader(
+                            new InputStreamReader(connection.getInputStream(), StandardCharsets.UTF_8))) {
+                        String line;
+                        while ((line = reader.readLine()) != null) {
+                            response.append(line);
+                        }
+                    }
+                    String responseBody = response.toString();
+                    String snippet =
+                            responseBody.length() <= MAX_RESPONSE_BODY_LOG_CHARS
+                                    ? responseBody
+                                    : responseBody.substring(0, MAX_RESPONSE_BODY_LOG_CHARS) + "…";
+                    Log.d(
+                            TAG,
+                            "plansLastUpdatedBetween response len="
+                                    + responseBody.length()
+                                    + " body="
+                                    + snippet);
+                    List<NotificationContent> contents = parseApiResponse(responseBody, context);
+                    if (!contents.isEmpty()) {
+                        updateLastAckedJwtIdFromResponse(responseBody);
+                    }
+                    Log.i(TAG, "Fetched " + contents.size() + " notification(s)");
+                    return contents;
+                }
+
+                if (retryCount < MAX_RETRIES && (responseCode >= 500 || responseCode == 429)) {
+                    int delayMs = RETRY_DELAY_MS * (1 << retryCount);
+                    String errBody = readHttpErrorBodySnippet(connection);
+                    Log.w(
+                            TAG,
+                            "Retryable error "
+                                    + responseCode
+                                    + (errBody.isEmpty() ? "" : " body: " + errBody)
+                                    + ", retrying in "
+                                    + delayMs
+                                    + "ms");
+                    try {
+                        Thread.sleep(delayMs);
+                    } catch (InterruptedException e) {
+                        Thread.currentThread().interrupt();
+                        return Collections.emptyList();
+                    }
+                    return fetchContentWithRetry(context, retryCount + 1).join();
+                }
+
+                String errBody = readHttpErrorBodySnippet(connection);
+                if (errBody.isEmpty()) {
+                    Log.e(TAG, "API error " + responseCode);
+                } else {
+                    Log.e(TAG, "API error " + responseCode + " body: " + errBody);
+                }
+                return Collections.emptyList();
+            } catch (Exception e) {
+                Log.e(TAG, "Fetch failed", e);
+                if (retryCount < MAX_RETRIES) {
+                    try {
+                        Thread.sleep(RETRY_DELAY_MS * (1 << retryCount));
+                    } catch (InterruptedException ie) {
+                        Thread.currentThread().interrupt();
+                        return Collections.emptyList();
+                    }
+                    return fetchContentWithRetry(context, retryCount + 1).join();
+                }
+                return Collections.emptyList();
+            }
+        });
+    }
+
+    /**
+     * Reads error response body for logging (HttpURLConnection puts 4xx/5xx bodies on
+     * {@link HttpURLConnection#getErrorStream()}).
+     */
+    private static String readHttpErrorBodySnippet(HttpURLConnection connection) {
+        InputStream stream = connection.getErrorStream();
+        if (stream == null) {
+            return "";
+        }
+        final int maxChars = 4096;
+        try (BufferedReader reader =
+                new BufferedReader(new InputStreamReader(stream, StandardCharsets.UTF_8))) {
+            StringBuilder sb = new StringBuilder();
+            String line;
+            while ((line = reader.readLine()) != null) {
+                if (sb.length() > 0) {
+                    sb.append('\n');
+                }
+                if (sb.length() + line.length() > maxChars) {
+                    sb.append(line, 0, Math.max(0, maxChars - sb.length()));
+                    sb.append("…");
+                    break;
+                }
+                sb.append(line);
+            }
+            return sb.toString().trim();
+        } catch (IOException e) {
+            return "(read error body failed: " + e.getMessage() + ")";
+        }
+    }
+
+    private List<String> getStarredPlanIds() {
+        try {
+            String idsJson = prefs.getString(KEY_STARRED_PLAN_IDS, "[]");
+            if (idsJson == null || idsJson.isEmpty() || "[]".equals(idsJson)) {
+                return new ArrayList<>();
+            }
+            JsonArray arr = JsonParser.parseString(idsJson).getAsJsonArray();
+            List<String> list = new ArrayList<>();
+            for (int i = 0; i < arr.size(); i++) {
+                list.add(arr.get(i).getAsString());
+            }
+            return list;
+        } catch (Exception e) {
+            Log.e(TAG, "Error loading starred plan IDs", e);
+            return new ArrayList<>();
+        }
+    }
+
+    private String getLastAcknowledgedJwtId() {
+        return prefs.getString(KEY_LAST_ACKED_JWT_ID, null);
+    }
+
+    private void updateLastAckedJwtIdFromResponse(String responseBody) {
+        try {
+            JsonObject root = JsonParser.parseString(responseBody).getAsJsonObject();
+            if (!root.has("data")) return;
+            JsonArray dataArray = root.getAsJsonArray("data");
+            if (dataArray == null || dataArray.size() == 0) return;
+            JsonObject lastItem = dataArray.get(dataArray.size() - 1).getAsJsonObject();
+            String jwtId = null;
+            if (lastItem.has("jwtId")) {
+                jwtId = lastItem.get("jwtId").getAsString();
+            } else if (lastItem.has("plan")) {
+                JsonObject plan = lastItem.getAsJsonObject("plan");
+                if (plan.has("jwtId")) {
+                    jwtId = plan.get("jwtId").getAsString();
+                }
+            }
+            if (jwtId != null && !jwtId.isEmpty()) {
+                prefs.edit().putString(KEY_LAST_ACKED_JWT_ID, jwtId).apply();
+            }
+        } catch (Exception e) {
+            Log.w(TAG, "Could not extract JWT ID from response", e);
+        }
+    }
+
+    /**
+     * Display title for a plansLastUpdatedBetween row; prefers {@code plan.name}, else "Unnamed Project".
+     */
+    private String extractProjectDisplayTitle(JsonObject item) {
+        if (item.has("plan")) {
+            JsonObject plan = item.getAsJsonObject("plan");
+            if (plan.has("name") && !plan.get("name").isJsonNull()) {
+                String name = plan.get("name").getAsString();
+                if (name != null && !name.trim().isEmpty()) {
+                    return name.trim();
+                }
+            }
+        }
+        return "Unnamed Project";
+    }
+
+    @Nullable
+    private String extractJwtIdFromItem(JsonObject item) {
+        if (item.has("plan")) {
+            JsonObject plan = item.getAsJsonObject("plan");
+            if (plan.has("jwtId") && !plan.get("jwtId").isJsonNull()) {
+                return plan.get("jwtId").getAsString();
+            }
+        }
+        if (item.has("jwtId") && !item.get("jwtId").isJsonNull()) {
+            return item.get("jwtId").getAsString();
+        }
+        return null;
+    }
+
+    private List<NotificationContent> parseApiResponse(String responseBody, FetchContext context) {
+        List<NotificationContent> contents = new ArrayList<>();
+        try {
+            JsonObject root = JsonParser.parseString(responseBody).getAsJsonObject();
+            JsonArray dataArray = root.has("data") ? root.getAsJsonArray("data") : null;
+            if (dataArray == null || dataArray.size() == 0) {
+                return contents;
+            }
+
+            JsonObject firstItem = dataArray.get(0).getAsJsonObject();
+            String firstTitle = extractProjectDisplayTitle(firstItem);
+            String jwtId = extractJwtIdFromItem(firstItem);
+
+            NotificationContent content = new NotificationContent();
+            content.setId("endorser_" + (jwtId != null ? jwtId : ("batch_" + System.currentTimeMillis())));
+            int n = dataArray.size();
+            String quotedFirst = "\u201C" + firstTitle + "\u201D";
+            if (n == 1) {
+                content.setTitle("Starred Project Update");
+                content.setBody(quotedFirst + " has been updated.");
+            } else {
+                content.setTitle("Starred Project Updates");
+                int more = n - 1;
+                content.setBody(quotedFirst + " + " + more + " more have been updated.");
+            }
+            content.setScheduledTime(
+                    context.scheduledTime != null
+                            ? context.scheduledTime
+                            : (System.currentTimeMillis() + 3600000));
+            content.setPriority("default");
+            content.setSound(true);
+            contents.add(content);
+        } catch (Exception e) {
+            Log.e(TAG, "Error parsing API response", e);
+        }
+        return contents;
+    }
+}

android/app/src/main/res/xml/network_security_config.xml

@@ -0,0 +1,12 @@
+<?xml version="1.0" encoding="utf-8"?>
+<network-security-config>
+    <base-config cleartextTrafficPermitted="true">
+        <trust-anchors>
+            <certificates src="system" />
+        </trust-anchors>
+    </base-config>
+    <domain-config cleartextTrafficPermitted="true">
+        <domain includeSubdomains="true">localhost</domain>
+        <domain includeSubdomains="true">10.0.2.2</domain>
+    </domain-config>
+</network-security-config>

android/build.gradle

@@ -22,6 +22,9 @@ allprojects {
         google()
         mavenCentral()
     }
+    
+    // Note: KAPT JVM arguments for Java 17+ compatibility are configured in gradle.properties
+    // The org.gradle.jvmargs setting includes --add-opens flags needed for KAPT
 }
 
 task clean(type: Delete) {

android/capacitor.settings.gradle

@@ -28,3 +28,6 @@ project(':capacitor-status-bar').projectDir = new File('../node_modules/@capacit
 
 include ':capawesome-capacitor-file-picker'
 project(':capawesome-capacitor-file-picker').projectDir = new File('../node_modules/@capawesome/capacitor-file-picker/android')
+
+include ':timesafari-daily-notification-plugin'
+project(':timesafari-daily-notification-plugin').projectDir = new File('../node_modules/@timesafari/daily-notification-plugin/android')

android/gradle.properties

@@ -9,7 +9,8 @@
 
 # Specifies the JVM arguments used for the daemon process.
 # The setting is particularly useful for tweaking memory settings.
-org.gradle.jvmargs=-Xmx1536m
+# Added --add-opens flags for KAPT compatibility with Java 17+
+org.gradle.jvmargs=-Xmx1536m --add-opens=jdk.compiler/com.sun.tools.javac.api=ALL-UNNAMED --add-opens=jdk.compiler/com.sun.tools.javac.code=ALL-UNNAMED --add-opens=jdk.compiler/com.sun.tools.javac.comp=ALL-UNNAMED --add-opens=jdk.compiler/com.sun.tools.javac.file=ALL-UNNAMED --add-opens=jdk.compiler/com.sun.tools.javac.jvm=ALL-UNNAMED --add-opens=jdk.compiler/com.sun.tools.javac.main=ALL-UNNAMED --add-opens=jdk.compiler/com.sun.tools.javac.parser=ALL-UNNAMED --add-opens=jdk.compiler/com.sun.tools.javac.processing=ALL-UNNAMED --add-opens=jdk.compiler/com.sun.tools.javac.tree=ALL-UNNAMED --add-opens=jdk.compiler/com.sun.tools.javac.util=ALL-UNNAMED
 
 # When configured, Gradle will run in incubating parallel mode.
 # This option should only be used with decoupled projects. More details, visit

capacitor.config.ts

@@ -44,6 +44,31 @@ const config: CapacitorConfig = {
         biometricTitle: 'Biometric login for TimeSafari'
       },
       electronIsEncryption: false
+    },
+    DailyNotification: {
+      debugMode: true,
+      enableNotifications: true,
+      timesafariConfig: {
+        activeDid: '', // Will be set dynamically from user's DID
+        endpoints: {
+          projectsLastUpdated: 'https://api.endorser.ch/api/v2/report/plansLastUpdatedBetween'
+        },
+        starredProjectsConfig: {
+          enabled: true,
+          starredPlanHandleIds: [],
+          fetchInterval: '0 8 * * *'
+        }
+      },
+      networkConfig: {
+        timeout: 30000,
+        retryAttempts: 3,
+        retryDelay: 1000
+      },
+      contentFetch: {
+        enabled: true,
+        schedule: '0 8 * * *',
+        fetchLeadTimeMinutes: 5
+      }
     }
   },
   ios: {

doc/DAILY_NOTIFICATION_BUG_DIAGNOSIS.md

@@ -0,0 +1,120 @@
+# Daily Notification Bugs — Diagnosis (Plugin + App)
+
+**Context:** Fixes were applied in both the plugin and the app, but "reset doesn't fire" and "notification text defaults to fallback" still occur. This doc summarizes what was checked and what to do next.
+
+---
+
+## What Was Verified
+
+### App integration (correct)
+
+- **NativeNotificationService.ts**  
+  - Pre-cancel is gated: only iOS calls `cancelDailyReminder()` before scheduling (lines 289–305). Android skips it.  
+  - Schedules with `id: this.reminderId` (`"daily_timesafari_reminder"`), plus `time`, `title`, `body`.  
+  - Calls `DailyNotification.scheduleDailyNotification(scheduleOptions)` (not `scheduleDailyReminder`).
+
+- **AccountViewView.vue**  
+  - `editReminderNotification()` only calls `cancelDailyNotification()` when **not** Android (lines 1303–1305). On Android it only calls `scheduleDailyNotification()`.  
+
+So the app is not double-cancelling on Android and is passing the expected options.
+
+### Plugin in app’s node_modules (fixed code present)
+
+- **node_modules/@timesafari/daily-notification-plugin** is at **version 1.1.4** and contains:
+  - **NotifyReceiver.kt:** DB idempotence is skipped when `skipPendingIntentIdempotence=true` (wrapped in `if (!skipPendingIntentIdempotence)`).
+  - **DailyNotificationWorker.java:** `preserveStaticReminder` read from input, stable `scheduleId` for static reminders, and `scheduleExactNotification(..., preserveStaticReminder, ...)`.
+  - **DailyNotificationPlugin.kt:** `cancelDailyReminder(call)` implemented.
+
+So the **source** the app uses (from its dependency) already has the fixes.
+
+### Plugin schedule path (correct)
+
+- App calls `scheduleDailyNotification` → plugin’s `scheduleDailyNotification(call)` → `ScheduleHelper.scheduleDailyNotification(...)`.
+- That helper calls `NotifyReceiver.cancelNotification(context, scheduleId)` then `scheduleExactNotification(..., skipPendingIntentIdempotence = true)`.
+- So the “re-set” path does set `skipPendingIntentIdempotence = true` and the DB idempotence skip should apply.
+
+---
+
+## Likely Causes Why Bugs Still Appear
+
+### 1. Stale Android build / old APK
+
+The Android app compiles the plugin from:
+
+`android/capacitor.settings.gradle` →  
+`project(':timesafari-daily-notification-plugin').projectDir = new File('../node_modules/@timesafari/daily-notification-plugin/android')`
+
+If the app was not fully rebuilt after the plugin in node_modules was updated, the running APK may still contain old plugin code.
+
+**Do this:**
+
+- In the **app** repo (`crowd-funder-for-time-pwa`):
+  - `./gradlew clean` (or Android Studio → Build → Clean Project)
+  - Build and reinstall the app (e.g. Run on device/emulator).
+- Confirm you’re not installing an older APK from somewhere else.
+
+### 2. Dependency not actually updated after plugin changes
+
+The app depends on:
+
+```json
+"@timesafari/daily-notification-plugin": "git+https://gitea.anomalistdesign.com/trent_larson/daily-notification-plugin.git#master"
+```
+
+If the fixes were only made in a **local clone** and never pushed to **gitea** `master`, then:
+
+- `npm install` / `npm update` in the app would not pull the fixes.
+- The app’s `node_modules` would only have the fixes if they were copied/linked from the fixed repo.
+
+**Do this:**
+
+- **Push** the fixed plugin to the official gitea repo (`trent_larson/daily-notification-plugin`), then in this app run `npm update @timesafari/daily-notification-plugin` (or set `package.json` to the branch/tag/commit you need), `npm install`, `npx cap sync android`, clean build and reinstall. The app should always depend on the published git remote, not a local `file:` path.
+
+### 3. Fallback text from native fetcher (Bug 2 only)
+
+**TimeSafariNativeFetcher.java** in the app is still a placeholder: it always returns:
+
+- Title: `"TimeSafari Update"`
+- Body: `"Check your starred projects for updates!"`
+
+That only affects flows that **fetch** content (e.g. prefetch or any path that uses the fetcher for display). The **static** daily reminder path does not use the fetcher for display: title/body come from the schedule Intent and WorkManager input. So if you only use the “daily reminder” (one time + custom title/body), the fetcher placeholder should not be the cause. If you have any flow that relies on **fetched** content for the text, you’ll see that placeholder until the fetcher is implemented and wired (and optionally token persistence).
+
+---
+
+## Verification Steps (after clean build + reinstall)
+
+1. **Reset / “re-set” (Bug 1)**  
+   - Set reminder for 2–3 minutes from now.  
+   - Edit and save **without changing the time**.  
+   - Wait for the time; the notification should fire.  
+   - In logcat, filter by the plugin’s tags and look for:
+     - `Skipping DB idempotence (skipPendingIntentIdempotence=true) for scheduleId=...`
+     - `Scheduling next daily alarm: id=daily_timesafari_reminder ...`  
+   If you see these, the fixed path is running.
+
+2. **Static text on rollover (Bug 2)**  
+   - Set a custom title/body, let the notification fire once.  
+   - In logcat look for:
+     - `DN|ROLLOVER next=... scheduleId=daily_timesafari_reminder static=true`  
+   If you see `static=true` and the same `scheduleId`, the next occurrence should keep your custom text.
+
+3. **Plugin version at build time**  
+   - In the app’s `node_modules/@timesafari/daily-notification-plugin/package.json`, confirm `"version": "1.1.4"` (or the version that includes the fixes).  
+   - After that, a clean build ensures that version is what’s in the APK.
+
+---
+
+## Summary
+
+| Check | Status |
+|-------|--------|
+| App gates cancel on Android | OK |
+| App calls scheduleDailyNotification with id/title/body | OK |
+| Plugin in app node_modules has DB idempotence skip | OK (1.1.4) |
+| Plugin in app node_modules has static rollover fix | OK |
+| Plugin in app node_modules has cancelDailyReminder | OK |
+| Schedule path passes skipPendingIntentIdempotence = true | OK |
+
+**See also:** `doc/plugin-feedback-android-rollover-double-fire-and-user-content.md` — when two notifications fire (e.g. one ~3 min early, one on the dot) and neither shows user-set content.
+
+Most likely the app is still running an **old Android build**. Do a **clean build and reinstall**, and ensure the plugin dependency in the app really points at the fixed code (gitea master or local path). Then re-test and check logcat for the lines above. If the bugs persist after that, the next step is to capture a full logcat from “edit reminder (same time)” through the next fire and from “first fire” through “next day” to see which path runs.

doc/DAILY_NOTIFICATION_DUPLICATE_FALLBACK_ANALYSIS.md

@@ -0,0 +1,169 @@
+# Daily Notification: Why Extra Notifications With Fallback / "Starred Projects" Still Fire
+
+**Date:** 2026-03-02  
+**Context:** After previous fixes (see `DAILY_NOTIFICATION_BUG_DIAGNOSIS.md` and `plugin-feedback-android-rollover-double-fire-and-user-content.md`), duplicate notifications and fallback/"starred projects" text still occur. This doc explains root causes and where fixes must happen.
+
+---
+
+## Summary of What’s Happening
+
+1. **Extra notification(s)** fire at a different time (e.g. ~3 min early) or at the same time as the user-set one.
+2. **Wrong text** appears: either generic fallback ("Daily Update" / "Good morning! Ready to make today amazing?") or the app’s placeholder ("TimeSafari Update" / "Check your starred projects for updates!").
+3. The **correct** notification (user-set time and message) can still fire as well, so the user sees both correct and wrong notifications.
+
+---
+
+## Root Causes
+
+### 1. Second alarm from prefetch (UUID / fallback)
+
+**Mechanism**
+
+- The plugin has two scheduling paths:
+  - **NotifyReceiver** (AlarmManager): used for the app’s single daily reminder; uses `scheduleId` (e.g. `daily_timesafari_reminder`) and carries title/body in the Intent.
+  - **DailyNotificationScheduler** (legacy): used by **DailyNotificationFetchWorker** when prefetch runs and then calls `scheduleNotificationIfNeeded(fallbackContent)`. That creates a **second** alarm with `notification_id` = **UUID** (from `createEmergencyFallbackContent()` or from fetcher placeholder).
+
+- **ScheduleHelper** correctly **does not** enqueue prefetch for static reminders (see comment in `DailyNotificationPlugin.kt` ~2686: "Do not enqueue prefetch for static reminders"). So **new** schedules from the app no longer create a prefetch job.
+
+- However:
+  - **Existing** WorkManager prefetch jobs (tag `daily_notification_fetch`) that were enqueued **before** that fix (or by an older build) are still pending. When they run, fetch fails or returns placeholder → `useFallbackContent()` → `scheduleNotificationIfNeeded(fallbackContent)` → **second alarm with UUID**.
+  - That UUID alarm is **not** stored in the Schedule table. So when the user later calls `scheduleDailyNotification`, **cleanupExistingNotificationSchedules** only cancels alarms for schedule IDs that exist in the DB (e.g. `daily_timesafari_reminder`, `daily_rollover_*`). The **UUID alarm is never cancelled**.
+
+- **Result:** You can have two alarms: one for `daily_timesafari_reminder` (correct) and one for a UUID (fallback text). If the UUID alarm was set for a slightly different time (e.g. from an old rollover), you get two notifications at two times.
+
+**Where the fallback text comes from (plugin)**
+
+- **DailyNotificationFetchWorker** (in both app’s `node_modules` plugin and the standalone repo):
+  - On failed fetch after max retries: `useFallbackContent(scheduledTime)` → `createEmergencyFallbackContent(scheduledTime)` → title "Daily Update", body "🌅 Good morning! Ready to make today amazing?".
+  - That content is saved and then **scheduled** via `scheduleNotificationIfNeeded(fallbackContent)`, which uses **DailyNotificationScheduler** (legacy) and assigns a **new UUID** to the content. So the second alarm fires with that UUID and shows that fallback text.
+
+### 2. Prefetch WorkManager jobs not cancelled when user reschedules
+
+- **scheduleDailyNotification** (plugin) calls:
+  - `ScheduleHelper.cleanupExistingNotificationSchedules(...)` → cancels **alarms** for all DB schedules (except current `scheduleId`).
+  - `ScheduleHelper.scheduleDailyNotification(...)` → cancels alarm for current `scheduleId`, schedules NotifyReceiver alarm, **does not** enqueue prefetch.
+
+- It does **not** cancel **WorkManager** jobs. So any already-enqueued prefetch work (tag `daily_notification_fetch`) remains. When that work runs, it creates the second (UUID) alarm as above.
+
+- **ScheduleHelper** has `cancelAllWorkManagerJobs(context)` (cancels tags `prefetch`, `daily_notification_fetch`, etc.), but **nothing calls it** in the schedule path. So pending prefetch jobs are left in place.
+
+**Fix (plugin):** When the app calls `scheduleDailyNotification`, **cancel all fetch-related WorkManager work** (e.g. call `ScheduleHelper.cancelAllWorkManagerJobs(context)` or a helper that only cancels `daily_notification_fetch` and `prefetch`) **before** or **right after** `cleanupExistingNotificationSchedules`. That prevents any pending prefetch from running and creating a UUID alarm later.
+
+### 3. "Starred projects" message from the app’s native fetcher
+
+- **TimeSafariNativeFetcher** (`android/app/src/main/java/app/timesafari/TimeSafariNativeFetcher.java`) is still a **placeholder**: it always returns:
+  - Title: `"TimeSafari Update"`
+  - Body: `"Check your starred projects for updates!"`
+
+- That text is used whenever the plugin **fetches** content and then displays it:
+  - **DailyNotificationFetchWorker**: on “successful” fetch it saves and schedules the fetcher’s result; for your app that result is the placeholder, so any notification created from that path shows “starred projects”.
+  - **DailyNotificationWorker** (JIT path): when `is_static_reminder` is false and content is loaded from Room by `notification_id`, if the worker then does a JIT refresh (e.g. content stale), it calls `DailyNotificationFetcher.fetchContentImmediately()` which can use the app’s native fetcher and **overwrite** title/body with the placeholder.
+
+- So “starred projects” appears on any notification that goes through a **fetch** path (prefetch success or JIT) instead of the **static reminder** path (Intent title/body or Room by canonical `schedule_id`).
+
+**Fix (app):** For a static-reminder-only flow, the plugin should not run prefetch (already done) and should not overwrite with fetcher in JIT for static reminders. Reducing duplicate/out-of-schedule alarms (fixes above) ensures the main run is the static one. Optionally, implement **TimeSafariNativeFetcher** to return real content if you ever want “fetch-based” notifications; until then, the only path that should show user text is the NotifyReceiver alarm with `daily_timesafari_reminder` and title/body from Intent or from Room by `schedule_id`.
+
+### 4. Rollover / Room content keyed by run-specific id
+
+- When an alarm fires with `notification_id` = **UUID** or **notify_<timestamp>** (and no or missing title/body in the Intent), the Worker treats it as **non-static**. It loads content from Room by that `notification_id`. The entity for `daily_timesafari_reminder` (user title/body) is stored under a **different** id, so the Worker either finds nothing or finds content written by prefetch/fallback for that run → wrong text.
+
+- When the alarm is the **correct** one (`daily_timesafari_reminder`) and Intent has title/body (or `schedule_id`), the Worker uses static reminder or resolves by `schedule_id` and shows user text. So the main fix is to **avoid creating the UUID/notify_* run in the first place** (cancel prefetch work; no second alarm). Rollover for the static reminder already passes `scheduleId` and title/body in the Intent (NotifyReceiver puts them in the PendingIntent), so once there’s only one alarm, rollover should keep user text.
+
+---
+
+## Where Fixes Must Happen
+
+### Plugin (daily-notification-plugin)
+
+**1. Cancel prefetch (and related) WorkManager jobs when scheduling**
+
+- **File:** `DailyNotificationPlugin.kt` (or wherever `scheduleDailyNotification` is implemented).
+- **Change:** When handling `scheduleDailyNotification`, after `cleanupExistingNotificationSchedules` and before (or after) `ScheduleHelper.scheduleDailyNotification`, call a method that cancels all WorkManager work that can create a second alarm. Prefer reusing **ScheduleHelper.cancelAllWorkManagerJobs(context)** or adding a small helper that cancels only fetch-related tags (e.g. `daily_notification_fetch`, `prefetch`) so you don’t cancel display/dismiss work unnecessarily.
+- **Effect:** Pending prefetch jobs from older builds or previous flows will not run, so no new UUID alarm is created and no extra notification with fallback text.
+
+**2. (Already done) Do not enqueue prefetch for static reminders**
+
+- **ScheduleHelper.scheduleDailyNotification** already does **not** enqueue FetchWorker for static reminders. No change needed here; just ensure no other code path enqueues prefetch for the app’s single daily reminder.
+
+**3. (Optional) DailyNotificationFetchWorker: skip scheduling second alarm for static-reminder schedules**
+
+- If you ever enqueue prefetch with an explicit “static reminder” flag, in **DailyNotificationFetchWorker** inside `useFallbackContent` / `scheduleNotificationIfNeeded`, skip calling `scheduleNotificationIfNeeded` when that flag is set. For your current setup (no prefetch for static), this is redundant but makes the contract clear and future-proof.
+
+**4. Receiver: no DB on main thread**
+
+- Your **DailyNotificationReceiver** in the app’s plugin only reads Intent extras and enqueues work; it does not read Room on the main thread. If you still see `db_fallback_failed` in logcat, the failing DB access is elsewhere (e.g. another receiver or an old build). Ensure no BroadcastReceiver does Room/DB access on the main thread; resolve title/body in the Worker from `schedule_id` if Intent lacks them.
+
+### App (crowd-funder-for-time-pwa)
+
+**Scope: static reminders only.** For fixing static reminders, **no app code changes are required.** Real fetch-based content can be added later.
+
+**1. TimeSafariNativeFetcher**
+
+- **File:** `android/app/src/main/java/app/timesafari/TimeSafariNativeFetcher.java`
+- **Current behavior:** Placeholder that returns `"TimeSafari Update"` / `"Check your starred projects for updates!"` (expected).
+- **For static reminders now:** Leave as-is. The plugin fix (cancel prefetch work when scheduling) ensures the only notification path is the static one; the fetcher is never used for display in that flow. No change needed.
+- **Later (optional):** When you implement real-world content fetching, replace the placeholder here so any future fetch-driven notifications show real content.
+
+**2. Build and dependency**
+
+- After plugin changes, ensure the app uses the updated plugin (point `package.json` at the fixed repo or publish and bump version), then **clean build** Android (`./gradlew clean`, rebuild, reinstall). Confirming the APK contains the plugin version that cancels prefetch work and does not enqueue prefetch for static reminders avoids stale behavior from old builds.
+
+---
+
+## Verification After Fixes
+
+1. **Single notification, user text**
+   - Set daily reminder with a **distinct** title/body and a time 2–3 minutes ahead. Wait until that time.
+   - **Expect:** Exactly **one** notification at that time with your text. No second notification (no UUID, no “Daily Update” or “starred projects”).
+
+2. **No out-of-schedule notification**
+   - Change reminder time (e.g. from 21:53 to 21:56) and save. Wait past 21:53 and until 21:56.
+   - **Expect:** No notification at 21:53; one at 21:56 with your text.
+
+3. **Rollover**
+   - Let the correct notification fire once so rollover runs. Next day (or next occurrence) you should see **one** notification with the same user text.
+
+4. **Logcat**
+   - No `display=<uuid>` at the same time as `static_reminder id=daily_timesafari_reminder`.
+   - After scheduling (e.g. edit and save), you should see prefetch/fetch work being cancelled if you add a log in the cancel path.
+
+---
+
+## Short Summary
+
+| Issue | Cause | Fix location |
+|-------|--------|--------------|
+| Extra notification at same or different time | Prefetch WorkManager job still runs and creates second (UUID) alarm via legacy scheduler; that alarm is never cancelled on reschedule | **Plugin:** Cancel fetch-related WorkManager jobs when `scheduleDailyNotification` is called |
+| Fallback text ("Daily Update" / "Good morning!") | FetchWorker’s `useFallbackContent` → `scheduleNotificationIfNeeded` creates alarm with that content | **Plugin:** Same as above (no prefetch run → no fallback alarm); optionally FetchWorker skips scheduling when static-reminder flag set |
+| "Starred projects" text | TimeSafariNativeFetcher placeholder used when a fetch path runs | **Plugin:** Same as above (no prefetch → no fetch path). **App:** No change for static reminders; leave fetcher as placeholder until real fetch is implemented. |
+| Wrong content on rollover | Rollover run keyed by UUID or notify_* and no title/body in Intent → Worker loads from Room by that id → wrong/empty content | **Plugin:** Avoid creating UUID/notify_* run (cancel prefetch). Static rollover already passes schedule_id and title/body. |
+
+The critical missing step is **cancelling prefetch (and fetch) WorkManager work when the user schedules or reschedules** the daily notification. That prevents any pending prefetch from running and creating the second alarm with fallback or “starred projects” text.
+
+---
+
+## For Cursor (plugin repo) — actionable handoff
+
+Use this section when applying the fix in the **daily-notification-plugin** repo (e.g. with Cursor). Paste or @-mention this doc as context.
+
+**Goal:** For static reminders, only one notification at the user's chosen time with user-set title/body. No extra notification from pending prefetch (UUID alarm with fallback or "starred projects" text).
+
+**Root cause:** `scheduleDailyNotification` cleans up DB schedules and alarms but **does not cancel WorkManager prefetch jobs**. Any previously enqueued job (tag `daily_notification_fetch`) still runs, then creates a second alarm via `DailyNotificationScheduler` (UUID). That alarm is never cancelled on reschedule. Fix: cancel fetch-related WorkManager work when the user schedules.
+
+**Change (required):**
+
+1. **Cancel fetch-related WorkManager jobs when handling `scheduleDailyNotification`**
+   - **File:** `android/src/main/java/com/timesafari/dailynotification/DailyNotificationPlugin.kt`
+   - **Where:** In `scheduleDailyNotification(call)`, inside the `CoroutineScope(Dispatchers.IO).launch { ... }` block, **after** `ScheduleHelper.cleanupExistingNotificationSchedules(...)` and **before** `ScheduleHelper.scheduleDailyNotification(...)`.
+   - **What:** Call a method that cancels WorkManager work that can create a second alarm. Reuse **ScheduleHelper.cancelAllWorkManagerJobs(context)** (it already cancels `prefetch`, `daily_notification_fetch`, etc.). If you prefer not to cancel display/dismiss work, add a helper that only cancels `daily_notification_fetch` and `prefetch` and call that instead.
+   - **Example (using existing helper):**
+     ```kotlin
+     ScheduleHelper.cancelAllWorkManagerJobs(context)
+     ```
+     (If `cancelAllWorkManagerJobs` is suspend, call it with `runBlocking { }` or from the same coroutine scope.)
+
+**No other plugin changes needed for this fix:** ScheduleHelper already does not enqueue prefetch for static reminders; the only missing step is cancelling **pending** prefetch work when the user schedules or reschedules.
+
+**Files to look at (plugin Android):**
+- `DailyNotificationPlugin.kt` — `scheduleDailyNotification(call)` (add cancel call after cleanup, before ScheduleHelper.scheduleDailyNotification).
+- `ScheduleHelper` (in same file or separate) — `cancelAllWorkManagerJobs(context)` (already exists; ensure it cancels at least `daily_notification_fetch` and `prefetch`).

doc/NOTIFICATION_TROUBLESHOOTING.md

@@ -0,0 +1,82 @@
+# TimeSafari — Daily notifications troubleshooting (iOS & Android)
+
+**Last updated:** 2026-03-06 17:08 PST  
+**Audience:** End-users  
+**Applies to:** TimeSafari iOS/Android native app (daily notifications scheduled on-device)
+
+If your **Daily Reminder** or notification doesn’t show up, follow the steps below.
+
+## Before you start
+
+- These notifications are **scheduled on your device** (no browser/web push).
+- If you previously followed an older “web notifications” guide, those steps no longer apply for iOS/Android builds.
+
+## 1) Check your in-app notification settings
+
+- Tap **Profile** in the bottom bar
+- Under **Notifications**, confirm:
+  - **Daily Reminder** is **enabled**
+  - The **time** is set correctly
+  - The message looks correct
+- If it’s already enabled, try to:
+  - Turn it **off**
+  - Turn it **on** again
+  - Re-set the time and message
+
+## 2) iOS troubleshooting
+
+### Allow notifications for TimeSafari
+
+1. Open **Settings** → **Notifications**
+2. Tap **TimeSafari**
+3. Turn **Allow Notifications** on
+4. Enable at least one delivery style (recommended):
+  - **Lock Screen**
+  - **Notification Center**
+  - **Banners**
+5. Optional but helpful:
+  - **Sounds** on (if you want an audible reminder)
+
+### Focus / Do Not Disturb
+
+If you’re using **Focus** or **Do Not Disturb**, notifications may be silenced or hidden.
+
+- Open **Settings** → **Focus**
+- Check the active Focus mode and ensure **TimeSafari** is allowed (or temporarily disable Focus to test)
+
+### After restarting your phone
+
+If you recently restarted iOS and don’t see the notification, open **TimeSafari** once. (You don’t need to change anything.)
+
+## 3) Android troubleshooting
+
+### Allow notifications for TimeSafari
+
+1. Open **Settings** → **Apps**
+2. Tap **TimeSafari** → **Manage notifications** (wording varies)
+3. Turn notifications **on**
+4. If Android shows notification categories/channels for the app, ensure the relevant channel is allowed.
+
+### Battery / background restrictions
+
+Battery optimization can delay or block scheduled notifications.
+
+- Open **Settings** → **Apps** → **TimeSafari** → **Battery usage** (wording varies)
+- If available:
+  - Set **Battery usage** to **Unrestricted**
+  - Turn **Allow background usage** on
+  - Disable optimization for TimeSafari
+- If your device has lists like **Sleeping apps** / **Restricted apps**, remove TimeSafari from them
+
+### After restarting your phone
+
+Depending on the device manufacturer, Android can clear scheduled notifications during a reboot. If you restarted recently:
+
+- Open **TimeSafari** once (you don’t need to change anything)
+
+## 4) If it still doesn’t work
+
+- Ensure you’re on the latest TimeSafari app version.
+- If you denied permission earlier, re-enable notifications in system settings (above).
+- As a last resort, uninstall/reinstall the app (you’ll need to enable notifications again and reconfigure the daily reminder). **Important:** Before uninstalling, back up your identifier seed so you can import it back later: **Profile → Data Management → Backup Identifier Seed**.
+

doc/android-daily-notification-second-schedule-issue.md

@@ -0,0 +1,85 @@
+# Android: Second notification doesn't fire (investigation & plan)
+
+**Handoff to plugin repo:** This doc can be used as context in the daily-notification-plugin repo (e.g. in Cursor) to fix the Android re-schedule issue. See **Plugin-side: where to look and what to try** and **Could "re-scheduling too soon" cause the failure?** for actionable plugin changes.
+
+---
+
+## Current state
+
+- **Symptom**: After a fresh install, the first scheduled daily notification fires. When the user sets another notification (same or different time), it does not fire until the app is uninstalled and reinstalled.
+- **Test app**: The plugin's test app (`daily-notification-test`) does not show this issue; scheduling a second notification works.
+- **Attempted fix**: We changed the reminder ID from `timesafari_daily_reminder` to `daily_timesafari_reminder` so the plugin's rollover logic preserves the schedule ID (IDs starting with `daily_` are preserved). That did not fix the issue.
+
+## Could "re-scheduling too soon" cause the failure?
+
+**Yes, timing can matter.** The plugin is not very forgiving on Android in one case:
+
+- **Idempotence in `NotifyReceiver.scheduleExactNotification`**: Before scheduling, the plugin checks for an existing PendingIntent (same `scheduleId` or same trigger time). If one exists, it **skips** scheduling to avoid duplicates.
+- **After cancel**: When you re-schedule, the flow is `cancelNotification(scheduleId)` then `scheduleExactNotification(...)`. Android may not remove a cancelled PendingIntent from its cache immediately. If the idempotence check runs right after cancel, it can still see the old PendingIntent and treat the new schedule as a duplicate, so the second schedule is skipped.
+- **After the first notification fires**: The alarm is gone but the PendingIntent might still be in the system. If the user opens the app and re-schedules within a few seconds, the same “duplicate” logic can trigger.
+
+**Practical check:** Try waiting **5–10 seconds** after the first notification fires (or after changing time and saving) before saving again. If re-scheduling works when you wait but fails when you do it immediately, the cause is this timing/idempotence behavior. Fix would be in the plugin (e.g. short delay after cancel before idempotence check, or re-check after cancel).
+
+**Other timing in the plugin (do not apply to your flow):** `DailyNotificationScheduler` has a 10s “notification throttle” and a 30s “activeDid changed” grace; those are used only when scheduling from **fetched content / rollover**, not when the user calls `scheduleDailyNotification`. Your re-schedule path goes through `NotifyReceiver.scheduleExactNotification` only, so those timeouts are not the cause.
+
+## Differences: Test app vs TimeSafari
+
+| Aspect | Test app | TimeSafari (before alignment) |
+|--------|----------|-------------------------------|
+| **Method** | `scheduleDailyNotification(options)` | `scheduleDailyReminder(options)` |
+| **Options** | `{ time, title, body, sound, priority }` — **no `id`** | `{ id, time, title, body, repeatDaily, sound, vibration, priority }` |
+| **Effective scheduleId** | Plugin default: `"daily_notification"` | Explicit: `"daily_timesafari_reminder"` (then `"daily_timesafari_reminder"` after prefix fix) |
+| **Pre-cancel** | None | Calls `cancelDailyReminder({ reminderId })` before scheduling |
+| **Android cancelDailyReminder** | Not used | Plugin **does not expose** `cancelDailyReminder` on Android (only `cancelAllNotifications`). So the pre-cancel is a no-op or fails silently. |
+
+The plugin's `scheduleDailyNotification` flow already cancels the existing alarm for the **same** scheduleId via `NotifyReceiver.cancelNotification(context, scheduleId)` before scheduling. So the only behavioral difference that might matter is **which scheduleId is used** and **whether we pass an `id`**.
+
+## Plan (app-side only)
+
+1. **Platform-specific behavior** (implemented):
+   - **Android**: Use **`scheduleDailyNotification`** without passing `id` so the plugin uses default scheduleId **`"daily_notification"`**. Use **`reminderId = "daily_notification"`** for cancel/getStatus. **Do not** call `cancelDailyReminder` before scheduling on Android (test app does not; plugin cancels the previous alarm internally).
+   - **iOS**: Use **`scheduleDailyNotification`** with **`id: "daily_timesafari_reminder"`** and call **`cancelDailyReminder`** before scheduling so the reminder is removed from the notification center before rescheduling.
+2. **If Android re-schedule still fails**, next step is **plugin-side investigation** in the plugin repo (no patch in this repo):
+   - Add logging in `NotifyReceiver.scheduleExactNotification` (idempotence checks, PendingIntent/DB) and in `ScheduleHelper.scheduleDailyNotification` / `cleanupExistingNotificationSchedules`; compare logcat for test app vs TimeSafari when scheduling twice.
+   - Optionally in test app: pass an explicit `id` when scheduling and test scheduling twice; if it then fails, the bug is tied to custom scheduleIds and the fix belongs in the plugin.
+   - Confirm whether the second schedule is skipped by an idempotence check (e.g. PendingIntent still present, or DB `nextRunAt` within 1 min of new trigger) or by another code path.
+
+## Plugin-side: where to look and what to try
+
+*(Use this section when working in the daily-notification-plugin repo.)*
+
+**Entry point (user schedule):**  
+`DailyNotificationPlugin.kt` → `scheduleDailyNotification` → `ScheduleHelper.scheduleDailyNotification` → `NotifyReceiver.cancelNotification(context, scheduleId)` then `NotifyReceiver.scheduleExactNotification(...)`.
+
+**Relevant plugin files (paths relative to plugin root):**
+
+- **`android/.../NotifyReceiver.kt`**
+  - `scheduleExactNotification`: idempotence checks at start (PendingIntent by requestCode, by trigger time, then DB by scheduleId + nextRunAt within 60s). If any check finds an existing schedule, the function returns without scheduling.
+  - `cancelNotification`: cancels alarm and `existingPendingIntent.cancel()`. Android may not drop the PendingIntent from its cache immediately.
+- **`android/.../DailyNotificationPlugin.kt`** (or ScheduleHelper companion/object)
+  - `ScheduleHelper.scheduleDailyNotification`: calls `NotifyReceiver.cancelNotification(context, scheduleId)` then `NotifyReceiver.scheduleExactNotification(...)`.
+  - `cleanupExistingNotificationSchedules`: cancels and deletes other schedules; excludes current scheduleId.
+
+**Likely cause:** Idempotence in `scheduleExactNotification` runs *after* `cancelNotification` in the same flow. A just-cancelled PendingIntent can still be returned by `PendingIntent.getBroadcast(..., FLAG_NO_CREATE)` and cause the new schedule to be skipped.
+
+**Suggested fixes (in plugin):**
+
+1. **Re-check after cancel:** In the path that does cancel-then-schedule (e.g. in `ScheduleHelper.scheduleDailyNotification`), after `cancelNotification(scheduleId)` either:
+   - Call `PendingIntent.getBroadcast(..., FLAG_NO_CREATE)` for that scheduleId in a short loop with a small delay (e.g. 50–100 ms) until it returns null, with a timeout (e.g. 500 ms), then call `scheduleExactNotification`; or
+   - Pass a flag into `scheduleExactNotification` to skip or relax the "existing PendingIntent" idempotence when the caller has just cancelled this scheduleId.
+2. **Or brief delay before idempotence:** When the schedule path has just called `cancelNotification(scheduleId)`, have `scheduleExactNotification` skip the PendingIntent check for that scheduleId if last cancel was < 1–2 s ago (e.g. store "justCancelled(scheduleId)" with timestamp).
+3. **Logging:** In `NotifyReceiver.scheduleExactNotification`, log when scheduling is skipped and which check triggered (PendingIntent by requestCode, by time, or DB). Capture logcat for "schedule, then fire, then re-schedule within a few seconds" to confirm.
+
+**Reproduce in test app:** In `daily-notification-test`, schedule once, let it fire (or wait), then schedule again within 1–2 seconds. If the second schedule doesn't fire, the bug is reproducible in the plugin; then apply one of the fixes above and re-test.
+
+---
+
+## If changes are needed in the plugin repo (TimeSafari app note)
+
+Do **not** add a patch in this (TimeSafari) repo. Instead:
+
+1. **Reproduce in the plugin's test app** (e.g. pass an explicit `id` like `"custom_id"` when scheduling and try scheduling twice) to see if the issue is tied to custom scheduleIds.
+2. **Add the logging** above in the plugin's Android code and capture logs for “first schedule → fire → second schedule” in both test app and TimeSafari.
+3. **Fix in the plugin** (e.g. relax or correct idempotence, or ensure cancel + DB state are consistent for the same scheduleId) and release a new plugin version; then bump the plugin dependency in this app.
+
+No patch file or copy of plugin code is needed in the TimeSafari repo.

doc/android-physical-device-guide.md

@@ -0,0 +1,515 @@
+# Android Physical Device Deployment Guide
+
+**Author**: Matthew Raymer  
+**Date**: 2025-02-12  
+**Status**: 🎯 **ACTIVE** - Complete guide for deploying TimeSafari to physical Android devices
+
+## Overview
+
+This guide provides comprehensive instructions for building and deploying TimeSafari to physical Android devices for testing and development. Unlike emulator testing, physical device testing requires additional setup for USB connections and network configuration.
+
+## Prerequisites
+
+### Required Tools
+
+1. **Android SDK Platform Tools** (includes `adb`)
+   ```bash
+   # macOS (Homebrew)
+   brew install android-platform-tools
+   
+   # Or via Android SDK Manager
+   sdkmanager "platform-tools"
+   ```
+
+2. **Node.js 18+** and npm
+
+3. **Java Development Kit (JDK) 17+**
+   ```bash
+   # macOS (Homebrew)
+   brew install openjdk@17
+   
+   # Verify installation
+   java -version
+   ```
+
+### Environment Setup
+
+Add to your shell configuration (`~/.zshrc` or `~/.bashrc`):
+
+```bash
+# Android SDK location
+export ANDROID_HOME=$HOME/Library/Android/sdk  # macOS default
+# export ANDROID_HOME=$HOME/Android/Sdk        # Linux default
+
+export PATH=$PATH:$ANDROID_HOME/platform-tools
+export PATH=$PATH:$ANDROID_HOME/cmdline-tools/latest/bin
+export PATH=$PATH:$ANDROID_HOME/build-tools/34.0.0
+```
+
+Reload your shell:
+
+```bash
+source ~/.zshrc  # or source ~/.bashrc
+```
+
+Verify installation:
+
+```bash
+adb version
+```
+
+## Device Setup
+
+### Step 1: Enable Developer Options
+
+Developer Options is hidden by default on Android devices. To enable it:
+
+1. Open **Settings** on your Android device
+2. Scroll down and tap **About phone** (or **About device**)
+3. Find **Build number** and tap it **7 times** rapidly
+4. You'll see a message: "You are now a developer!"
+5. Go back to Settings - **Developer options** now appears
+
+### Step 2: Enable USB Debugging
+
+1. Go to **Settings** → **Developer options**
+2. Enable **USB debugging** (toggle it ON)
+3. Optionally enable these helpful options:
+   - **Stay awake** - Screen stays on while charging
+   - **Install via USB** - Allow app installations via USB
+
+### Step 3: Connect Your Device
+
+1. Connect your Android device to your computer via USB cable
+2. On your device, you'll see a prompt: "Allow USB debugging?"
+3. Check **"Always allow from this computer"** (recommended)
+4. Tap **Allow**
+
+### Step 4: Verify Connection
+
+```bash
+# List connected devices
+adb devices
+
+# Expected output:
+# List of devices attached
+# XXXXXXXXXX    device
+```
+
+If you see `unauthorized` instead of `device`, check your phone for the USB debugging authorization prompt.
+
+## Network Configuration for Development
+
+### Understanding the Network Challenge
+
+When running a local development server on your computer:
+- **Emulators** use `10.0.2.2` to reach the host machine
+- **Physical devices** need your computer's actual LAN IP address
+
+### Step 1: Find Your Computer's IP Address
+
+```bash
+# macOS
+ipconfig getifaddr en0    # Wi-Fi
+# or
+ipconfig getifaddr en1    # Ethernet
+
+# Linux
+hostname -I | awk '{print $1}'
+# or
+ip addr show | grep 'inet ' | grep -v '127.0.0.1' | awk '{print $2}' | cut -d'/' -f1
+```
+
+Example output: `192.168.1.100`
+
+### Step 2: Ensure Same Network
+
+Your Android device and computer **must be on the same Wi-Fi network** for the device to reach your local development servers.
+
+### Step 3: Configure API Endpoints
+
+Create or edit `.env.development` with your computer's IP:
+
+```bash
+# .env.development - for physical device testing
+VITE_DEFAULT_ENDORSER_API_SERVER=http://192.168.1.100:3000
+VITE_DEFAULT_PARTNER_API_SERVER=http://192.168.1.100:3000
+VITE_DEFAULT_IMAGE_API_SERVER=https://test-image-api.timesafari.app
+VITE_APP_SERVER=http://192.168.1.100:8080
+```
+
+**Important**: Replace `192.168.1.100` with your actual IP address.
+
+### Step 4: Start Your Local Server
+
+If testing against local API servers, ensure they're accessible from the network:
+
+```bash
+# Start your API server bound to all interfaces (not just localhost)
+# Example for Node.js:
+node server.js --host 0.0.0.0
+
+# Or configure your server to listen on 0.0.0.0 instead of 127.0.0.1
+```
+
+### Alternative: Use Test/Production Servers
+
+For simpler testing without local servers, use the test environment:
+
+```bash
+# Build with test API servers (no local server needed)
+npm run build:android:test
+```
+
+## Building and Deploying
+
+### Quick Start (Recommended)
+
+```bash
+# 1. Verify device is connected
+adb devices
+
+# 2. Build and deploy in one command
+npm run build:android:debug:run
+```
+
+### Step-by-Step Deployment
+
+#### Step 1: Build the App
+
+```bash
+# Development build (uses .env.development)
+npm run build:android:dev
+
+# Test build (uses test API servers)
+npm run build:android:test
+
+# Production build
+npm run build:android:prod
+```
+
+#### Step 2: Install the APK
+
+```bash
+# Install (replace existing if present)
+adb install -r android/app/build/outputs/apk/debug/app-debug.apk
+```
+
+#### Step 3: Launch the App
+
+```bash
+# Start the app
+adb shell am start -n app.timesafari.app/app.timesafari.MainActivity
+```
+
+### One-Line Deploy Commands
+
+```bash
+# Development build + install + launch
+npm run build:android:debug:run
+
+# Test build + install + launch
+npm run build:android:test:run
+
+# Deploy to connected device (build must exist)
+npm run build:android:deploy
+```
+
+## Debugging
+
+### View App Logs
+
+```bash
+# All logs from your app
+adb logcat | grep -E "(TimeSafari|Capacitor)"
+
+# With color highlighting
+adb logcat | grep -E "(TimeSafari|Capacitor)" --color=always
+
+# Save logs to file
+adb logcat > device-logs.txt
+```
+
+### Chrome DevTools (Remote Debugging)
+
+1. Open Chrome on your computer
+2. Navigate to `chrome://inspect`
+3. Your device should appear under "Remote Target"
+4. Click **inspect** to open DevTools for your app
+
+**Requirements**:
+- USB debugging must be enabled
+- Device must be connected via USB
+- App must be a debug build
+
+### Common Log Filters
+
+```bash
+# Network-related issues
+adb logcat | grep -i "network\|http\|socket"
+
+# JavaScript errors
+adb logcat | grep -i "console\|error\|exception"
+
+# Capacitor plugin issues
+adb logcat | grep -i "capacitor"
+
+# Detailed app logs
+adb logcat -s "TimeSafari:V"
+```
+
+## Troubleshooting
+
+### Device Not Detected
+
+**Symptom**: `adb devices` shows nothing or shows `unauthorized`
+
+**Solutions**:
+
+1. **Check USB cable**: Some cables are charge-only. Use a data-capable USB cable.
+
+2. **Revoke USB debugging authorizations** (on device):
+   - Settings → Developer options → Revoke USB debugging authorizations
+   - Reconnect and re-authorize
+
+3. **Restart ADB server**:
+   ```bash
+   adb kill-server
+   adb start-server
+   adb devices
+   ```
+
+4. **Try different USB port**: Some USB hubs don't work well with ADB.
+
+5. **Check device USB mode**: Pull down notification shade and ensure USB is set to "File Transfer" or "MTP" mode, not just charging.
+
+### App Can't Connect to Local Server
+
+**Symptom**: App loads but shows network errors or can't reach API
+
+**Solutions**:
+
+1. **Verify IP address**:
+   ```bash
+   # Make sure you have the right IP
+   ipconfig getifaddr en0  # macOS
+   ```
+
+2. **Check firewall**: Temporarily disable firewall or add exception for port 3000
+
+3. **Test connectivity from device**:
+   - Open Chrome on your Android device
+   - Navigate to `http://YOUR_IP:3000`
+   - Should see your API response
+
+4. **Verify server is listening on all interfaces**:
+   ```bash
+   # Should show 0.0.0.0:3000, not 127.0.0.1:3000
+   lsof -i :3000
+   ```
+
+5. **Same network check**: Ensure phone Wi-Fi and computer are on the same network
+
+### Installation Failed
+
+**Symptom**: `adb install` fails with error
+
+**Common errors and solutions**:
+
+1. **INSTALL_FAILED_UPDATE_INCOMPATIBLE**:
+   ```bash
+   # Uninstall existing app first
+   adb uninstall app.timesafari.app
+   adb install android/app/build/outputs/apk/debug/app-debug.apk
+   ```
+
+2. **INSTALL_FAILED_INSUFFICIENT_STORAGE**:
+   - Free up space on the device
+   - Or install to SD card if available
+
+3. **INSTALL_FAILED_USER_RESTRICTED**:
+   - Enable "Install via USB" in Developer options
+   - On some devices: Settings → Security → Unknown sources
+
+4. **Signature mismatch**:
+   ```bash
+   # Full clean reinstall
+   adb uninstall app.timesafari.app
+   npm run clean:android
+   npm run build:android:debug
+   adb install android/app/build/outputs/apk/debug/app-debug.apk
+   ```
+
+### App Crashes on Launch
+
+**Symptom**: App opens briefly then closes
+
+**Debug steps**:
+
+1. **Check crash logs**:
+   ```bash
+   adb logcat | grep -E "FATAL|AndroidRuntime|Exception"
+   ```
+
+2. **Clear app data**:
+   ```bash
+   adb shell pm clear app.timesafari.app
+   ```
+
+3. **Reinstall clean**:
+   ```bash
+   adb uninstall app.timesafari.app
+   npm run clean:android
+   npm run build:android:debug:run
+   ```
+
+### Build Failures
+
+**Symptom**: Build fails before APK is created
+
+**Solutions**:
+
+1. **Asset validation**:
+   ```bash
+   npm run assets:validate:android
+   ```
+
+2. **Clean and rebuild**:
+   ```bash
+   npm run clean:android
+   npm run build:android:debug
+   ```
+
+3. **Check Gradle**:
+   ```bash
+   cd android
+   ./gradlew clean --stacktrace
+   ./gradlew assembleDebug --stacktrace
+   ```
+
+## Wireless Debugging (Optional)
+
+Once initial USB connection is established, you can switch to wireless:
+
+### Enable Wireless Debugging
+
+```bash
+# 1. Connect via USB first
+adb devices
+
+# 2. Enable TCP/IP mode on port 5555
+adb tcpip 5555
+
+# 3. Find device IP (on device: Settings → About → IP address)
+# Or:
+adb shell ip addr show wlan0
+
+# 4. Connect wirelessly (disconnect USB cable)
+adb connect 192.168.1.XXX:5555
+
+# 5. Verify
+adb devices
+```
+
+### Reconnect After Reboot
+
+```bash
+# Device IP may have changed - check it first
+adb connect 192.168.1.XXX:5555
+```
+
+### Return to USB Mode
+
+```bash
+adb usb
+```
+
+## Best Practices
+
+### Development Workflow
+
+1. **Keep device connected during development** for quick iteration
+
+2. **Use test builds for most testing**:
+   ```bash
+   npm run build:android:test:run
+   ```
+   This avoids local server configuration hassles.
+
+3. **Use Chrome DevTools** for JavaScript debugging - much easier than logcat
+
+4. **Test on multiple devices** if possible - different Android versions behave differently
+
+### Performance Testing
+
+Physical devices give you real-world performance insights that emulators can't:
+
+- **Battery consumption**: Monitor with Settings → Battery
+- **Network conditions**: Test on slow/unstable Wi-Fi
+- **Memory pressure**: Test with many apps open
+- **Touch responsiveness**: Actual finger input vs mouse clicks
+
+### Before Release Testing
+
+Always test on physical devices before any release:
+
+1. Fresh install (not upgrade)
+2. Upgrade from previous version
+3. Test on lowest supported Android version
+4. Test on both phone and tablet if applicable
+
+## Quick Reference
+
+### Essential Commands
+
+```bash
+# Check connected devices
+adb devices
+
+# Build and run (debug)
+npm run build:android:debug:run
+
+# Build and run (test environment)
+npm run build:android:test:run
+
+# Install existing APK
+adb install -r android/app/build/outputs/apk/debug/app-debug.apk
+
+# Uninstall app
+adb uninstall app.timesafari.app
+
+# Launch app
+adb shell am start -n app.timesafari.app/app.timesafari.MainActivity
+
+# View logs
+adb logcat | grep TimeSafari
+
+# Take screenshot
+adb exec-out screencap -p > screenshot.png
+
+# Record screen
+adb shell screenrecord /sdcard/demo.mp4
+# (Ctrl+C to stop, then pull file)
+adb pull /sdcard/demo.mp4
+```
+
+### Build Modes Quick Reference
+
+| Command | Environment | API Servers |
+|---------|-------------|-------------|
+| `npm run build:android:dev` | Development | Local (your IP:3000) |
+| `npm run build:android:test` | Test | test-api.endorser.ch |
+| `npm run build:android:prod` | Production | api.endorser.ch |
+
+## Conclusion
+
+Physical device testing is essential for:
+- ✅ Real-world performance validation
+- ✅ Touch and gesture testing
+- ✅ Camera and hardware feature testing
+- ✅ Network condition testing
+- ✅ Battery and resource usage analysis
+
+For emulator-based testing (useful for quick iteration), see [Android Emulator Deployment Guide](android-emulator-deployment-guide.md).
+
+For questions or additional troubleshooting, refer to the main [BUILDING.md](../BUILDING.md) documentation.

doc/consuming-app-handoff-ios-native-fetcher-chained-dual.md

@@ -0,0 +1,80 @@
+# Consuming app handoff: iOS native fetcher + chained dual (mirror)
+
+**Canonical source:** `daily-notification-plugin` repo, `doc/CONSUMING_APP_HANDOFF_IOS_NATIVE_FETCHER_AND_CHAINED_DUAL.md` (same content as below for offline use).
+
+---
+
+## Implemented in this app
+
+- **`ios/App/App/TimeSafariNativeFetcher.swift`** — Swift `NativeNotificationContentFetcher` mirroring `TimeSafariNativeFetcher.java` (`POST …/plansLastUpdatedBetween`, starred IDs from `daily_notification_timesafari.starredPlanIds`, JWT pool selection, pagination key `daily_notification_timesafari.last_acked_jwt_id`, aggregated copy).
+- **`AppDelegate.swift`** — `DailyNotificationPlugin.registerNativeFetcher(TimeSafariNativeFetcher.shared)` at launch **before** any JS `configureNativeFetcher`; foreground handler reads `scheduled_time` as `Int64`, `NSNumber`, or `Int` for `DailyNotificationDelivered`.
+
+## Dependency
+
+- **`@timesafari/daily-notification-plugin`** must be **≥ 3.0.0** (register native fetcher, chained dual, iOS `updateStarredPlans`). Declare it in `package.json` from the official remote (`git+https://gitea.anomalistdesign.com/trent_larson/daily-notification-plugin.git`, branch or tag as needed), then `npm install` so `package-lock.json` resolves the published tree.
+
+## Bump / sync (after plugin version is resolved)
+
+1. `npm install`
+2. `npx cap sync ios && npx cap sync android`
+3. `cd ios/App && pod install`
+4. Clean build in Xcode / Android Studio
+
+## QA focus
+
+- iOS: Fetcher registered before `configureNativeFetcher`; `updateStarredPlans` not `UNIMPLEMENTED`.
+- Both: New Activity fires **after** prefetch for that cycle where the plugin implements chaining.
+- Android: Existing `MainActivity.setNativeFetcher` unchanged; regression-test `cancelDualSchedule` vs Daily Reminder.
+
+---
+
+## Original handoff text (from plugin)
+
+This document is for the **host app** repository (e.g. crowd-funder-for-time-pwa) after bumping `@timesafari/daily-notification-plugin` to a version that includes:
+
+- **iOS** `NativeNotificationContentFetcher`–style registration (`DailyNotificationPlugin.registerNativeFetcher`)
+- **iOS** `updateStarredPlans` / `getStarredPlans` (parity with Android `daily_notification_timesafari` / `starredPlanIds` semantics)
+- **iOS** chained dual flow: user notification is **armed only after** prefetch completes (delay if fetch is late; max slip 15 minutes before fallback copy)
+- **Android** chained dual flow: exact **notify** alarm is scheduled **after** dual prefetch completes (no longer scheduled at initial `scheduleDualNotification` before fetch)
+
+Material from `doc/new-activity-notifications-ios-android-parity.md` still applies; the plugin doc adds **app-side** steps not spelled out there.
+
+### 1. iOS — register native fetcher before `configureNativeFetcher`
+
+The plugin **rejects** `configureNativeFetcher` if no fetcher is registered (aligned with Android).
+
+**In `AppDelegate` (or earliest app startup before Capacitor calls into the plugin):**
+
+```swift
+import TimesafariDailyNotificationPlugin
+
+DailyNotificationPlugin.registerNativeFetcher(TimeSafariNativeFetcher.shared)
+```
+
+Implement **`TimeSafariNativeFetcher`** as a Swift type that:
+
+- Conforms to `NativeNotificationContentFetcher`
+- Implements `fetchContent(context: FetchContext) async throws -> [NotificationContent]` with the same **Endorser** behavior as `TimeSafariNativeFetcher.java`
+- Implements `configure(apiBaseUrl:activeDid:jwtToken:jwtTokenPool:)` if the fetcher needs credentials pushed from TypeScript
+
+**Starred plan IDs for the fetcher:** Read JSON array string from UserDefaults key **`daily_notification_timesafari.starredPlanIds`** (written by `updateStarredPlans` from JS).
+
+### 2. iOS — `UNUserNotificationCenterDelegate` / rollover
+
+Chained dual notifications set:
+
+- `notification_id` = `org.timesafari.dailynotification.dual`
+- `scheduled_time` = `NSNumber` (fire time in ms)
+
+Ensure **`DailyNotificationDelivered`** forwards **`notification_id`** and **`scheduled_time`** from **notification content `userInfo`**.
+
+### 3. Android — no API change for `setNativeFetcher`
+
+Host apps that already call `DailyNotificationPlugin.setNativeFetcher(TimeSafariNativeFetcher(...))` keep that flow.
+
+**Behavior change:** the dual **notify** alarm is scheduled when **dual prefetch work finishes**, not at the initial `scheduleDualNotification` only.
+
+### 4. Assumptions
+
+- Swift host implements `TimeSafariNativeFetcher`; the plugin does **not** embed `plansLastUpdatedBetween` on iOS when a host fetcher is registered (mirrors Android).
+- Module import: `TimesafariDailyNotificationPlugin` (Pod `TimesafariDailyNotificationPlugin`).

doc/daily-notification-alignment-outline.md

@@ -0,0 +1,105 @@
+# Daily Notification Plugin: Alignment Outline
+
+**Purpose:** Checklist of changes/additions needed in this app to align with the test app (`daily-notification-plugin/test-apps/daily-notification-test`) so that:
+
+1. **Rollover recovery** (and rollover itself) works.
+2. **Notifications show when the app is in the foreground** (not only background/closed).
+3. **Plugin loads at app launch** so recovery runs after reboot without the user opening notification UI.
+
+**Reference:** In the **daily-notification-plugin** repository, the test app lives at `test-apps/daily-notification-test` (same repo as `https://gitea.anomalistdesign.com/trent_larson/daily-notification-plugin`).
+
+---
+
+## 1. iOS AppDelegate
+
+**File:** `ios/App/App/AppDelegate.swift`
+
+### 1.1 Add imports
+
+- [ ] `import UserNotifications`
+- [ ] Import the Daily Notification plugin framework (Swift module name: **TimesafariDailyNotificationPlugin** per this app’s Podfile; test app uses **DailyNotificationPlugin**)
+
+### 1.2 Conform to `UNUserNotificationCenterDelegate`
+
+- [ ] Add `, UNUserNotificationCenterDelegate` to the class declaration:  
+  `class AppDelegate: UIResponder, UIApplicationDelegate, UNUserNotificationCenterDelegate`
+
+### 1.3 Force-load plugin at launch
+
+- [ ] In `application(_:didFinishLaunchingWithOptions:)`, **before** other setup, add logic to force-load the plugin class (e.g. `_ = DailyNotificationPlugin.self` or the class exposed by the TimesafariDailyNotificationPlugin pod) so that the plugin’s `load()` (and thus `performRecovery()`) runs at app launch, not only when JS first calls the plugin.
+
+### 1.4 Set notification center delegate
+
+- [ ] In `didFinishLaunchingWithOptions`, set:  
+  `UNUserNotificationCenter.current().delegate = self`
+- [ ] In `applicationDidBecomeActive`, **re-set** the same delegate (in case Capacitor or another component clears it).
+
+### 1.5 Implement `userNotificationCenter(_:willPresent:withCompletionHandler:)`
+
+- [ ] When a notification is delivered (including in foreground), read `notification_id` and `scheduled_time` from `notification.request.content.userInfo`.
+- [ ] Post rollover event:  
+  `NotificationCenter.default.post(name: NSNotification.Name("DailyNotificationDelivered"), object: nil, userInfo: ["notification_id": id, "scheduled_time": scheduledTime])`
+- [ ] Call completion handler with presentation options so the notification is shown in foreground, e.g.  
+  `completionHandler([.banner, .sound, .badge])` (use `.alert` on iOS 13 if needed).
+
+### 1.6 Implement `userNotificationCenter(_:didReceive:withCompletionHandler:)`
+
+- [ ] Handle notification tap/interaction; call `completionHandler()` when done.
+
+---
+
+## 2. Android Manifest
+
+**File:** `android/app/src/main/AndroidManifest.xml`
+
+### 2.1 Fix receiver placement
+
+- [ ] Move the two `<receiver>` elements (**DailyNotificationReceiver** and **BootReceiver**) **inside** the `<application>` block (e.g. after `<activity>...</activity>` and before `<provider>...</provider>`).
+- [ ] Remove the stray second `</application>` so there is a single `<application>...</application>` containing activity, receivers, and provider.
+
+### 2.2 (Optional) Add NotifyReceiver
+
+- [ ] If the plugin’s Android integration expects **NotifyReceiver** for alarm-based delivery, add a `<receiver>` for `org.timesafari.dailynotification.NotifyReceiver` inside `<application>` (see test app manifest for exact declaration).
+
+### 2.3 (Optional) BootReceiver options
+
+- [ ] Consider aligning with test app: add `android:directBootAware="true"`, `android:exported="true"`, and intent-filter actions `LOCKED_BOOT_COMPLETED`, `MY_PACKAGE_REPLACED`, `PACKAGE_REPLACED` if you need the same boot/update behavior.
+
+---
+
+## 3. Capacitor / JS startup (optional but recommended)
+
+**File:** `src/main.capacitor.ts` (or the main entry used for native builds)
+
+### 3.1 Load plugin at startup
+
+- [ ] Add a top-level import or an early call that touches the Daily Notification plugin so the JS side loads it at app startup (e.g. `import "@timesafari/daily-notification-plugin"` or a small init that calls `getRebootRecoveryStatus()` or `configure()`).  
+  This ensures the plugin is loaded as soon as the app runs; together with the iOS force-load in AppDelegate, recovery runs at launch.
+
+---
+
+## 4. Plugin configuration (optional)
+
+- [ ] If you use the native fetcher or need plugin config (db path, storage, etc.), call `DailyNotification.configure()` and/or `configureNativeFetcher()` when appropriate (e.g. after login or when notification UI is first used), similar to the test app’s `configureNativeFetcher()` in HomeView.
+
+---
+
+## 5. Summary table
+
+| Area                    | Change / addition                                                                 |
+|-------------------------|------------------------------------------------------------------------------------|
+| **iOS AppDelegate**     | Conform to `UNUserNotificationCenterDelegate`; set delegate; force-load plugin; implement `willPresent` (post `DailyNotificationDelivered` + show in foreground) and `didReceive`. |
+| **Android manifest**    | Move DailyNotificationReceiver and BootReceiver inside `<application>`; remove duplicate `</application>`; optionally add NotifyReceiver and BootReceiver options. |
+| **main.capacitor.ts**  | Optionally import or call plugin at startup so it (and recovery) load at launch.  |
+| **Plugin config**      | Optionally call `configure()` / `configureNativeFetcher()` where appropriate.     |
+
+---
+
+## 6. Verification
+
+After making the changes:
+
+- [ ] **iOS:** Build and run; trigger a daily notification and confirm it appears when the app is in the foreground.
+- [ ] **iOS:** Confirm rollover (next day’s schedule) still occurs after a notification fires (check logs for `DNP-ROLLOVER` / `DailyNotificationDelivered`).
+- [ ] **iOS:** Restart the app (or reboot) and confirm recovery runs without opening the notification settings screen (e.g. logs show plugin load and recovery).
+- [ ] **Android:** Build and run; confirm receivers are registered (no manifest errors) and that notifications and boot recovery behave as expected.

doc/daily-notification-plugin-android-receiver-issue.md

@@ -0,0 +1,251 @@
+# Daily Notification Plugin - Android Receiver Not Triggered by AlarmManager
+
+**Date**: 2026-02-02  
+**Status**: ✅ Resolved (2026-02-06)  
+**Plugin**: @timesafari/daily-notification-plugin  
+**Platform**: Android  
+**Issue**: AlarmManager fires alarms but DailyNotificationReceiver is not receiving broadcasts
+
+---
+
+## Resolution (2026-02-06)
+
+The bug was fixed in the plugin repository. The plugin now:
+
+- Creates the PendingIntent with the receiver component explicitly set (`setComponent(ComponentName(context, DailyNotificationReceiver::class.java))`), so AlarmManager delivers the broadcast to the receiver.
+- Adds the schedule ID to the Intent extras (`intent.putExtra("id", scheduleId)`), resolving the `missing_id` error.
+
+**In this app after pulling the fix:**
+
+1. Run `npm install` to get the latest plugin from `#master`.
+2. Run `npx cap sync` so the Android (and iOS) native projects get the updated plugin code.
+3. Run `node scripts/restore-local-plugins.js` if you use local plugins (e.g. SafeArea, SharedImage).
+4. Rebuild and run on Android, then verify using the [Testing Steps for Plugin Fix](#testing-steps-for-plugin-fix) below.
+</think>
+
+---
+
+## Problem Summary
+
+Alarms are being scheduled successfully and fire at the correct time, but the `DailyNotificationReceiver` is not being triggered when AlarmManager delivers the broadcast. Manual broadcasts to the receiver work correctly, indicating the receiver itself is functional.
+
+---
+
+## What Works ✅
+
+1. **Receiver Registration**: The receiver is properly registered in AndroidManifest.xml with `exported="true"`
+2. **Manual Broadcasts**: Manually triggering the receiver via `adb shell am broadcast` successfully triggers it
+3. **Alarm Scheduling**: Alarms are successfully scheduled via `setAlarmClock()` and appear in `dumpsys alarm`
+4. **Alarm Firing**: Alarms fire at the scheduled time (confirmed by alarm disappearing from dumpsys)
+
+---
+
+## What Doesn't Work ❌
+
+1. **Automatic Receiver Triggering**: When AlarmManager fires the alarm, the broadcast PendingIntent does not reach the receiver
+2. **No Logs on Alarm Fire**: No `DN|RECEIVE_START` logs appear when alarms fire automatically
+3. **Missing ID in Intent**: When manually tested, receiver shows `DN|RECEIVE_ERR missing_id` (separate issue but related)
+
+---
+
+## Technical Details
+
+### Receiver Configuration
+
+**File**: `android/app/src/main/AndroidManifest.xml`
+
+```xml
+<receiver
+    android:name="org.timesafari.dailynotification.DailyNotificationReceiver"
+    android:enabled="true"
+    android:exported="true">
+    <intent-filter>
+        <action android:name="org.timesafari.daily.NOTIFICATION" />
+    </intent-filter>
+</receiver>
+```
+
+- ✅ `exported="true"` is set (required for AlarmManager broadcasts)
+- ✅ Intent action matches: `org.timesafari.daily.NOTIFICATION`
+- ✅ Receiver is inside `<application>` tag
+
+### Alarm Scheduling Evidence
+
+From logs when scheduling (23:51:32):
+```
+I DNP-SCHEDULE: Scheduling OS alarm: variant=ALARM_CLOCK, action=org.timesafari.daily.NOTIFICATION, triggerTime=1770105300000, requestCode=44490, scheduleId=timesafari_daily_reminder
+I DNP-NOTIFY: Alarm clock scheduled (setAlarmClock): triggerAt=1770105300000, requestCode=44490
+```
+
+From `dumpsys alarm` output:
+```
+RTC_WAKEUP #36: Alarm{7a8fb5e type 0 origWhen 1770148800000 whenElapsed 122488536 app.timesafari.app}
+  tag=*walarm*:org.timesafari.daily.NOTIFICATION
+  type=RTC_WAKEUP origWhen=2026-02-03 12:00:00.000 window=0 exactAllowReason=policy_permission
+  operation=PendingIntent{6fce955: PendingIntentRecord{5856f6a app.timesafari.app broadcastIntent}}
+```
+
+### Alarm Firing Evidence
+
+- Alarm scheduled for 23:55:00 (timestamp: 1770105300000)
+- At 23:55:00, alarm is no longer in `dumpsys alarm` (confirmed it fired)
+- **No `DN|RECEIVE_START` log at 23:55:00** (receiver was not triggered)
+
+### Manual Broadcast Test (Works)
+
+```bash
+adb shell am broadcast -a org.timesafari.daily.NOTIFICATION -n app.timesafari.app/org.timesafari.dailynotification.DailyNotificationReceiver
+```
+
+**Result**: ✅ Receiver triggered successfully
+```
+02-02 23:46:07.505  DailyNotificationReceiver  D  DN|RECEIVE_START action=org.timesafari.daily.NOTIFICATION
+02-02 23:46:07.506  DailyNotificationReceiver  W  DN|RECEIVE_ERR missing_id
+```
+
+---
+
+## Root Cause Analysis
+
+The issue appears to be in how the PendingIntent is created when scheduling alarms. Possible causes:
+
+### Hypothesis 1: PendingIntent Not Targeting Receiver Correctly
+
+The PendingIntent may be created without explicitly specifying the component, causing Android to not match it to the receiver when the alarm fires.
+
+**Expected Fix**: When creating the PendingIntent for AlarmManager, explicitly set the component:
+
+```kotlin
+val intent = Intent("org.timesafari.daily.NOTIFICATION").apply {
+    setComponent(ComponentName(context, DailyNotificationReceiver::class.java))
+    putExtra("id", scheduleId) // Also fix missing_id issue
+}
+val pendingIntent = PendingIntent.getBroadcast(
+    context,
+    requestCode,
+    intent,
+    PendingIntent.FLAG_UPDATE_CURRENT or PendingIntent.FLAG_IMMUTABLE
+)
+```
+
+### Hypothesis 2: PendingIntent Flags Issue
+
+The PendingIntent may be created with incorrect flags that prevent delivery when the app is in certain states.
+
+**Check**: Ensure flags include:
+- `FLAG_UPDATE_CURRENT` or `FLAG_CANCEL_CURRENT`
+- `FLAG_IMMUTABLE` (required on Android 12+)
+
+### Hypothesis 3: Package/Component Mismatch
+
+The PendingIntent may be created with a different package name or component than what's registered in the manifest.
+
+**Check**: Verify the package name in the Intent matches `app.timesafari.app` and the component matches the receiver class.
+
+---
+
+## Additional Issue: Missing ID in Intent
+
+When the receiver IS triggered (manually), it shows:
+```
+DN|RECEIVE_ERR missing_id
+```
+
+This indicates the Intent extras don't include the `scheduleId`. The plugin should add the ID to the Intent when creating the PendingIntent:
+
+```kotlin
+intent.putExtra("id", scheduleId)
+// or
+intent.putExtra("scheduleId", scheduleId) // if receiver expects different key
+```
+
+---
+
+## Testing Steps for Plugin Fix
+
+1. **Verify PendingIntent Creation**:
+   - Check the code that creates PendingIntent for AlarmManager
+   - Ensure component is explicitly set
+   - Ensure ID is added to Intent extras
+
+2. **Test Alarm Delivery**:
+   - Schedule an alarm for 1-2 minutes in the future
+   - Monitor logs: `adb logcat | grep -E "DN|RECEIVE_START|DailyNotification"`
+   - Verify `DN|RECEIVE_START` appears when alarm fires
+   - Verify no `missing_id` error
+
+3. **Test Different App States**:
+   - App in foreground
+   - App in background
+   - App force-closed
+   - Device in doze mode (if possible on emulator)
+
+4. **Compare with Manual Broadcast**:
+   - Manual broadcast works → receiver is fine
+   - Alarm broadcast doesn't work → PendingIntent creation is the issue
+
+---
+
+## Files to Check in Plugin
+
+1. **Alarm Scheduling Code**: Where `setAlarmClock()` or `setExact()` is called
+2. **PendingIntent Creation**: Where `PendingIntent.getBroadcast()` is called
+3. **Intent Creation**: Where the Intent for the alarm is created
+4. **Receiver Code**: Verify what Intent extras it expects (for missing_id fix)
+
+---
+
+## Related Configuration
+
+### AndroidManifest.xml (App Side)
+- ✅ Receiver exported="true"
+- ✅ Correct intent action
+- ✅ Receiver inside application tag
+
+### Permissions (App Side)
+- ✅ POST_NOTIFICATIONS
+- ✅ SCHEDULE_EXACT_ALARM
+- ✅ RECEIVE_BOOT_COMPLETED
+- ✅ WAKE_LOCK
+- ❌ USE_EXACT_ALARM -- must not use; see note below
+
+> **Note on `USE_EXACT_ALARM`:** The `USE_EXACT_ALARM` permission is restricted
+> by Google on Android. Apps that declare it must be primarily dedicated to alarm
+> or calendar functionality. Google will reject apps from the Play Store that use
+> this permission for other purposes. This plugin uses `SCHEDULE_EXACT_ALARM`
+> instead, which is sufficient for scheduling daily notifications.
+
+---
+
+## Expected Behavior After Fix
+
+When an alarm fires:
+1. AlarmManager delivers the broadcast
+2. `DailyNotificationReceiver.onReceive()` is called
+3. Log shows: `DN|RECEIVE_START action=org.timesafari.daily.NOTIFICATION`
+4. Receiver finds the ID in Intent extras (no `missing_id` error)
+5. Notification is displayed
+
+---
+
+## Notes
+
+- The `exported="true"` change in the app's manifest was necessary and correct
+- The issue is in the plugin's PendingIntent creation, not the app configuration
+- Manual broadcasts work, proving the receiver registration is correct
+- Alarms fire, proving AlarmManager scheduling is correct
+- The gap is in the PendingIntent → Receiver delivery
+
+---
+
+## Quick Reference: Working Manual Test
+
+```bash
+# This works - receiver is triggered
+adb shell am broadcast \
+  -a org.timesafari.daily.NOTIFICATION \
+  -n app.timesafari.app/org.timesafari.dailynotification.DailyNotificationReceiver \
+  --es "id" "timesafari_daily_reminder"
+```
+
+The plugin's PendingIntent should create an equivalent broadcast that AlarmManager can deliver.

doc/daily-notification-plugin-architecture.md

@@ -0,0 +1,312 @@
+# Daily Notification Plugin - Architecture Overview
+
+## System Architecture
+
+```
+┌─────────────────────────────────────────────────────────────────┐
+│                        Vue Components                            │
+│  (PushNotificationPermission.vue, AccountViewView.vue, etc.)    │
+└───────────────────────────┬─────────────────────────────────────┘
+                            │
+                            ▼
+┌─────────────────────────────────────────────────────────────────┐
+│              NotificationService (Factory)                       │
+│           - Platform detection via Capacitor API                 │
+│           - Singleton pattern                                    │
+│           - Returns appropriate implementation                   │
+└───────────────────────────┬─────────────────────────────────────┘
+                            │
+                ┌───────────┴────────────┐
+                ▼                        ▼
+┌───────────────────────────┐  ┌────────────────────────────┐
+│ NativeNotificationService │  │ WebPushNotificationService │
+│                           │  │                            │
+│ iOS/Android               │  │ Web/PWA                    │
+│ - UNUserNotificationCenter│  │ - Web Push API             │
+│ - NotificationManager     │  │ - Service Workers          │
+│ - AlarmManager            │  │ - VAPID keys               │
+│ - Background tasks        │  │ - Push server              │
+└─────────────┬─────────────┘  └────────────┬───────────────┘
+              │                              │
+              ▼                              ▼
+┌─────────────────────────┐  ┌──────────────────────────────┐
+│  DailyNotificationPlugin│  │  Existing Web Push Logic     │
+│  (Capacitor Plugin)     │  │  (PushNotificationPermission)│
+│                         │  │                              │
+│  - Native iOS code      │  │  - Service worker            │
+│  - Native Android code  │  │  - VAPID subscription        │
+│  - SQLite storage       │  │  - Push server integration   │
+└─────────────────────────┘  └──────────────────────────────┘
+```
+
+## Platform Decision Flow
+
+```
+User Action: Schedule Notification
+         │
+         ▼
+   NotificationService.getInstance()
+         │
+         ├──> Check: Capacitor.isNativePlatform()
+         │
+    ┌────┴─────┐
+    │          │
+   YES        NO
+    │          │
+    ▼          ▼
+Native      Web/PWA
+Service     Service
+    │          │
+    ▼          ▼
+Plugin      Web Push
+```
+
+## Data Flow Example: Scheduling a Notification
+
+### Native Platform (iOS/Android)
+```
+1. User clicks "Enable Notifications"
+   │
+2. PushNotificationPermission.vue
+   │
+   └─> NotificationService.getInstance()
+       │
+       └─> Returns NativeNotificationService (detected iOS/Android)
+           │
+           └─> nativeService.requestPermissions()
+               │
+               └─> DailyNotification.requestPermissions() [Capacitor Plugin]
+                   │
+                   └─> Native code requests OS permissions
+                       │
+                       └─> Returns: { granted: true/false }
+
+3. User sets time & message
+   │
+4. nativeService.scheduleDailyNotification({ time: '09:00', ... })
+   │
+   └─> DailyNotification.scheduleDailyReminder({ ... })
+       │
+       └─> Native code:
+           - Stores in SQLite
+           - Schedules AlarmManager (Android) or UNNotificationRequest (iOS)
+           - Returns: success/failure
+
+5. At 9:00 AM:
+   - Android: AlarmManager triggers → DailyNotificationReceiver
+   - iOS: UNUserNotificationCenter triggers notification
+   - Notification appears even if app is closed
+```
+
+### Web Platform
+```
+1. User clicks "Enable Notifications"
+   │
+2. PushNotificationPermission.vue
+   │
+   └─> NotificationService.getInstance()
+       │
+       └─> Returns WebPushNotificationService (detected web)
+           │
+           └─> webService.requestPermissions()
+               │
+               └─> Notification.requestPermission() [Browser API]
+                   │
+                   └─> Returns: 'granted'/'denied'/'default'
+
+3. User sets time & message
+   │
+4. webService.scheduleDailyNotification({ ... })
+   │
+   └─> [TODO] Subscribe to push service with VAPID
+       │
+       └─> Send subscription to server with schedule time
+           │
+           └─> Server sends push at scheduled time
+               │
+               └─> Service worker receives → shows notification
+```
+
+## File Organization
+
+```
+src/
+├── plugins/
+│   └── DailyNotificationPlugin.ts          [Plugin registration]
+│
+├── services/
+│   └── notifications/
+│       ├── index.ts                        [Barrel export]
+│       ├── NotificationService.ts          [Factory + Interface]
+│       ├── NativeNotificationService.ts    [iOS/Android impl]
+│       └── WebPushNotificationService.ts   [Web impl stub]
+│
+├── components/
+│   └── PushNotificationPermission.vue      [UI - to be updated]
+│
+└── views/
+    └── AccountViewView.vue                 [Settings UI]
+```
+
+## Key Design Decisions
+
+### 1. **Unified Interface**
+- Single `NotificationServiceInterface` for all platforms
+- Consistent API regardless of underlying implementation
+- Type-safe across TypeScript codebase
+
+### 2. **Runtime Platform Detection**
+- No build-time configuration needed
+- Same code bundle for all platforms
+- Factory pattern selects implementation automatically
+
+### 3. **Coexistence Strategy**
+- Web Push and Native run on different platforms
+- No conflicts - mutually exclusive at runtime
+- Allows gradual migration and testing
+
+### 4. **Singleton Pattern**
+- One service instance per app lifecycle
+- Efficient resource usage
+- Consistent state management
+
+## Permission Flow
+
+### Android
+```
+App Launch
+  ↓
+Check if POST_NOTIFICATIONS granted (API 33+)
+  │
+  ├─> YES: Ready to schedule
+  │
+  └─> NO: Request runtime permission
+          ↓
+      Show system dialog
+          ↓
+      User grants/denies
+          ↓
+      Schedule notifications (if granted)
+```
+
+### iOS
+```
+App Launch
+  ↓
+Check notification authorization status
+  │
+  ├─> authorized: Ready to schedule
+  │
+  ├─> notDetermined: Request permission
+  │       ↓
+  │   Show system dialog
+  │       ↓
+  │   User grants/denies
+  │
+  └─> denied: Guide user to Settings
+```
+
+### Web
+```
+App Load
+  ↓
+Check Notification.permission
+  │
+  ├─> "granted": Ready to subscribe
+  │
+  ├─> "default": Request permission
+  │       ↓
+  │   Show browser prompt
+  │       ↓
+  │   User grants/denies
+  │
+  └─> "denied": Cannot show notifications
+```
+
+## Error Handling Strategy
+
+```typescript
+// All methods return promises with success/failure
+try {
+  const granted = await service.requestPermissions();
+  if (granted) {
+    const success = await service.scheduleDailyNotification({...});
+    if (success) {
+      // Show success message
+    } else {
+      // Show scheduling error
+    }
+  } else {
+    // Show permission denied message
+  }
+} catch (error) {
+  // Log error and show generic error message
+  logger.error('Notification error:', error);
+}
+```
+
+## Background Execution
+
+### Native (iOS/Android)
+- ✅ Full background support
+- ✅ Survives app termination
+- ✅ Survives device reboot (with BootReceiver)
+- ✅ Exact alarm scheduling
+- ✅ Works offline
+
+### Web/PWA
+- ⚠️ Limited background support
+- ⚠️ Requires active service worker
+- ⚠️ Browser/OS dependent
+- ❌ Needs network for delivery
+- ⚠️ iOS: Only on Home Screen PWAs (16.4+)
+
+## Storage
+
+### Native
+```
+DailyNotificationPlugin
+    ↓
+SQLite Database (Room/Core Data)
+    ↓
+Stores:
+- Schedule configurations
+- Content cache
+- Delivery history
+- Callback registrations
+```
+
+### Web
+```
+Web Push
+    ↓
+IndexedDB (via Dexie)
+    ↓
+Stores:
+- Settings (notifyingNewActivityTime, etc.)
+- Push subscription info
+- VAPID keys
+```
+
+## Testing Strategy
+
+### Unit Testing
+- Mock `Capacitor.isNativePlatform()` to test both paths
+- Test factory returns correct implementation
+- Test each service implementation independently
+
+### Integration Testing
+- Test on actual devices (iOS/Android)
+- Test in browsers (Chrome, Safari, Firefox)
+- Verify notification delivery
+- Test permission flows
+
+### E2E Testing
+- Schedule notification → Wait → Verify delivery
+- Test app restart scenarios
+- Test device reboot scenarios
+- Test permission denial recovery
+
+---
+
+**Key Takeaway**: The architecture provides a clean separation between platforms while maintaining a unified API for Vue components. Platform detection happens automatically at runtime, and the appropriate notification system is used transparently.

doc/daily-notification-plugin-checklist.md

@@ -0,0 +1,348 @@
+# Daily Notification Plugin - Integration Checklist
+
+**Integration Date**: 2026-01-21  
+**Plugin Version**: 1.0.11  
+**Status**: Phase 1 Complete ✅
+
+---
+
+## Phase 1: Infrastructure Setup ✅ COMPLETE
+
+### Code Files
+- [x] Created `src/plugins/DailyNotificationPlugin.ts`
+- [x] Created `src/services/notifications/NotificationService.ts`
+- [x] Created `src/services/notifications/NativeNotificationService.ts`
+- [x] Created `src/services/notifications/WebPushNotificationService.ts`
+- [x] Created `src/services/notifications/index.ts`
+
+### Android Configuration
+
+> **Note on `USE_EXACT_ALARM`:** The `USE_EXACT_ALARM` permission is restricted
+> by Google on Android. Apps that declare it must be primarily dedicated to alarm
+> or calendar functionality. Google will reject apps from the Play Store that use
+> this permission for other purposes. This plugin uses `SCHEDULE_EXACT_ALARM`
+> instead, which is sufficient for scheduling daily notifications.
+
+- [x] Added permissions to `AndroidManifest.xml`:
+  - [x] `POST_NOTIFICATIONS`
+  - [x] `SCHEDULE_EXACT_ALARM`
+  - [x] `RECEIVE_BOOT_COMPLETED`
+  - [x] `WAKE_LOCK`
+  - [ ] `USE_EXACT_ALARM` -- must avoid; see note above
+- [x] Registered receivers in `AndroidManifest.xml`:
+  - [x] `DailyNotificationReceiver`
+  - [x] `BootReceiver`
+- [x] Added dependencies to `build.gradle`:
+  - [x] Room (`androidx.room:room-runtime:2.6.1`)
+  - [x] WorkManager (`androidx.work:work-runtime-ktx:2.9.0`)
+  - [x] Coroutines (`org.jetbrains.kotlinx:kotlinx-coroutines-android:1.7.3`)
+  - [x] Room Compiler (`androidx.room:room-compiler:2.6.1`)
+- [x] Registered plugin in `MainActivity.java`
+
+### iOS Configuration
+- [x] Added to `Info.plist`:
+  - [x] `UIBackgroundModes` (fetch, processing)
+  - [x] `BGTaskSchedulerPermittedIdentifiers`
+  - [x] `NSUserNotificationAlertStyle`
+- [ ] ⚠️ **MANUAL STEP**: Xcode capabilities (see Phase 5)
+
+### Documentation
+- [x] Created `doc/daily-notification-plugin-integration.md`
+- [x] Created `doc/daily-notification-plugin-integration-summary.md`
+- [x] Created `doc/daily-notification-plugin-architecture.md`
+- [x] Created this checklist
+
+---
+
+## Phase 2: UI Integration ⏳ TODO
+
+### Update Components
+- [ ] Modify `PushNotificationPermission.vue`:
+  - [ ] Import `NotificationService`
+  - [ ] Replace direct web push calls with service methods
+  - [ ] Add platform-aware messaging
+  - [ ] Test permission flow
+  - [ ] Test notification scheduling
+
+### Update Views
+- [ ] Update `AccountViewView.vue`:
+  - [ ] Use `NotificationService` for status checks
+  - [ ] Add platform indicator
+  - [ ] Test settings display
+  
+### Settings Integration
+- [ ] Verify settings save/load correctly:
+  - [ ] `notifyingNewActivityTime` for native
+  - [ ] `notifyingReminderMessage` for native
+  - [ ] `notifyingReminderTime` for native
+  - [ ] Existing web push settings preserved
+
+---
+
+## Phase 3: Web Push Integration ⏳ TODO
+
+### Wire WebPushNotificationService
+- [ ] Extract subscription logic from `PushNotificationPermission.vue`
+- [ ] Implement `scheduleDailyNotification()` method
+- [ ] Implement `cancelDailyNotification()` method
+- [ ] Implement `getStatus()` method
+- [ ] Test web platform notification flow
+
+### Server Integration
+- [ ] Verify web push server endpoints still work
+- [ ] Test subscription/unsubscription
+- [ ] Test scheduled message delivery
+
+---
+
+## Phase 4: Testing ⏳ TODO
+
+### Desktop Development
+- [ ] Code compiles without errors
+- [ ] ESLint passes
+- [ ] TypeScript types are correct
+- [ ] Platform detection works in browser console
+
+### Android Emulator
+- [ ] App builds successfully
+- [ ] Plugin loads without errors
+- [ ] Can open app and navigate
+- [ ] No JavaScript console errors
+
+### Android Device (Real)
+- [ ] Request permissions dialog appears
+- [ ] Permissions can be granted
+- [ ] Schedule notification succeeds
+- [ ] Notification appears at scheduled time
+- [ ] Notification survives app close
+- [ ] Notification survives device reboot
+- [ ] Notification can be cancelled
+
+### iOS Simulator
+- [ ] App builds successfully
+- [ ] Plugin loads without errors
+- [ ] Can open app and navigate
+- [ ] No JavaScript console errors
+
+### iOS Device (Real)
+- [ ] Request permissions dialog appears
+- [ ] Permissions can be granted
+- [ ] Schedule notification succeeds
+- [ ] Notification appears at scheduled time
+- [ ] Background fetch works
+- [ ] Notification survives app close
+- [ ] Notification can be cancelled
+
+### Web Browser
+- [ ] Existing web push still works
+- [ ] No JavaScript errors
+- [ ] Platform detection selects web service
+- [ ] Permission flow works
+- [ ] Subscription works
+
+---
+
+## Phase 5: iOS Xcode Setup ⚠️ MANUAL REQUIRED
+
+### Open Xcode Project
+```bash
+cd ios
+open App/App.xcodeproj
+```
+
+### Configure Capabilities
+- [ ] Select "App" target in project navigator
+- [ ] Go to "Signing & Capabilities" tab
+- [ ] Click "+ Capability" button
+- [ ] Add "Background Modes":
+  - [ ] Enable "Background fetch"
+  - [ ] Enable "Background processing"
+- [ ] Click "+ Capability" button again
+- [ ] Add "Push Notifications" (if using remote notifications)
+
+### Install CocoaPods
+```bash
+cd ios
+pod install
+cd ..
+```
+- [ ] Run `pod install` successfully
+- [ ] Verify `CapacitorDailyNotification` pod is installed
+
+### Verify Configuration
+- [ ] Build succeeds in Xcode
+- [ ] No capability warnings
+- [ ] No pod errors
+- [ ] Can run on simulator
+
+---
+
+## Phase 6: Build & Deploy ⏳ TODO
+
+### Sync Capacitor
+```bash
+npx cap sync
+```
+- [ ] Sync completes without errors
+- [ ] Plugin files copied to native projects
+
+### Build Android
+```bash
+npm run build:android:debug
+```
+- [ ] Build succeeds
+- [ ] APK/AAB generated
+- [ ] Can install on device/emulator
+
+### Build iOS
+```bash
+npm run build:ios:debug
+```
+- [ ] Build succeeds
+- [ ] IPA generated (if release)
+- [ ] Can install on device/simulator
+
+### Test Production Builds
+- [ ] Android release build works
+- [ ] iOS release build works
+- [ ] Notifications work in production
+
+---
+
+## Troubleshooting Checklist
+
+### Android Issues
+
+#### Notifications Not Appearing
+- [ ] Verified `DailyNotificationReceiver` is in AndroidManifest.xml
+- [ ] Checked logcat for errors: `adb logcat | grep DailyNotification`
+- [ ] Verified permissions granted in app settings
+- [ ] Checked "Exact alarms" permission (Android 12+)
+- [ ] Verified notification channel is created
+
+#### Build Errors
+- [ ] Verified all dependencies in build.gradle
+- [ ] Ran `./gradlew clean` and rebuilt
+- [ ] Verified Kotlin version compatibility
+- [ ] Checked for conflicting dependencies
+
+### iOS Issues
+
+#### Notifications Not Appearing
+- [ ] Verified Background Modes enabled in Xcode
+- [ ] Checked Xcode console for errors
+- [ ] Verified permissions granted in Settings app
+- [ ] Tested on real device (not just simulator)
+- [ ] Checked BGTaskScheduler identifiers match Info.plist
+
+#### Build Errors
+- [ ] Ran `pod install` successfully
+- [ ] Verified deployment target is iOS 13.0+
+- [ ] Checked for pod conflicts
+- [ ] Cleaned build folder (Xcode → Product → Clean Build Folder)
+
+### Web Issues
+
+#### Web Push Not Working
+- [ ] Verified service worker is registered
+- [ ] Checked browser console for errors
+- [ ] Verified VAPID keys are correct
+- [ ] Tested in supported browser (Chrome 42+, Firefox)
+- [ ] Checked push server is running
+
+#### Permission Issues
+- [ ] Verified permissions not blocked in browser
+- [ ] Checked site settings in browser
+- [ ] Verified HTTPS connection (required for web push)
+
+---
+
+## Verification Commands
+
+### Check Plugin is Installed
+```bash
+npm list @timesafari/daily-notification-plugin
+```
+
+### Check Capacitor Sync
+```bash
+npx cap ls
+```
+
+### Check Android Build
+```bash
+cd android
+./gradlew clean
+./gradlew assembleDebug
+```
+
+### Check iOS Build
+```bash
+cd ios
+pod install
+xcodebuild -workspace App/App.xcworkspace -scheme App -configuration Debug build
+```
+
+### Check TypeScript
+```bash
+npm run type-check
+```
+
+### Check Linting
+```bash
+npm run lint
+```
+
+---
+
+## Next Immediate Actions
+
+1. **Run Capacitor Sync**:
+   ```bash
+   npx cap sync
+   ```
+
+2. **For iOS Development**:
+   ```bash
+   cd ios
+   open App/App.xcodeproj
+   # Enable Background Modes capability
+   pod install
+   cd ..
+   ```
+
+3. **Test on Emulator/Simulator**:
+   ```bash
+   npm run build:android:debug  # For Android
+   npm run build:ios:debug      # For iOS
+   ```
+
+4. **Update UI Components**:
+   - Start with `PushNotificationPermission.vue`
+   - Import and use `NotificationService`
+
+---
+
+## Success Criteria
+
+- [x] **Phase 1**: All files created and configurations applied
+- [ ] **Phase 2**: Components use NotificationService
+- [ ] **Phase 3**: Web push integrated with service
+- [ ] **Phase 4**: All tests pass on all platforms
+- [ ] **Phase 5**: iOS capabilities configured in Xcode
+- [ ] **Phase 6**: Production builds work on real devices
+
+---
+
+## Questions or Issues?
+
+See documentation:
+- Full guide: `doc/daily-notification-plugin-integration.md`
+- Architecture: `doc/daily-notification-plugin-architecture.md`
+- Summary: `doc/daily-notification-plugin-integration-summary.md`
+
+Plugin docs: `node_modules/@timesafari/daily-notification-plugin/README.md`
+
+---
+
+**Current Status**: Ready for Phase 2 (UI Integration) 🚀

doc/daily-notification-plugin-integration-summary.md

@@ -0,0 +1,193 @@
+# Daily Notification Plugin Integration - Summary
+
+**Date**: 2026-01-21  
+**Status**: ✅ Phase 1 Complete  
+**Next Phase**: UI Integration
+
+---
+
+## What Was Completed
+
+### ✅ Plugin Infrastructure
+1. **Plugin Registration**: `src/plugins/DailyNotificationPlugin.ts`
+   - Capacitor plugin registered with full TypeScript types
+   - Native-only (iOS/Android)
+
+2. **Service Abstraction**: `src/services/notifications/`
+   - `NotificationService.ts` - Platform detection & factory
+   - `NativeNotificationService.ts` - Native implementation
+   - `WebPushNotificationService.ts` - Web stub (for future)
+   - `index.ts` - Barrel export
+
+3. **Android Configuration**:
+   - ✅ Permissions added to `AndroidManifest.xml`
+   - ✅ Receivers registered (DailyNotificationReceiver, BootReceiver)
+   - ✅ Dependencies added to `build.gradle` (Room, WorkManager, Coroutines)
+   - ✅ Plugin registered in `MainActivity.java`
+
+4. **iOS Configuration**:
+   - ✅ Background modes added to `Info.plist`
+   - ✅ BGTaskScheduler identifiers configured
+   - ⚠️ **Requires manual Xcode setup** (capabilities)
+
+5. **Documentation**: `doc/daily-notification-plugin-integration.md`
+
+---
+
+## Platform Support
+
+| Platform | Notification System | Status |
+|----------|---------------------|--------|
+| **iOS** | Native (UNUserNotificationCenter) | ✅ Configured |
+| **Android** | Native (NotificationManager + AlarmManager) | ✅ Configured |
+| **Web/PWA** | Web Push (existing) | 🔄 Coexists, not yet wired |
+| **Electron** | Native (via Capacitor) | ✅ Ready |
+
+**Key Feature**: Both systems coexist using runtime platform detection.
+
+---
+
+## Quick Start Usage
+
+```typescript
+import { NotificationService } from '@/services/notifications';
+
+// Automatically uses native on iOS/Android, web push on web
+const service = NotificationService.getInstance();
+
+// Request permissions
+const granted = await service.requestPermissions();
+
+if (granted) {
+  // Schedule daily notification at 9 AM
+  await service.scheduleDailyNotification({
+    time: '09:00',
+    title: 'Daily Check-In',
+    body: 'Time to check your TimeSafari activity'
+  });
+}
+
+// Check status
+const status = await service.getStatus();
+console.log('Notifications enabled:', status.enabled);
+```
+
+---
+
+## Next Steps
+
+### Immediate (Phase 2)
+1. **Update UI Components**:
+   - Modify `PushNotificationPermission.vue` to use `NotificationService`
+   - Add platform-aware messaging
+   - Test on simulator/emulator
+
+2. **iOS Xcode Setup** (Required):
+   ```bash
+   cd ios
+   open App/App.xcodeproj
+   ```
+   - Enable "Background Modes" capability
+   - Enable "Push Notifications" capability
+   - Run `pod install`
+
+### Short-term (Phase 3)
+3. **Wire Web Push**: Connect `WebPushNotificationService` to existing web push logic
+4. **Test on Devices**: Real iOS and Android devices
+5. **Update Settings**: Ensure notification preferences save correctly
+
+---
+
+## Build & Sync
+
+```bash
+# Sync native projects with web code
+npx cap sync
+
+# Build for Android
+npm run build:android:debug
+
+# Build for iOS (after Xcode setup)
+cd ios && pod install && cd ..
+npm run build:ios:debug
+```
+
+---
+
+## Important Notes
+
+### ⚠️ Critical Requirements
+
+**Android**:
+- `DailyNotificationReceiver` must be in AndroidManifest.xml (✅ done)
+- Runtime permissions needed for Android 13+ (API 33+)
+- Exact alarm permission for Android 12+ (API 31+)
+
+**iOS**:
+- Background Modes capability must be enabled in Xcode (⚠️ manual)
+- BGTaskScheduler identifiers must match Info.plist (✅ done)
+- Test on real device (simulators have limitations)
+
+**Web**:
+- Existing Web Push continues to work unchanged
+- No conflicts - platform detection ensures correct system
+
+---
+
+## Files Created/Modified
+
+### Created (8 files)
+- `src/plugins/DailyNotificationPlugin.ts`
+- `src/services/notifications/NotificationService.ts`
+- `src/services/notifications/NativeNotificationService.ts`
+- `src/services/notifications/WebPushNotificationService.ts`
+- `src/services/notifications/index.ts`
+- `doc/daily-notification-plugin-integration.md`
+- `doc/daily-notification-plugin-integration-summary.md`
+
+### Modified (4 files)
+- `android/app/src/main/AndroidManifest.xml` - Permissions + Receivers
+- `android/app/build.gradle` - Dependencies
+- `android/app/src/main/java/app/timesafari/MainActivity.java` - Plugin registration
+- `ios/App/App/Info.plist` - Background modes + BGTaskScheduler
+
+---
+
+## Testing Checklist
+
+### Before Device Testing
+- [ ] Code compiles without errors
+- [ ] Platform detection logic verified
+- [ ] Service factory creates correct implementation
+
+### Android Device
+- [ ] Request permissions (Android 13+)
+- [ ] Schedule notification
+- [ ] Notification appears at scheduled time
+- [ ] Notification survives app close
+- [ ] Notification survives device reboot
+
+### iOS Device
+- [ ] Xcode capabilities enabled
+- [ ] Request permissions
+- [ ] Schedule notification
+- [ ] Notification appears at scheduled time
+- [ ] Background fetch works
+- [ ] Notification survives app close
+
+### Web/PWA
+- [ ] Existing web push still works
+- [ ] No errors in console
+- [ ] Platform detection selects web implementation
+
+---
+
+## Questions?
+
+See full documentation: `doc/daily-notification-plugin-integration.md`
+
+Plugin README: `node_modules/@timesafari/daily-notification-plugin/README.md`
+
+---
+
+**Status**: Ready for Phase 2 (UI Integration) 🚀

doc/daily-notification-plugin-integration.md

@@ -0,0 +1,237 @@
+# Daily Notification Plugin Integration
+
+**Date**: 2026-01-21  
+**Status**: ✅ Phase 1 Complete - Native Infrastructure  
+**Integration Type**: Native + Web Coexistence
+
+## Overview
+
+The Daily Notification Plugin has been integrated to provide native notification functionality for iOS and Android while maintaining existing Web Push for web/PWA builds. The integration uses platform detection to automatically select the appropriate notification system at runtime.
+
+## What Was Implemented
+
+### 1. **Plugin Registration** ✅
+- **File**: `src/plugins/DailyNotificationPlugin.ts`
+- Registered Capacitor plugin with proper TypeScript types
+- Native-only (no web implementation)
+
+### 2. **Service Abstraction Layer** ✅
+Created unified notification service with platform-specific implementations:
+
+- **`NotificationService.ts`**: Factory that selects implementation based on platform
+- **`NativeNotificationService.ts`**: Wraps DailyNotificationPlugin for iOS/Android
+- **`WebPushNotificationService.ts`**: Stub for future Web Push integration
+
+**Location**: `src/services/notifications/`
+
+**Key Features**:
+- Unified interface (`NotificationServiceInterface`)
+- Automatic platform detection via `Capacitor.isNativePlatform()`
+- Type-safe implementation
+- Singleton pattern for efficiency
+
+### 3. **Android Configuration** ✅
+
+**Modified Files**:
+- `android/app/src/main/AndroidManifest.xml`
+- `android/app/build.gradle`
+- `android/app/src/main/java/app/timesafari/MainActivity.java`
+
+**Changes**:
+- ✅ Added notification permissions (POST_NOTIFICATIONS, SCHEDULE_EXACT_ALARM, etc.)
+- ✅ Registered `DailyNotificationReceiver` (critical for alarm delivery)
+- ✅ Registered `BootReceiver` (restores schedules after device restart)
+- ✅ Added Room, WorkManager, and Coroutines dependencies
+- ✅ Registered plugin in MainActivity
+
+### 4. **iOS Configuration** ✅
+
+**Modified Files**:
+- `ios/App/App/Info.plist`
+
+**Changes**:
+- ✅ Added `UIBackgroundModes` (fetch, processing)
+- ✅ Added `BGTaskSchedulerPermittedIdentifiers` for background tasks
+- ✅ Added `NSUserNotificationAlertStyle` for alert-style notifications
+
+**Still Required** (Manual in Xcode):
+- ⚠️ Enable "Background Modes" capability in Xcode
+  - Background fetch
+  - Background processing
+- ⚠️ Enable "Push Notifications" capability (if using remote notifications)
+
+## Platform Behavior
+
+| Platform | Implementation | Status |
+|----------|---------------|--------|
+| **iOS** | DailyNotificationPlugin (native) | ✅ Configured |
+| **Android** | DailyNotificationPlugin (native) | ✅ Configured |
+| **Web/PWA** | Web Push (existing) | 🔄 Not yet wired up |
+| **Electron** | Would use native | ✅ Ready |
+
+## Usage Example
+
+```typescript
+import { NotificationService } from '@/services/notifications/NotificationService';
+
+// Get the appropriate service for current platform
+const notificationService = NotificationService.getInstance();
+
+// Check platform
+console.log('Platform:', NotificationService.getPlatform());
+console.log('Is native:', NotificationService.isNative());
+
+// Request permissions
+const granted = await notificationService.requestPermissions();
+
+if (granted) {
+  // Schedule daily notification
+  await notificationService.scheduleDailyNotification({
+    time: '09:00',
+    title: 'Daily Check-In',
+    body: 'Time to check your TimeSafari activity',
+    priority: 'normal'
+  });
+}
+
+// Check status
+const status = await notificationService.getStatus();
+console.log('Enabled:', status.enabled);
+console.log('Time:', status.scheduledTime);
+```
+
+## Next Steps
+
+### Phase 2: UI Integration
+- [ ] Update `PushNotificationPermission.vue` to use `NotificationService`
+- [ ] Add platform-aware UI messaging
+- [ ] Update settings storage to work with both systems
+- [ ] Test notification scheduling UI
+
+### Phase 3: Web Push Integration
+- [ ] Wire `WebPushNotificationService` to existing PushNotificationPermission logic
+- [ ] Extract web push subscription code into service methods
+- [ ] Test web platform notification flow
+
+### Phase 4: Testing & Polish
+- [ ] Test on real iOS device
+- [ ] Test on real Android device (API 23+, API 33+)
+- [ ] Test permission flows
+- [ ] Test notification delivery
+- [ ] Test app restart/reboot scenarios
+- [ ] Verify background notification delivery
+
+### Phase 5: Xcode Configuration (iOS Only)
+- [ ] Open `ios/App/App.xcodeproj` in Xcode
+- [ ] Select App target → Signing & Capabilities
+- [ ] Click "+ Capability" → Add "Background Modes"
+  - Enable "Background fetch"
+  - Enable "Background processing"
+- [ ] Click "+ Capability" → Add "Push Notifications" (if using remote)
+- [ ] Run `pod install` in `ios/` directory
+- [ ] Build and test on device
+
+## Build Commands
+
+### Sync Capacitor
+```bash
+npx cap sync
+# or
+npx cap sync android
+npx cap sync ios
+```
+
+### Build Android
+```bash
+npm run build:android
+# or
+npm run build:android:debug
+```
+
+### Build iOS
+```bash
+npm run build:ios
+# or after Xcode setup:
+cd ios && pod install && cd ..
+npm run build:ios:debug
+```
+
+## Important Notes
+
+### Android
+- **Critical**: `DailyNotificationReceiver` must be in AndroidManifest.xml
+- Android 12+ (API 31+) requires `SCHEDULE_EXACT_ALARM` permission
+- Android 13+ (API 33+) requires runtime `POST_NOTIFICATIONS` permission
+- BootReceiver restores schedules after device restart
+
+### iOS
+- **Critical**: Background modes must be enabled in Xcode capabilities
+- iOS 13.0+ supported (already compatible with your deployment target)
+- Background tasks use `BGTaskScheduler`
+- User must grant notification permissions in Settings
+
+### Web
+- Existing Web Push continues to work
+- No conflicts with native implementation
+- Platform detection ensures correct system is used
+
+## Files Modified
+
+### Created
+- `src/plugins/DailyNotificationPlugin.ts`
+- `src/services/notifications/NotificationService.ts`
+- `src/services/notifications/NativeNotificationService.ts`
+- `src/services/notifications/WebPushNotificationService.ts`
+
+### Modified
+- `android/app/src/main/AndroidManifest.xml`
+- `android/app/build.gradle`
+- `android/app/src/main/java/app/timesafari/MainActivity.java`
+- `ios/App/App/Info.plist`
+
+## Troubleshooting
+
+### Android: Notifications Not Appearing
+1. Check that `DailyNotificationReceiver` is registered in AndroidManifest.xml
+2. Verify permissions are requested at runtime (Android 13+)
+3. Check that notification channel is created
+4. Enable "Exact alarms" in app settings (Android 12+)
+
+### iOS: Background Tasks Not Running
+1. Ensure Background Modes capability is enabled in Xcode
+2. Check that BGTaskScheduler identifiers match Info.plist
+3. Test on real device (simulator has limitations)
+4. Check iOS Settings → Notifications → TimeSafari
+
+### Permission Issues
+1. Request permissions before scheduling: `requestPermissions()`
+2. Check permission status: `checkPermissions()`
+3. Guide users to system settings if denied
+
+## Plugin Documentation
+
+For complete plugin documentation, see:
+- Plugin README: `node_modules/@timesafari/daily-notification-plugin/README.md`
+- Plugin version: 1.0.11
+- Repository: https://gitea.anomalistdesign.com/trent_larson/daily-notification-plugin
+
+## Testing Checklist
+
+- [ ] Android: Notification appears at scheduled time
+- [ ] Android: Notification survives app close
+- [ ] Android: Notification survives device reboot
+- [ ] iOS: Notification appears at scheduled time
+- [ ] iOS: Background fetch works
+- [ ] iOS: Notification survives app close
+- [ ] Web: Existing web push still works
+- [ ] Platform detection works correctly
+- [ ] Permission requests work on all platforms
+- [ ] Status retrieval works correctly
+
+## Current Status
+
+✅ **Phase 1 Complete**: Native infrastructure configured  
+🔄 **Phase 2 In Progress**: Ready for UI integration  
+⏳ **Phase 3 Pending**: Web Push service integration  
+⏳ **Phase 4 Pending**: Testing and validation  
+⏳ **Phase 5 Pending**: Xcode capabilities setup

doc/debug-hook-guide.md

@@ -80,7 +80,7 @@ installed by each developer. They are not automatically active.
 - Test files: `*.test.js`, `*.spec.ts`, `*.test.vue`
 - Scripts: `scripts/` directory
 - Test directories: `test-*` directories
-- Documentation: `docs/`, `*.md`, `*.txt`
+- Documentation: `doc/`, `*.md`, `*.txt`
 - Config files: `*.json`, `*.yml`, `*.yaml`
 - IDE files: `.cursor/` directory
 

doc/endorser-jwt-background-prefetch-options.md

@@ -0,0 +1,152 @@
+# Options: expired JWT during background “New Activity” prefetch (mobile)
+
+**Date:** 2026-03-26 17:29 PST  
+**Audience:** TimeSafari / crowd-funder team; **Endorser server** maintainers (auth + API policy)  
+**Context:** Android Capacitor app, `POST /api/v2/report/plansLastUpdatedBetween`, native `TimeSafariNativeFetcher` invoked from WorkManager at **T−5 minutes** before the daily notification.
+
+---
+
+## Problem (short)
+
+New Activity notifications prefetch Endorser data in **background** (no JavaScript, no WebView). The HTTP client uses a **Bearer JWT** supplied earlier via `configureNativeFetcher` / `getHeaders(activeDid)`.
+
+If the **access token’s `exp`** is **before** prefetch time, the API returns **400** with a body like:
+
+```json
+{
+  "error": {
+    "message": "JWT failed verification: ... JWT has expired: exp: … < now: …",
+    "code": "JWT_VERIFY_FAILED"
+  }
+}
+```
+
+We **cannot** rely on the user opening the app immediately before prefetch (T−5), so **client-only** mitigations (e.g. refresh JWT on app resume) **reduce** failures but **do not guarantee** a valid token for headless background work.
+
+---
+
+## Why this is different from normal in-app API calls
+
+| In-app | Background prefetch |
+|--------|----------------------|
+| `getHeaders()` runs in JS when needed; user often recently active | WorkManager runs **without** Capacitor / passkey / session refresh |
+| Short TTL tokens are refreshed as the user uses the app | Same token may sit in native memory until **T−5** (or longer) |
+
+So **server-side** and **architecture** choices matter for this feature.
+
+---
+
+## Options (for decision)
+
+### 1. Increase access token TTL (Endorser / IdP)
+
+**Idea:** Issue access JWTs with a longer `exp` so that **configure time → prefetch time** (often **5+ minutes**, sometimes **24h+** if the user rarely opens the app) usually still falls inside validity.
+
+| Pros | Cons |
+|------|------|
+| Simple to explain; one policy change | Longer-lived bearer tokens increase risk if exfiltrated; mitigate with scope, rotation, monitoring |
+| No client protocol change | May not fit strict security posture without a dedicated scope |
+
+**Endorser owner:** token lifetime, scopes, and whether a **dedicated** lifetime or scope for “mobile background read” is acceptable.
+
+---
+
+### 2. Scoped long-lived token for report reads only (Endorser)
+
+**Idea:** Mint a **separate** access token (or sub-scope) valid only for **read-only report** endpoints (`plansLastUpdatedBetween`, etc.), with a **longer TTL** than the interactive session token.
+
+| Pros | Cons |
+|------|------|
+| Limits blast radius vs “longer JWT for everything” | Requires auth model + issuance path; client must store/use this token only for prefetch |
+
+**Endorser owner:** feasibility of **narrow scope** + **longer TTL** for this use case.
+
+---
+
+### 3. Refresh token or device grant (Endorser + mobile native)
+
+**Idea:** Client stores a **refresh token** (or OAuth **device** grant) in **Android Keystore / iOS Keychain**. Before `plansLastUpdatedBetween`, **native** code (no JS) exchanges it for a **new access token**.
+
+| Pros | Cons |
+|------|------|
+| Standard pattern; short TTL for access tokens remains | Endorser must support refresh (or equivalent); secure storage + rotation; **both** client and server work |
+| Works when app is backgrounded for days | Implementation cost on mobile |
+
+**Endorser owner:** refresh endpoint, token rotation, revocation.  
+**Mobile owner:** native fetch path, secure storage, failure handling.
+
+---
+
+### 4. Backend proxy / BFF (TimeSafari backend + Endorser)
+
+**Idea:** Phone calls **your** backend with a **device session** (or FCM registration id); **server** uses **server-to-server** credentials or a **service account** to call Endorser. The device **never** sends an Endorser JWT for this path.
+
+| Pros | Cons |
+|------|------|
+| No Endorser JWT lifetime problem on device | New service, auth, rate limits, privacy review |
+| Central place for logging, abuse control | Operational cost |
+
+**Endorser owner:** partner / S2S auth model for the BFF.  
+**Product team:** hosting and trust boundaries.
+
+---
+
+### 5. “Cron” or periodic jobs on the device to refresh JWT (JS)
+
+**Idea:** Use something like a **cron** schedule to refresh tokens.
+
+**Reality:** Scheduled **native** jobs can run, but **Capacitor / `getHeaders()` / passkey** do **not** run reliably in that context without waking the **WebView**. So **“cron”** only helps if refresh is **fully native** (see option 3) or you accept **unreliable** wake + JS.
+
+**Not recommended** as the primary fix unless paired with **native refresh** or **server** changes.
+
+---
+
+### 6. Product / UX constraints (no server change)
+
+**Idea:** Accept that **headless** API calls may fail if the session is stale; show **fallback** copy; or require “open app once per day” for best results.
+
+| Pros | Cons |
+|------|------|
+| No Endorser change | Does not meet “API-driven notification” expectation for inactive users |
+
+---
+
+## Client-side mitigations already in play (not sufficient alone)
+
+- **`configureNativeFetcherIfReady()`** after startup and when **Account** / identity is ready.
+- **`appStateChange` → `isActive`:** refresh native fetcher when the app returns to foreground (reduces staleness when the user **does** open the app).
+- **Error logging** of 400 bodies for diagnosis.
+
+These **do not** guarantee a fresh JWT at **T−5** if the user never opens the app before prefetch.
+
+---
+
+## Suggested decision order
+
+1. **Align on security posture:** Is a **longer TTL** or **scoped long-lived read token** acceptable for Endorser?
+2. If not, is **refresh token in native** (option 3) or **BFF** (option 4) on the roadmap?
+3. **Parallel:** UX fallback when API is unavailable (option 6) so the app never silently looks “broken.”
+
+---
+
+## References (this repo)
+
+| Topic | Location |
+|--------|----------|
+| Native fetcher + JWT from `getHeaders` | `src/services/notifications/nativeFetcherConfig.ts` |
+| Android POST + errors | `android/app/src/main/java/app/timesafari/TimeSafariNativeFetcher.java` |
+| Web `plansLastUpdatedBetween` + `afterId` | `src/libs/endorserServer.ts` (`getStarredProjectsWithChanges`) |
+| New Activity / dual schedule | `doc/notification-from-api-call.md`, `doc/plugin-feedback-android-dual-schedule-native-fetch-and-timing.md` |
+
+---
+
+## Open questions for Endorser (server developer)
+
+1. What is the **current access token TTL** and can it be **increased** for mobile clients, or **per-scope**?
+2. Is **refresh token** (or similar) available for **non-interactive** renewal?
+3. Would a **read-only** scope for `plansLastUpdatedBetween` with a **longer** lifetime be acceptable?
+4. Is there an existing **server-to-server** or **partner** path that a **BFF** could use instead of user JWT on device?
+
+---
+
+*This document is for internal planning and decision; update it when the team chooses an approach.*

doc/new-activity-notifications-ios-android-parity.md

@@ -0,0 +1,158 @@
+# New Activity Notifications: iOS Parity with Android
+
+**Purpose:** Describe what is required for **iOS** to match **Android** for the daily-notification-plugin **API-driven “New Activity”** flow (`scheduleDualNotification` / `cancelDualSchedule`, with prefetch and Endorser-backed content). The canonical product behavior is documented in `doc/notification-from-api-call.md` and `doc/notification-new-activity-lay-of-the-land.md`.
+
+**Plugin source of truth:** The Capacitor package is `@timesafari/daily-notification-plugin`, pulled from the official remote in `package.json` (`git+https://gitea.anomalistdesign.com/trent_larson/daily-notification-plugin.git`). Plugin development happens in that repository; this app bumps the dependency and runs `npm install` / `npx cap sync` after releases.
+
+---
+
+## 1. What “parity” means here
+
+| Concern | Intended behavior |
+|--------|---------------------|
+| **Scheduling** | Dual schedule: prefetch job **before** notify time (app uses cron T−5 minutes), then user-visible notification at the chosen time. |
+| **API content** | Prefetch calls the **same Endorser semantics** as the Android host: **`plansLastUpdatedBetween`** (POST) with **starred plan IDs**, JWT auth, aggregated titles/bodies consistent with `TimeSafariNativeFetcher`. |
+| **Starred plans** | `updateStarredPlans({ planIds })` from the app must affect what the native prefetch queries. |
+| **Configure** | `configureNativeFetcher({ apiBaseUrl, activeDid, jwtToken, … })` supplies credentials the native layer uses for prefetch. |
+| **Lifecycle** | `cancelDualSchedule()` removes the dual prefetch + notify schedule without breaking the separate Daily Reminder. |
+
+Platform differences (iOS **BGTaskScheduler** is opportunistic; Android **alarms/WorkManager** can be more exact) mean **timing** may never be identical, but **API behavior and user-visible copy** should align.
+
+---
+
+## 2. Current state: Android (this app)
+
+- **Host native fetcher:** `android/.../TimeSafariNativeFetcher.java` implements the plugin’s `NativeNotificationContentFetcher` and calls **`POST …/api/v2/report/plansLastUpdatedBetween`** using starred plan IDs (via plugin storage from `updateStarredPlans`).
+- **Registration:** `MainActivity` calls `DailyNotificationPlugin.setNativeFetcher(new TimeSafariNativeFetcher(this))`.
+- **Plugin (Android) — older notes:** Prior dual-schedule issues (native fetcher / fetch cron) are addressed in **plugin ≥ 3.0.0** (chained dual: notify after prefetch). Historical analysis: `doc/plugin-feedback-android-dual-schedule-native-fetch-and-timing.md`.
+
+---
+
+## 3. Current state: iOS (this app + bundled plugin)
+
+### 3.1 This repository
+
+- **iOS native fetcher:** `ios/App/App/TimeSafariNativeFetcher.swift` implements `NativeNotificationContentFetcher` (Endorser `plansLastUpdatedBetween`, same prefs keys as Java). **`AppDelegate`** calls `DailyNotificationPlugin.registerNativeFetcher(TimeSafariNativeFetcher.shared)` at launch **before** any `configureNativeFetcher` from JS (see plugin `doc/CONSUMING_APP_HANDOFF_IOS_NATIVE_FETCHER_AND_CHAINED_DUAL.md` and **`doc/consuming-app-handoff-ios-native-fetcher-chained-dual.md`**).
+- **JS/TS is already shared:** `nativeFetcherConfig.ts`, `dualScheduleConfig.ts`, `syncStarredPlansToNativePlugin.ts`, and `AccountViewView.vue` call the same APIs on both platforms.
+- **Info.plist** already lists `UIBackgroundModes` (fetch, processing) and `BGTaskSchedulerPermittedIdentifiers` for the plugin’s task IDs. Xcode **Signing & Capabilities** should still enable **Background fetch** and **Background processing** (see `doc/daily-notification-plugin-integration.md`).
+- **AppDelegate** posts `DailyNotificationDelivered` for foreground presentation—aligned with plugin rollover behavior.
+
+### 3.2 Bundled plugin (`node_modules/@timesafari/daily-notification-plugin`, iOS)
+
+Requires **plugin ≥ 3.0.0** (register native fetcher, chained dual, iOS `updateStarredPlans`). Version pinned in `ios/App/Podfile.lock` after `pod install`.
+
+- **`scheduleDualNotification` / `cancelDualSchedule`** — see plugin release notes; clean sync + `pod install` if you see `UNIMPLEMENTED` (`doc/plugin-feedback-ios-scheduleDualNotification.md`).
+- **`configureNativeFetcher`** — **requires** `DailyNotificationPlugin.registerNativeFetcher` first; the host Swift fetcher performs **`plansLastUpdatedBetween`** (plugin does not use in-plugin `offers` GET when a fetcher is registered—mirrors Android).
+- **`updateStarredPlans`** — implemented on iOS in current plugin; persists **`daily_notification_timesafari.starredPlanIds`** for the host fetcher.
+- **Chained dual** — user notification is armed **after** prefetch for that cycle (plugin); iOS remains subject to BG scheduling limits; see **§3.3**.
+
+### 3.3 Prefetch before notify (ordering, not cron)
+
+iOS has no system cron; the app/plugin may still **parse** cron to compute “next run” times. The hard part is **ordering**: if **prefetch** is driven by **`BGTaskScheduler`** (opportunistic) and **notify** by **`UNUserNotificationCenter`** at a fixed time **T**, those are **independent**. The OS can deliver the local notification at **T** while prefetch runs **after** **T** or not at all—so the awkward case (notify first, prefetch later, stale or fallback content) **can** happen. Two peer timers do **not** imply “fetch always completes before **T**.”
+
+To **enforce** prefetch-before-notify as a rule, use **chaining**, not two unrelated schedules:
+
+- After prefetch for that cycle **finishes** (success or explicit timeout policy), **then** schedule or **replace** the pending `UNNotificationRequest` for time **T** with the resolved title/body (or fallback). Until then, do not arm a user-visible notification that claims fresh API content.
+- **Tradeoffs:** If prefetch is late, the notification may be **late**; if prefetch never runs before a deadline, use **fallback** copy at **T** or skip—product choice.
+- **Parsing cron** remains useful to compute **T** and to decide when to **submit** BG work; **ordering** is a **pipeline** decision (fetch → cache → arm notify), not “BG at T−5 and UN at **T** both scheduled up front.”
+
+Plugin work item **§4A.3** should reflect this: document the chosen strategy (chained arm vs best-effort dual timer) and how it interacts with `relationship.contentTimeout` / fallback.
+
+---
+
+## 4. Work breakdown
+
+### 4A. Plugin (`daily-notification-plugin`) — status (v3.x)
+
+Items below were the original gap list; **plugin ≥ 3.0.0** ships **iOS** `updateStarredPlans`, **`registerNativeFetcher`**, **chained dual** on iOS and Android, and Android dual-path fixes. Remaining work is **release coordination** (bump, sync, QA), not greenfield plugin implementation.
+
+1. **`updateStarredPlans` on iOS** — shipped in current plugin.
+
+2. **iOS `plansLastUpdatedBetween` / host fetcher** — shipped: host registers **`TimeSafariNativeFetcher`** (Swift); plugin does not duplicate Endorser logic when a fetcher is registered.
+
+3. **Dual schedule / chaining** — shipped (notify after prefetch; see plugin release notes and **§3.3**).
+
+4. **Android dual path** — chained dual + native fetcher alignment in current plugin (see `doc/plugin-feedback-android-dual-schedule-native-fetch-and-timing.md` for historical context).
+
+5. **JWT pool / expiry (Phase B)**  
+   - **App:** Phase B is already implemented: `configureNativeFetcherIfReady()` passes `jwtTokens` from `mintBackgroundJwtTokenPool` on **both** iOS and Android (`src/services/notifications/nativeFetcherConfig.ts`).  
+   - **Android:** `TimeSafariNativeFetcher` selects a bearer from the pool for background requests (`doc/plugin-feedback-daily-notification-configureNativeFetcher-jwt-pool.md`).  
+   - **iOS:** The bundled plugin’s `configureNativeFetcher` **already accepts and persists** `jwtTokens` / `jwtTokenPoolJson`, and the in-plugin fetch path uses a bearer from the primary token or pool. What is **not** yet at parity with Android is **which API** that token is used for (`offers` GET vs `plansLastUpdatedBetween` + starred plans)—that falls under **§4A.2**, not “waiting for Phase B on iOS.”  
+   - **Expiry:** Re-calling `configureNativeFetcherIfReady` on foreground / Account (see `notification-from-api-call.md`) remains relevant on both platforms.
+
+### 4B. This app (crowd-funder-for-time-pwa) — after or alongside plugin changes
+
+1. **Bump `@timesafari/daily-notification-plugin`** to **≥ 3.0.0** via the git dependency in `package.json`, run `npm install`, `npx cap sync ios`, `cd ios/App && pod install`, clean build (`doc/plugin-feedback-ios-scheduleDualNotification.md`, **`doc/consuming-app-handoff-ios-native-fetcher-chained-dual.md`**).
+2. **iOS native fetcher** — **Done:** `TimeSafariNativeFetcher.swift` + `registerNativeFetcher` in `AppDelegate` (see handoff doc).
+3. **Re-test** `syncStarredPlansToNativePlugin` on iOS; the helper may still catch `UNIMPLEMENTED` for older plugin binaries.
+4. **Xcode:** Confirm Background Modes capabilities match `Info.plist`.
+5. **QA:** Full matrix in `doc/notification-from-api-call.md` (enable/disable, empty starred list, JWT expiry, foreground/background); chained dual timing (notify after prefetch).
+
+### 4C. Related product bug (both platforms)
+
+- **`PushNotificationPermission.vue` vs New Activity:** Enabling New Activity can still schedule the **single** daily reminder by mistake; turning New Activity off may not cancel that reminder. See `doc/notification-new-activity-lay-of-the-land.md`. Fixing this is orthogonal to iOS/Android API parity but affects perceived “notifications behavior.”
+
+---
+
+## 5. Reference map (this repo)
+
+| Topic | Document |
+|-------|-----------|
+| Plugin post-bump handoff (iOS fetcher + chained dual) | `doc/consuming-app-handoff-ios-native-fetcher-chained-dual.md` |
+| Feature plan & file list | `doc/notification-from-api-call.md` |
+| Dual vs Daily Reminder confusion | `doc/notification-new-activity-lay-of-the-land.md` |
+| iOS `UNIMPLEMENTED` / PluginHeaders | `doc/plugin-feedback-ios-scheduleDualNotification.md` |
+| Android dual schedule + native fetcher | `doc/plugin-feedback-android-dual-schedule-native-fetch-and-timing.md` |
+| Integration & Xcode | `doc/daily-notification-plugin-integration.md` |
+| Android host fetcher | `android/.../TimeSafariNativeFetcher.java`, `MainActivity.java` |
+
+---
+
+## 6. Handoff to plugin repo (Cursor / isolated workspace)
+
+Use this section when **daily-notification-plugin** is open **without** the TimeSafari app tree, so implementers do not depend on paths that only exist in crowd-funder-for-time-pwa.
+
+### 6.1 Bring reference material into scope
+
+| Source (this app repo) | Why |
+|------------------------|-----|
+| `android/app/src/main/java/app/timesafari/TimeSafariNativeFetcher.java` | **Canonical Endorser behavior** for New Activity: POST body, pagination, aggregation copy, prefs keys for starred IDs and `last_acked_jwt_id`. Copy or open alongside the plugin when implementing iOS fetch or `setNativeFetcher`. |
+| `src/services/notifications/dualScheduleConfig.ts` | Shape the app sends to `scheduleDualNotification` (`buildDualScheduleConfig`). |
+| `doc/plugin-feedback-android-dual-schedule-native-fetch-and-timing.md` | Android plugin: dual path must call native fetcher at fetch cron. |
+| `doc/plugin-feedback-ios-scheduleDualNotification.md` | iOS `UNIMPLEMENTED` / PluginHeaders troubleshooting. |
+
+In the plugin repo itself, align with **`src/definitions.ts`** (`DualScheduleConfiguration`, `configureNativeFetcher`, `updateStarredPlans`) and **INTEGRATION_GUIDE** if present.
+
+### 6.2 HTTP / storage contract (match `TimeSafariNativeFetcher`)
+
+Implementations on **iOS** (in-plugin Swift or host `NativeNotificationContentFetcher`) should match this **unless** product explicitly changes:
+
+- **Method & path:** `POST` `{apiBaseUrl}/api/v2/report/plansLastUpdatedBetween` (no trailing slash mismatch on `apiBaseUrl`).
+- **Headers:** `Content-Type: application/json`, `Authorization: Bearer {token}` (token from `jwtToken` or **JWT pool** selection—see Java `selectBearerTokenForRequest`: UTC day mod pool size).
+- **JSON body:** `planIds` (array of strings, possibly empty), `afterId` (string; use `"0"` if none stored).
+- **Starred plans:** Android: SharedPreferences **`daily_notification_timesafari`** + key **`starredPlanIds`**. iOS (plugin + host): `UserDefaults.standard` key **`daily_notification_timesafari.starredPlanIds`** (JSON array string).
+- **Pagination:** After a successful response with non-empty `data`, update **`last_acked_jwt_id`** from the last row’s `jwtId` (item or nested `plan.jwtId`)—see Java `updateLastAckedJwtIdFromResponse`. iOS host (`TimeSafariNativeFetcher.swift`) persists **`daily_notification_timesafari.last_acked_jwt_id`** in `UserDefaults.standard`.
+- **Empty `data`:** Return **no** notification items (empty list); do not synthesize a “no updates” push from an empty result—Java returns empty `contents` when `data` is absent or empty.
+- **Non-empty `data`:** One aggregated `NotificationContent`: titles **Starred Project Update** / **Starred Project Updates**, bodies use typographic quotes around first project name and **has been updated.** / **+ N more have been updated.** (see Java `parseApiResponse`).
+
+### 6.3 Likely plugin touchpoints (maintenance / debugging)
+
+- **iOS:** `ios/Plugin/DailyNotificationPlugin.swift`, `DailyNotificationScheduleHelper.swift`, native fetcher registry, BG / UN paths.
+- **Android:** `DailyNotificationPlugin.kt`, fetch workers / `ScheduleHelper`—see dual-schedule feedback doc for history.
+
+### 6.4 Suggested order (plugin shipped ≥ 3.0.0)
+
+1. Tag / publish **`@timesafari/daily-notification-plugin`**.  
+2. **Consuming app:** bump, `npm install`, `npx cap sync`, `pod install`, QA (`doc/consuming-app-handoff-ios-native-fetcher-chained-dual.md`).
+
+---
+
+## 7. Acceptance checklist (iOS vs Android product intent)
+
+- [ ] Prefetch uses **plansLastUpdatedBetween** (or host fetcher with identical behavior), not only `offers` GET.
+- [ ] **Starred plan IDs** from settings change what is queried (`updateStarredPlans` works on iOS).
+- [ ] Notification title/body match the **same rules** as Android for “starred project updates” (including empty updates).
+- [ ] `configureNativeFetcher` + JWT refresh story documented; re-config on foreground if needed (`notification-from-api-call.md`).
+- [ ] `cancelDualSchedule` clears dual prefetch/notify without leaving orphan schedules.
+- [ ] Understand and document **iOS timing** limitations vs Android for support/Help copy.
+- [ ] **Prefetch vs notify ordering** on iOS: chosen strategy (chained arm vs independent BG + UN) documented; avoids claiming fresh API content when prefetch has not run yet (**§3.3**).

doc/notification-from-api-call.md

@@ -0,0 +1,108 @@
+# New Activity Notification (API-Driven Daily Message)
+
+**Purpose:** Integrate the daily-notification-plugin’s second feature—the **daily, API-driven message**—into the crowd-funder (TimeSafari) app. The first feature (daily static reminder) is already integrated; this document covers the plan, completed work, and remaining tasks for the API-driven flow.
+
+**References:**
+
+- Plugin: `daily-notification-plugin` (INTEGRATION_GUIDE.md, definitions.ts)
+- Alignment outline: `doc/daily-notification-alignment-outline.md`
+- Help copy: `HelpNotificationTypesView.vue` (“New Activity Notifications”)
+
+---
+
+## Plan Summary
+
+The API-driven flow:
+
+1. **Prefetch** – Shortly before the user’s chosen time, the plugin runs a background job that calls the Endorser.ch API (e.g. `plansLastUpdatedBetween`, and optionally offers endpoints) using credentials supplied by the app.
+2. **Cache** – Fetched content is stored in the plugin’s cache.
+3. **Notify** – At the chosen time, the user sees a notification whose title/body come from that content (or a fallback).
+
+The app must:
+
+- **Configure the native fetcher** with `apiBaseUrl`, `activeDid`, and a JWT so the plugin’s background workers can call the API.
+- **Implement the native fetcher** (or register an implementation) so the plugin can perform the actual HTTP requests and parse responses into notification content.
+- **Sync starred plan IDs** to the plugin via `updateStarredPlans` so the fetcher knows which plans to query.
+- **Expose UI** to enable/disable the “New Activity” notification and choose a time, and call `scheduleDualNotification` / `cancelDualSchedule` accordingly.
+
+---
+
+## Tasks Finished
+
+- **Configure native fetcher on startup and identity**
+  - Added `configureNativeFetcherIfReady()` in `src/services/notifications/nativeFetcherConfig.ts` (reads `activeDid` and `apiServer` from DB, gets JWT via `getHeaders(did)`, calls `DailyNotification.configureNativeFetcher()`).
+  - Called from `main.capacitor.ts` after the 2s delay (with deep link registration).
+  - Called from `AccountViewView.initializeState()` when on native and `activeDid` is set; when New Activity is enabled, also calls `updateStarredPlans(settings.starredPlanHandleIds)`.
+- **Implement real API calls in Android native fetcher**
+  - `android/app/src/main/java/app/timesafari/TimeSafariNativeFetcher.java` implements `NativeNotificationContentFetcher`: POST to `/api/v2/report/plansLastUpdatedBetween` with `planIds` (from SharedPreferences `daily_notification_timesafari` / `starredPlanIds`) and `afterId`; when `data` is non-empty, builds **one** aggregated `NotificationContent` (title **Starred Project Update** or **Starred Project Updates**, body from `plan.name` with typographic quotes, then `has been updated.` or `+ N more have been updated.`); when `data` is empty, returns an empty list (no “no updates” notification); updates `last_acked_jwt_id` for pagination when content is returned.
+  - Registered in `MainActivity.onCreate()` via `DailyNotificationPlugin.setNativeFetcher(new TimeSafariNativeFetcher(this))`.
+- **Sync starred plan IDs**
+  - Shared helper `syncStarredPlansToNativePlugin(planIds)` in `src/services/notifications/syncStarredPlansToNativePlugin.ts` (exported from `src/services/notifications/index.ts`) calls `DailyNotification.updateStarredPlans` on native only; ignores `UNIMPLEMENTED`.
+  - When user enables New Activity, `scheduleNewActivityDualNotification()` uses the helper with `settings.starredPlanHandleIds ?? []`.
+  - When Account view loads and New Activity is on, `initializeState()` uses the helper with the same list.
+  - When the user stars or unstars on a project (`ProjectViewView.toggleStar`), after a successful settings save, the helper runs if `notifyingNewActivityTime` is set so prefetch sees the current list without reopening Account.
+- **Dual schedule config and scheduling**
+  - Added `src/services/notifications/dualScheduleConfig.ts`: `timeToCron()`, `timeToCronFiveMinutesBefore()`, `buildDualScheduleConfig({ notifyTime, title?, body? })` (contentFetch 5 min before, userNotification at chosen time).
+  - When user enables New Activity and picks a time, app calls `DailyNotification.scheduleDualNotification({ config })` with this config.
+  - When user disables New Activity, app calls `DailyNotification.cancelDualSchedule()`.
+- **UI for New Activity notification**
+  - Unhid the “New Activity Notification” block in `AccountViewView.vue` (toggle + accessibility).
+  - Enable flow: time dialog → save settings → on native, `scheduleNewActivityDualNotification(timeText)` (configure fetcher, updateStarredPlans, scheduleDualNotification).
+  - Disable flow: on native, `cancelDualSchedule()` then save and clear settings.
+  - Added `starredPlanHandleIds` to `AccountSettings` in `interfaces/accountView.ts`.
+- **Exports**
+  - `src/services/notifications/index.ts` exports `configureNativeFetcherIfReady`, `syncStarredPlansToNativePlugin`, `buildDualScheduleConfig`, `timeToCron`, `timeToCronFiveMinutesBefore`, and `DualScheduleConfigInput`.
+
+---
+
+## Checklist of Remaining Tasks
+
+### iOS
+
+**Parity outline (API, starred plans, plugin vs app work):** See **`doc/new-activity-notifications-ios-android-parity.md`**.
+
+- **Confirm iOS native fetcher / dual schedule**  
+Plugin exposes `configureNativeFetcher` on iOS. Confirm whether the plugin expects an iOS-specific native fetcher registration (similar to Android’s `setNativeFetcher`) and, if so, register a TimeSafari fetcher implementation for iOS so API-driven notifications work on iPhone.
+- **Verify dual schedule on iOS**  
+Test `scheduleDualNotification` and `cancelDualSchedule` on iOS; ensure content fetch and user notification fire at the expected times and that foreground/background behavior matches expectations.
+
+### Testing and hardening
+
+- **Test full flow on Android**  
+Enable New Activity, set time, wait for prefetch and notification (or use a short rollover for testing). Confirm notification shows with API-derived or fallback content.
+- **Test full flow on iOS**  
+Same as Android: enable, set time, verify prefetch and notification delivery and content.
+- **Test with no starred plans**  
+Enable New Activity with empty `starredPlanHandleIds`; confirm no crash; the native fetcher returns no Endorser-derived items when there is nothing to query or no new rows (see `TimeSafariNativeFetcher`).
+- **Test JWT expiry**  
+Ensure behavior when the token passed to `configureNativeFetcher` has expired (e.g. app in background for a long time); document or implement refresh (e.g. re-call `configureNativeFetcherIfReady` on foreground or when opening Account).
+
+### Optional enhancements
+
+- **Offers endpoints**  
+Extend `TimeSafariNativeFetcher` (and any iOS fetcher) to call offers endpoints (e.g. `offers`, `offersToPlansOwnedByMe`) and merge with project-update content for richer notifications.
+- **Documentation**  
+Add a short “New Activity notifications” section to BUILDING.md or a user-facing help page describing how the feature works and how to troubleshoot (e.g. no notification, wrong content, JWT/API errors).
+
+---
+
+## File Reference
+
+
+| Area                   | Files                                                                   |
+| ---------------------- | ----------------------------------------------------------------------- |
+| Fetcher config         | `src/services/notifications/nativeFetcherConfig.ts`                     |
+| Starred list → plugin  | `src/services/notifications/syncStarredPlansToNativePlugin.ts`          |
+| Dual schedule config   | `src/services/notifications/dualScheduleConfig.ts`                      |
+| Notification exports   | `src/services/notifications/index.ts`                                   |
+| Startup                | `src/main.capacitor.ts`                                                 |
+| Account UI and flow    | `src/views/AccountViewView.vue`                                         |
+| Project star / unstar  | `src/views/ProjectViewView.vue` (`toggleStar`)                          |
+| Settings type          | `src/interfaces/accountView.ts`                                         |
+| Android native fetcher | `android/app/src/main/java/app/timesafari/TimeSafariNativeFetcher.java` |
+| Android registration   | `android/app/src/main/java/app/timesafari/MainActivity.java`            |
+| iOS native fetcher     | `ios/App/App/TimeSafariNativeFetcher.swift`                              |
+| iOS registration       | `ios/App/App/AppDelegate.swift` (`DailyNotificationPlugin.registerNativeFetcher`) |
+| Plugin 3.x handoff     | `doc/consuming-app-handoff-ios-native-fetcher-chained-dual.md`           |
+
+

doc/notification-integration-changes-outline.md

@@ -0,0 +1,412 @@
+# Notification Integration Changes - Implementation Outline
+
+**Date**: 2026-01-23  
+**Purpose**: Detailed outline of changes needed to integrate DailyNotificationPlugin with UI
+
+---
+
+## Overview
+
+This document outlines all changes required to integrate the DailyNotificationPlugin with the existing notification UI, making it work seamlessly on both native (iOS/Android) and web platforms.
+
+**Estimated Complexity**: Medium  
+**Estimated Files Changed**: 3-4 files  
+**Breaking Changes**: None (backward compatible)
+
+---
+
+## Change Summary
+
+| File | Changes | Complexity | Risk |
+|------|---------|------------|------|
+| `PushNotificationPermission.vue` | Add platform detection, native flow | Medium | Low |
+| `AccountViewView.vue` | Platform detection in toggles, hide push server on native | Low | Low |
+| `WebPushNotificationService.ts` | Complete stub implementation (optional) | Medium | Low |
+
+---
+
+## Detailed Changes
+
+### 1. PushNotificationPermission.vue
+
+**File**: `src/components/PushNotificationPermission.vue`  
+**Current Lines**: ~656 lines  
+**Estimated New Lines**: +50-80 lines  
+**Complexity**: Medium
+
+#### Changes Required
+
+**A. Add Imports** (Top of script section)
+```typescript
+import { Capacitor } from "@capacitor/core";
+import { NotificationService } from "@/services/notifications";
+```
+
+**B. Add Platform Detection Property**
+```typescript
+// Add to class properties
+private get isNativePlatform(): boolean {
+  return Capacitor.isNativePlatform();
+}
+```
+
+**C. Modify `open()` Method** (Lines 170-258)
+- **Current**: Always initializes web push (VAPID key, service worker)
+- **Change**: Add platform check at start
+  - If native: Skip VAPID/service worker, show UI immediately
+  - If web: Keep existing logic
+
+**D. Modify `turnOnNotifications()` Method** (Lines 393-499)
+- **Current**: Web push subscription flow
+- **Change**: Split into two paths:
+  - **Native path**: Use `NotificationService.getInstance()` → `requestPermissions()` → `scheduleDailyNotification()`
+  - **Web path**: Keep existing logic
+
+**E. Add New Method: `turnOnNativeNotifications()`**
+- Request permissions via `NotificationService`
+- Convert time input (AM/PM) to 24-hour format (HH:mm)
+- Call `scheduleDailyNotification()` with proper options
+- Save to settings
+- Call callback with success/time/message
+
+**F. Update `handleTurnOnNotifications()` Method** (Line 643)
+- Add platform check
+- Route to `turnOnNativeNotifications()` or `turnOnNotifications()` based on platform
+
+**G. Update Computed Properties**
+- `isSystemReady`: For native, return `true` immediately (no VAPID needed)
+- `canShowNotificationForm`: For native, return `true` immediately
+
+**H. Update Template** (Optional - for better UX)
+- Add platform-specific messaging if desired
+- Native: "Notifications will be scheduled on your device"
+- Web: Keep existing messaging
+
+#### Code Structure Preview
+
+```typescript
+async open(pushType: string, callback?: ...) {
+  this.callback = callback || this.callback;
+  this.isVisible = true;
+  this.pushType = pushType;
+  
+  // Platform detection
+  if (this.isNativePlatform) {
+    // Native: No VAPID/service worker needed
+    this.serviceWorkerReady = true; // Fake it for UI
+    this.vapidKey = "native"; // Placeholder
+    return; // Skip web push initialization
+  }
+  
+  // Existing web push initialization...
+  // (keep all existing code)
+}
+
+async turnOnNotifications() {
+  if (this.isNativePlatform) {
+    return this.turnOnNativeNotifications();
+  }
+  // Existing web push logic...
+}
+
+private async turnOnNativeNotifications(): Promise<void> {
+  const service = NotificationService.getInstance();
+  
+  // Request permissions
+  const granted = await service.requestPermissions();
+  if (!granted) {
+    // Handle permission denial
+    return;
+  }
+  
+  // Convert time to 24-hour format
+  const time24h = this.convertTo24HourFormat();
+  
+  // Determine title and body based on pushType
+  const title = this.pushType === this.DAILY_CHECK_TITLE 
+    ? "Daily Check-In" 
+    : "Daily Reminder";
+  const body = this.pushType === this.DIRECT_PUSH_TITLE
+    ? this.messageInput
+    : "Time to check your TimeSafari activity";
+  
+  // Schedule notification
+  const success = await service.scheduleDailyNotification({
+    time: time24h,
+    title,
+    body,
+    priority: 'normal'
+  });
+  
+  if (success) {
+    // Save to settings
+    const timeText = this.notificationTimeText;
+    await this.$saveSettings({
+      [this.pushType === this.DAILY_CHECK_TITLE 
+        ? 'notifyingNewActivityTime' 
+        : 'notifyingReminderTime']: timeText,
+      ...(this.pushType === this.DIRECT_PUSH_TITLE && {
+        notifyingReminderMessage: this.messageInput
+      })
+    });
+    
+    // Call callback
+    this.callback(true, timeText, this.messageInput);
+  }
+}
+
+private convertTo24HourFormat(): string {
+  const hour = parseInt(this.hourInput);
+  const minute = parseInt(this.minuteInput);
+  
+  let hour24 = hour;
+  if (!this.hourAm && hour !== 12) {
+    hour24 = hour + 12;
+  } else if (this.hourAm && hour === 12) {
+    hour24 = 0;
+  }
+  
+  return `${hour24.toString().padStart(2, '0')}:${minute.toString().padStart(2, '0')}`;
+}
+```
+
+#### Testing Considerations
+- Test on iOS device
+- Test on Android device
+- Test on web (should still work as before)
+- Test permission denial flow
+- Test time conversion (AM/PM → 24-hour)
+
+---
+
+### 2. AccountViewView.vue
+
+**File**: `src/views/AccountViewView.vue`  
+**Current Lines**: 2124 lines  
+**Estimated New Lines**: +20-30 lines  
+**Complexity**: Low
+
+#### Changes Required
+
+**A. Add Import** (Top of script section, around line 739)
+```typescript
+import { Capacitor } from "@capacitor/core";
+```
+
+**B. Add Computed Property** (In class, around line 888)
+```typescript
+private get isNativePlatform(): boolean {
+  return Capacitor.isNativePlatform();
+}
+```
+
+**C. Modify Notification Toggle Methods** (Lines 1134-1202)
+
+**`showNewActivityNotificationChoice()`** (Lines 1134-1158)
+- **Current**: Always uses `PushNotificationPermission` component
+- **Change**: Add platform check
+  - If native: Use `NotificationService` directly (or still use component - it will handle platform)
+  - If web: Keep existing logic
+  - **Note**: Since we're updating `PushNotificationPermission` to handle both, this might not need changes, but we could add direct native path for cleaner code
+
+**`showReminderNotificationChoice()`** (Lines 1171-1202)
+- Same as above
+
+**D. Conditionally Hide Push Server Setting** (Lines 506-549)
+- Wrap the entire "Notification Push Server" section in `v-if="!isNativePlatform"`
+- This hides it on iOS/Android where it's not needed
+
+**E. Update Status Display** (Optional)
+- When showing notification status, could add platform indicator
+- "Native notification scheduled" vs "Web push subscription active"
+
+#### Code Structure Preview
+
+```typescript
+// Add computed property
+private get isNativePlatform(): boolean {
+  return Capacitor.isNativePlatform();
+}
+
+// In template, wrap push server section:
+<section v-if="!isNativePlatform" id="sectionPushServer">
+  <h2 class="text-slate-500 text-sm font-bold mb-2">
+    Notification Push Server
+  </h2>
+  <!-- ... existing push server UI ... -->
+</section>
+
+// Optional: Update notification choice methods
+async showNewActivityNotificationChoice(): Promise<void> {
+  if (!this.notifyingNewActivity) {
+    // Component now handles platform detection, so this can stay the same
+    // OR we could add direct native path here for cleaner separation
+    (this.$refs.pushNotificationPermission as PushNotificationPermission)
+      .open(DAILY_CHECK_TITLE, async (success: boolean, timeText: string) => {
+        // ... existing callback ...
+      });
+  } else {
+    // ... existing turn-off logic ...
+  }
+}
+```
+
+#### Testing Considerations
+- Verify push server section hidden on iOS
+- Verify push server section hidden on Android
+- Verify push server section visible on web
+- Test notification toggles work on all platforms
+
+---
+
+### 3. WebPushNotificationService.ts (Optional Enhancement)
+
+**File**: `src/services/notifications/WebPushNotificationService.ts`  
+**Current Lines**: 213 lines  
+**Estimated New Lines**: +100-150 lines  
+**Complexity**: Medium  
+**Priority**: Low (can be done later)
+
+#### Changes Required
+
+**A. Complete `scheduleDailyNotification()` Implementation**
+- Extract logic from `PushNotificationPermission.vue`
+- Subscribe to push service
+- Send subscription to server
+- Return success status
+
+**B. Complete `cancelDailyNotification()` Implementation**
+- Get current subscription
+- Unsubscribe from push service
+- Notify server to stop sending
+
+**C. Complete `getStatus()` Implementation**
+- Check settings for `notifyingNewActivityTime` / `notifyingReminderTime`
+- Check service worker subscription status
+- Return combined status
+
+**Note**: This is optional because `PushNotificationPermission.vue` already handles web push. Completing this would allow using `NotificationService` directly for web too, but it's not required for the integration to work.
+
+---
+
+## Implementation Order
+
+### Phase 1: Core Integration (Required)
+1. ✅ Update `PushNotificationPermission.vue` with platform detection
+2. ✅ Update `AccountViewView.vue` to hide push server on native
+3. ✅ Test on native platforms
+
+### Phase 2: Polish (Optional)
+4. Complete `WebPushNotificationService.ts` implementation
+5. Add platform-specific UI messaging
+6. Add status indicators
+
+---
+
+## Risk Assessment
+
+### Low Risk Changes
+- ✅ Adding platform detection (read-only check)
+- ✅ Conditionally hiding UI elements
+- ✅ Adding new code paths (not modifying existing)
+
+### Medium Risk Changes
+- ⚠️ Modifying `turnOnNotifications()` flow (but we're adding, not replacing)
+- ⚠️ Time format conversion (need to test edge cases)
+
+### Mitigation Strategies
+1. **Backward Compatibility**: All changes are additive - existing web push flow remains unchanged
+2. **Feature Flags**: Could add feature flag to enable/disable native notifications
+3. **Gradual Rollout**: Test on one platform first (e.g., Android), then iOS
+4. **Fallback**: If native service fails, could fall back to showing error message
+
+---
+
+## Testing Checklist
+
+### Functional Testing
+- [ ] Native iOS: Request permissions → Schedule notification → Verify scheduled
+- [ ] Native Android: Request permissions → Schedule notification → Verify scheduled
+- [ ] Web: Existing flow still works (no regression)
+- [ ] Permission denial: Shows appropriate error message
+- [ ] Time conversion: AM/PM correctly converts to 24-hour format
+- [ ] Both notification types: Daily Check and Direct Push work on native
+- [ ] Settings persistence: Times saved correctly to database
+
+### UI Testing
+- [ ] Push server setting hidden on iOS
+- [ ] Push server setting hidden on Android
+- [ ] Push server setting visible on web
+- [ ] Notification toggles work on all platforms
+- [ ] Time picker UI works on native (same as web)
+
+### Edge Cases
+- [ ] 12:00 AM conversion (should be 00:00)
+- [ ] 12:00 PM conversion (should be 12:00)
+- [ ] Invalid time input handling
+- [ ] App restart: Notifications still scheduled
+- [ ] Device reboot: Notifications still scheduled (Android)
+
+---
+
+## Dependencies
+
+### Required
+- ✅ `@capacitor/core` - Already in project
+- ✅ `@timesafari/daily-notification-plugin` - Already installed
+- ✅ `NotificationService` - Already created
+
+### No New Dependencies Needed
+
+---
+
+## Estimated Effort
+
+| Task | Time Estimate |
+|------|---------------|
+| Update PushNotificationPermission.vue | 2-3 hours |
+| Update AccountViewView.vue | 30 minutes - 1 hour |
+| Testing on iOS | 1-2 hours |
+| Testing on Android | 1-2 hours |
+| Bug fixes & polish | 1-2 hours |
+| **Total** | **5-10 hours** |
+
+---
+
+## Rollback Plan
+
+If issues arise:
+
+1. **Quick Rollback**: Revert changes to `PushNotificationPermission.vue` and `AccountViewView.vue`
+2. **Partial Rollback**: Keep platform detection but disable native path (feature flag)
+3. **No Data Migration Needed**: Settings structure unchanged
+
+---
+
+## Questions to Consider
+
+1. **Should we keep using `PushNotificationPermission` component for native, or create separate native flow?**
+   - **Recommendation**: Keep using component (simpler, less code duplication)
+
+2. **Should we show different UI messaging for native vs web?**
+   - **Recommendation**: Optional enhancement, not required for MVP
+
+3. **Should we complete `WebPushNotificationService` now or later?**
+   - **Recommendation**: Later (not blocking, existing component works)
+
+4. **How to handle notification cancellation on native?**
+   - **Recommendation**: Use `NotificationService.cancelDailyNotification()` in existing turn-off logic
+
+---
+
+## Next Steps After Implementation
+
+1. Update documentation with platform-specific instructions
+2. Add error handling for edge cases
+3. Consider adding notification status display in UI
+4. Test on real devices (critical for native notifications)
+5. Monitor for any platform-specific issues
+
+---
+
+**Last Updated**: 2026-01-23

doc/notification-new-activity-lay-of-the-land.md

@@ -0,0 +1,250 @@
+# Lay of the Land: API-Driven Daily Message (New Activity) and Web-Push Confusion
+
+**Purpose:** Shareable analysis of the New Activity (API-driven daily message) implementation and the root cause of “always fires / can’t be turned off.” For discussion with teammates.
+
+**Related:** `doc/notification-from-api-call.md` (plan and progress), teammate note about web-push confusion and possibly removing that logic.
+
+---
+
+## 1. Two Separate Notification Features
+
+There are **two** distinct native notification flows that both go through the same UI component:
+
+| Feature | Plugin API | Purpose |
+|--------|------------|--------|
+| **Daily Reminder** | `scheduleDailyNotification` / `cancelDailyReminder` | Single daily alarm, static title/body (user’s message). |
+| **New Activity** (API-driven) | `scheduleDualNotification` / `cancelDualSchedule` | Prefetch from API 5 min before, then notify at chosen time with API or fallback content. |
+
+- **Daily Reminder** is driven from AccountViewView’s “Daily Reminder” toggle; on native it uses `NotificationService.getInstance().scheduleDailyNotification()` / `cancelDailyNotification()` (backed by `NativeNotificationService` and a single `reminderId`: `"daily_timesafari_reminder"`).
+- **New Activity** is intended to be driven only by `scheduleNewActivityDualNotification()` / `cancelDualSchedule()` in AccountViewView (dual schedule only).
+
+So: one feature = single schedule (reminder), the other = dual schedule (prefetch + notify). They are different plugin APIs and different lifecycle (enable/disable) handling.
+
+---
+
+## 2. Where the Bug Comes From: One Dialog, Two Behaviors
+
+**New Activity** reuses the same dialog as Daily Reminder: **`PushNotificationPermission.vue`**.
+
+- When the user turns **New Activity** on from AccountViewView:
+  - AccountViewView opens this dialog with `DAILY_CHECK_TITLE` and a callback that, on success, calls `scheduleNewActivityDualNotification(timeText)` on native.
+  - The dialog does **not** receive `skipSchedule: true` for this flow (only the “edit reminder” flow does).
+
+So when the user clicks “Turn on Daily Reminder” in the dialog for **New Activity**:
+
+1. **PushNotificationPermission** (native path) runs `turnOnNativeNotifications()` and always calls:
+   - `service.scheduleDailyNotification({ time, title: "Daily Check-In", body: "Time to check your TimeSafari activity", ... })`
+   - i.e. it schedules the **single** daily reminder (plugin’s `scheduleDailyNotification`), using the same `reminderId` as Daily Reminder (`"daily_timesafari_reminder"`).
+2. Then the callback runs and AccountViewView calls **`scheduleNewActivityDualNotification(timeText)`**, which calls the plugin’s **`scheduleDualNotification`**.
+
+Result:
+
+- **Two schedules** are created when enabling New Activity:
+  - One **single** reminder (wrong for New Activity): static “Daily Check-In” message, same ID as Daily Reminder.
+  - One **dual** schedule (correct): prefetch + notify with API/fallback content.
+- When the user turns **New Activity** off, AccountViewView only calls **`cancelDualSchedule()`**. It never calls `cancelDailyNotification()` (or equivalent) for the single reminder.
+- So the **single** reminder stays scheduled and keeps firing at the chosen time. That’s the notification that “always fires” and “can’t be turned off.”
+
+So the “huge problem with confusion with the web-push” is really: **the same dialog and the same “Turn on” path are used for both Daily Reminder and New Activity, but the dialog always schedules the single daily reminder on native**, while New Activity is supposed to use only the dual schedule. That mixing is what makes the wrong schedule stick and not be cancellable from the New Activity toggle.
+
+---
+
+## 3. Key Files and Flows
+
+- **`src/components/PushNotificationPermission.vue`**
+  - Shared dialog for both “Daily Reminder” and “New Activity” (via `pushType` = `DIRECT_PUSH_TITLE` vs `DAILY_CHECK_TITLE`).
+  - On native it always uses `NotificationService.getInstance().scheduleDailyNotification(...)` (single reminder) and does not branch on “New Activity” to skip scheduling or to call the dual API.
+  - Saves `notifyingNewActivityTime` when `pushType === DAILY_CHECK_TITLE` (lines 834–836). So the dialog both schedules the wrong thing and persists settings for New Activity.
+
+- **`src/views/AccountViewView.vue`**
+  - **Daily Reminder:** toggle opens same dialog with `DIRECT_PUSH_TITLE`; on native, disable path calls `service.cancelDailyNotification()`.
+  - **New Activity:** toggle opens same dialog with `DAILY_CHECK_TITLE`; on success callback calls `scheduleNewActivityDualNotification(timeText)`; on disable only calls `DailyNotification.cancelDualSchedule()`.
+  - `initializeState()`: on native with `activeDid`, calls `configureNativeFetcherIfReady(activeDid)` and, if New Activity is on, `updateStarredPlans(...)`. It does **not** re-call `scheduleNewActivityDualNotification` on load (so no double dual-schedule from here).
+
+- **`src/services/notifications/NativeNotificationService.ts`**
+  - Single reminder only: `scheduleDailyNotification` → plugin `scheduleDailyNotification` with `id: this.reminderId` (`"daily_timesafari_reminder"`); `cancelDailyNotification` → `cancelDailyReminder({ reminderId })`. No dual API here.
+
+- **`src/services/notifications/nativeFetcherConfig.ts`**
+  - Only configures the plugin for API calls (JWT, apiBaseUrl, activeDid). No scheduling.
+
+- **`src/services/notifications/dualScheduleConfig.ts`**
+  - Builds config for `scheduleDualNotification` (contentFetch 5 min before, userNotification at notify time). Used only from AccountViewView’s `scheduleNewActivityDualNotification`.
+
+- **`src/main.capacitor.ts`**
+  - Imports the daily-notification plugin; after a 2s delay calls `configureNativeFetcherIfReady()`. No scheduling; only fetcher config.
+
+So: the “always fires / can’t turn off” behavior is from the **single** reminder created in `PushNotificationPermission` for New Activity and never cancelled when New Activity is turned off. The “confusion with web-push” is the reuse of the same dialog and the same native “schedule single reminder” path for both features.
+
+---
+
+## 4. Plugin Usage Summary
+
+- **Single daily reminder (Daily Reminder):**
+  - Scheduled/cancelled via `NativeNotificationService.scheduleDailyNotification` / `cancelDailyNotification` → plugin `scheduleDailyNotification` / `cancelDailyReminder` with one `reminderId`.
+- **Dual schedule (New Activity):**
+  - Scheduled/cancelled only in AccountViewView via `DailyNotification.scheduleDualNotification` / `cancelDualSchedule` (and `configureNativeFetcherIfReady` + `updateStarredPlans` as per doc).
+- **Fetcher config (New Activity):**
+  - `configureNativeFetcherIfReady()` from main.capacitor and from AccountViewView `initializeState` / `scheduleNewActivityDualNotification`; no scheduling by itself.
+
+---
+
+## 5. Root Cause (Concise)
+
+- **Single code path in PushNotificationPermission** for native: it always schedules the **single** daily reminder, regardless of `pushType` (Daily Reminder vs New Activity).
+- For **New Activity**, that creates an extra, wrong schedule (single reminder) in addition to the correct dual schedule.
+- **Disable path for New Activity** only calls `cancelDualSchedule()` and never cancels the single reminder, so that reminder keeps firing and appears as “always fires” and “can’t be turned off.”
+
+---
+
+## 6. Proper Fix: Options and Detail
+
+A fix should ensure that (1) enabling New Activity creates only the dual schedule, and (2) disabling New Activity removes every schedule that was created for it. Below are concrete options and implementation notes.
+
+### 6.1 Option A: Don’t schedule the single reminder when the dialog is for New Activity (recommended)
+
+**Idea:** On native, when the dialog is opened for **New Activity** (`pushType === DAILY_CHECK_TITLE`), the dialog should **not** call `scheduleDailyNotification`. Only the callback in AccountViewView should run, and it already calls `scheduleNewActivityDualNotification(timeText)`, which uses the dual API only.
+
+**Where:** `PushNotificationPermission.vue`, inside `turnOnNativeNotifications()`.
+
+**Implementation sketch:**
+
+- After requesting permissions and before calling `service.scheduleDailyNotification(...)`, branch on `pushType` and platform:
+  - If native **and** `pushType === this.DAILY_CHECK_TITLE`: skip the `scheduleDailyNotification` call entirely. Still run the rest of the flow (e.g. build `timeText`, save settings if desired, call `callback(true, timeText, ...)`). AccountViewView’s callback will then call `scheduleNewActivityDualNotification(timeText)` and that is the only schedule created for New Activity.
+  - Otherwise (web, or Daily Reminder on native): keep current behavior and call `scheduleDailyNotification` as today.
+
+**Pros:** Single source of truth for “what is scheduled for New Activity” (dual only). No leftover single reminder to cancel later. Clear separation: dialog collects time + permission; AccountViewView owns native scheduling for New Activity.
+
+**Cons:** Dialog’s native path now has two behaviors (schedule vs no schedule) depending on `pushType`; needs a quick comment so future changes don’t regress.
+
+**Note:** The “edit reminder” flow already uses `skipSchedule: true` so the dialog doesn’t schedule; only the parent does. For New Activity enable, we’re doing the same idea: dialog doesn’t schedule on native, parent does.
+
+### 6.2 Option B: When turning New Activity off, also cancel the single reminder
+
+**Idea:** Assume the wrong single reminder might already exist (e.g. from before the fix, or from a different code path). When the user turns **New Activity** off, in addition to `cancelDualSchedule()`, call the service’s `cancelDailyNotification()` so the single reminder (same `reminderId` as Daily Reminder) is cancelled too.
+
+**Where:** `AccountViewView.vue`, inside the disable branch of `showNewActivityNotificationChoice()` (where we currently only call `DailyNotification.cancelDualSchedule()`).
+
+**Implementation sketch:**
+
+- On native, when user confirms “turn off New Activity”:
+  1. Call `DailyNotification.cancelDualSchedule()` (existing).
+  2. Call `NotificationService.getInstance().cancelDailyNotification()` (new) so any single reminder that was mistakenly scheduled for this flow is removed.
+
+**Pros:** Defensive: cleans up the bad schedule even if it was created in the past or by another path. Complements Option A (e.g. A prevents new wrong schedules; B cleans up existing ones).
+
+**Cons:** That single `reminderId` is shared with **Daily Reminder**. If the user has **Daily Reminder** on and **New Activity** on, then turns only **New Activity** off, we must not cancel the reminder they still want for Daily Reminder. So either:
+- Only call `cancelDailyNotification()` when we’re sure the single reminder was created for New Activity (e.g. we don’t have a separate “New Activity reminder ID”), which is hard without more state, or
+- Don’t use Option B alone as the primary fix: use Option A so we never create the single reminder for New Activity, and only add B if we decide we need a one-time cleanup or a safety net (with care not to cancel Daily Reminder’s schedule).
+
+**Recommendation:** Use Option A as the main fix. Add Option B only if the team agrees we need to cancel the single reminder on “New Activity off” and can do so without affecting Daily Reminder (e.g. by introducing a distinct reminder ID for a “New Activity legacy” reminder and only cancelling that, or by documenting that B is a one-time migration and not long-term behavior).
+
+### 6.3 Optional cleanup: Separate reminder IDs or dialog responsibilities
+
+- **Separate reminder IDs:** Today both Daily Reminder and the mistaken New Activity single reminder use `"daily_timesafari_reminder"`. If we ever want to support “both features on” and cancel only one, we’d need a second ID (e.g. one for Daily Reminder, one for New Activity). With Option A in place, New Activity no longer creates a single reminder, so we might not need a second ID unless we add a dedicated “New Activity fallback” single alarm later.
+- **Dialog responsibilities:** We could narrow the dialog’s role when used for New Activity on native to “collect time + request permission and report success,” and leave all scheduling to AccountViewView. That’s what Option A does without necessarily refactoring the rest of the dialog (e.g. web push, Daily Reminder) in the same change.
+- **Removing web-push logic for New Activity:** If the team decides to “totally remove” web-push logic that was added for New Activity, that would be a separate change (e.g. ensure New Activity on web either uses a different mechanism or is explicitly unsupported). The lay-of-the-land and this fix section focus on native; web can be scoped in a follow-up.
+
+---
+
+## 7. Testing New Activity on a Real Device (iOS or Android)
+
+Use this section to verify the New Activity flow end-to-end on a physical device after implementing the fix (or to reproduce the current bug).
+
+### Prerequisites
+
+- **Build:** Native app built and installed (e.g. `npx cap sync` then build/run from Xcode or Android Studio), or a dev build on device.
+- **Identity:** User is signed in (active DID set) so `configureNativeFetcherIfReady` and the native fetcher can use a valid JWT.
+- **Endorser API URL:** New Activity prefetch uses **Account → API Server URL** (the Endorser base URL passed to `configureNativeFetcher`), not the Partner API URL. You can run these tests against **production, test, or local Endorser** (e.g. the test preset `https://test-api.endorser.ch`); use an identity, JWT, and starred plans that exist on **that** server. Changing only **Partner API** URL does not change where `plansLastUpdatedBetween` is called.
+- **Optional:** One or more starred plans so the API can return activity; with zero starred plans the notification should still show with a sensible fallback (e.g. “No updates in your starred projects”).
+
+### Enable flow
+
+1. Open **Account** (Profile).
+2. In the **Notifications** section, turn **New Activity Notification** on.
+3. In the dialog, choose a time. For quick testing, set the device clock or pick a time **2–5 minutes from now** (e.g. if it’s 14:00, choose 14:03).
+4. Tap **Turn on Daily Reminder** (or equivalent), grant notification permission when the OS prompts, and confirm the dialog closes and the toggle shows on with the chosen time.
+5. **Background the app** (home or switch to another app). The prefetch runs ~5 minutes before the chosen time; the user notification fires at the chosen time.
+
+### What to verify (after fix)
+
+- **One notification** at the chosen time, with content from the API or the fallback text (e.g. “Check your starred projects and offers for updates.”). You should **not** see a second, static “Daily Check-In” / “Time to check your TimeSafari activity” notification from the old single-reminder path.
+- **Before the fix:** You may see two notifications (one static from the mistaken single schedule, one from the dual schedule), and turning New Activity off will only stop the dual one; the static one will keep firing.
+
+### Disable flow
+
+1. On **Account**, turn **New Activity Notification** off and confirm in the “turn off” dialog.
+2. Wait until the next occurrence of the previously chosen time (or use the same “time a few minutes ahead” trick and wait). **No notification** should appear. If one still appears, the single reminder was not cancelled (current bug or Option B not applied correctly).
+
+### Device-specific notes
+
+- **Android:** This app has **exact alarm disabled** (no `SCHEDULE_EXACT_ALARM`). Notification permission must be granted; delivery may be inexact or batched by the system. If the app is killed by the OS, behavior may depend on plugin boot/recovery behavior.
+- **iOS:** Notification permission and background capabilities (e.g. background fetch) may affect prefetch. Test with app in background, not force-quit.
+- **Time zone:** The chosen time is in the device’s local time. Ensure the device date/time and time zone are correct when testing.
+
+### Optional test cases
+
+- **No starred plans:** Enable New Activity with no starred projects; confirm no crash and a sensible fallback message in the notification.
+- **JWT / API errors:** After leaving the app in background for a long time, the JWT may expire. Re-opening Account (or app) may re-run `configureNativeFetcherIfReady`; document or test whether a new notification still gets valid content or shows fallback.
+- **Daily Reminder and New Activity both on:** With the fix, turning off only New Activity should not affect the Daily Reminder notification (they use different plugin APIs; Option B must not cancel the single reminder if the user still has Daily Reminder on).
+
+### Testing: starred project with new activity (Android native fetcher)
+
+Use this to verify that when a **starred** plan has **new** activity reported by `plansLastUpdatedBetween`, the notification shows API-derived copy (not only the dual-schedule default from `dualScheduleConfig.ts`).
+
+The steps and expected notification copy below are **Android-specific**: this repo registers `TimeSafariNativeFetcher` only on Android today. Do not assume the same strings or behavior on iOS until native fetcher parity exists; see **`doc/notification-from-api-call.md`** (iOS checklist and remaining tasks).
+
+**How it works (short):** On Android, `TimeSafariNativeFetcher` POSTs to `/api/v2/report/plansLastUpdatedBetween` with `planIds` from the plugin (`updateStarredPlans`) and `afterId` from stored `last_acked_jwt_id` (or `"0"` initially). When the response `data` array is **non-empty**, the fetcher builds **one** `NotificationContent`: title **Starred Project Update** (one row) or **Starred Project Updates** (two or more rows); body uses each row’s `plan.name` when present (else **Unnamed Project**). For a single update: `[name] has been updated.` For multiple: typographic quotes around the first row’s name, then ` + N more have been updated.` (with `N` = number of additional rows). When `data` is **empty**, the fetcher returns **no** notification items (no “nothing to report” notification). (See `android/app/src/main/java/app/timesafari/TimeSafariNativeFetcher.java`.)
+
+**Procedure (repeatable on device)**
+
+1. Sign in on the Endorser environment you mean to test (e.g. test API URL in Account—see **Prerequisites**, Endorser API URL) so `configureNativeFetcherIfReady` can set JWT and `activeDid`.
+2. Star at least one project you can change (e.g. your own test plan on staging).
+3. Turn **New Activity Notification** on and pick a time **2–5 minutes ahead** (same quick-test pattern as above).
+4. Open **Account** once (or finish the enable flow) so `updateStarredPlans({ planIds })` runs with current `starredPlanHandleIds`.
+5. **Background the app** (home out; do not force-quit). Prefetch runs on the cron **~5 minutes before** the chosen time; the user notification fires at the chosen time.
+6. **Produce new activity the API will return:** before that prefetch window (i.e. early enough that the scheduled content fetch still sees it), make a real change to the starred plan so `plansLastUpdatedBetween` returns **new** rows after the current `afterId` (e.g. an edit or other update your backend exposes through that report). If you change the plan **after** prefetch already ran with no new rows, you may not get an API-derived notification until the next prefetch cycle (typically the next day at the same T−5 schedule, unless you reschedule).
+
+**What to verify**
+
+- **One notification** at the chosen time (no extra static “Daily Check-In” after the fix—see “What to verify (after fix)” above).
+- **Success path (API returns updates):** Title/body match **Starred Project Update(s)** and the `[name] has been updated.` / `[first name] + N more have been updated.` patterns (names from `plan.name`), not the generic `buildDualScheduleConfig` defaults (**New Activity** / **Check your starred projects and offers for updates.**), which apply when the plugin falls back—e.g. fetch failure—not when the Android fetcher successfully returns Endorser-parsed content.
+- **Contrast (cursor caught up, no new rows):** After a successful fetch that returned data, `last_acked_jwt_id` advances. Without further plan changes, a later prefetch may return an empty `data` array; the fetcher then supplies **no** Endorser-derived notification (useful to compare against the “has activity” case; the plugin may still show dual-schedule fallback text depending on configuration).
+
+**Repeatability:** Each successful fetch that returns data moves the `afterId` cursor forward. To see **Starred Project Update** copy again on subsequent tests, make **another** qualifying plan change (or accept heavier setup such as clearing app/plugin storage to reset cursor—usually unnecessary).
+
+**Debugging:** On Android, filter **logcat** for `TimeSafariNativeFetcher` (e.g. HTTP 200, `Fetched N notification(s)`) to confirm prefetch ran and how many `NotificationContent` items were built.
+
+**Note:** The in-app **New Activity** screen loads starred changes via the JS stack; the **push** path uses the native fetcher and plugin cache. Validate the notification using **background + prefetch timing**, not only by opening that screen.
+
+---
+
+## 8. Plugin Repo Alignment and Attention Items
+
+Comparison with the **daily-notification-plugin** repo on gitea (`trent_larson/daily-notification-plugin`, `master` or the tag this app pins) to confirm our documentation and usage line up, and to flag anything that needs attention for the New Activity feature.
+
+### 8.1 What lines up
+
+- **API surface:** Plugin `definitions.ts` exposes `configureNativeFetcher({ apiBaseUrl, activeDid, jwtToken })`, `scheduleDualNotification(config)`, `cancelDualSchedule()`, `updateStarredPlans({ planIds })`, `scheduleDailyNotification(options)`, and `cancelDailyReminder(reminderId)`. Our app uses these as described in this doc; `buildDualScheduleConfig` produces a `DualScheduleConfiguration` that matches the plugin’s `ContentFetchConfig` / `UserNotificationConfig` / `relationship` shape (cron schedules, title/body, `callbacks: {}`, `fallbackBehavior: "show_default"`, etc.).
+- **Native fetcher:** Plugin is designed for a host-supplied JWT via `configureNativeFetcher` and a native fetcher implementation (e.g. Android `TimeSafariNativeFetcher`). Our `nativeFetcherConfig.ts` and Android `TimeSafariNativeFetcher.java` follow that model; prefetch runs in the plugin’s background workers and uses the configured credentials.
+- **Dual vs single:** The plugin clearly separates:
+  - **Single daily path:** `scheduleDailyNotification(options)` (with `id` on Android) and `cancelDailyReminder(reminderId)` (iOS uses `reminder_<reminderId>` for the static-reminder path).
+  - **Dual path:** `scheduleDualNotification(config)` and `cancelDualSchedule()`.  
+  So our analysis that “two schedules” are created when the dialog schedules the single reminder and AccountViewView schedules the dual is consistent with the plugin.
+- **Exact alarm:** The plugin’s Android implementation does **not** require exact alarm: it proceeds with scheduling using inexact/windowed alarms when exact is not granted. The plugin’s `INTEGRATION_GUIDE.md` still shows `SCHEDULE_EXACT_ALARM` in the manifest example; this app has chosen to disable exact alarm, and the plugin supports that. No doc change needed beyond what we already state in section 7.
+
+### 8.2 Attention items
+
+- **`cancelDailyReminder` signature:** In the plugin’s `definitions.ts`, `cancelDailyReminder(reminderId: string)`. The app calls it with an object: `cancelDailyReminder({ reminderId })`. On iOS the plugin uses `call.getString("reminderId")`, so the object form works. If the plugin’s TypeScript definition is ever used for strict typing, prefer updating the plugin to accept `{ reminderId: string }` or document that the bridge accepts an object with a `reminderId` key.
+- **Plugin INTEGRATION_GUIDE vs this app:** The guide describes generic polling, dual scheduling, and optional `SCHEDULE_EXACT_ALARM`. This app uses the dual-schedule + native-fetcher path only (no generic polling), and does not use exact alarm. When onboarding or debugging, treat the guide as the full plugin feature set; our flow is the “legacy dual scheduling” + native fetcher part plus `updateStarredPlans` and `configureNativeFetcher`.
+- **iOS `scheduleDailyNotification` and stable `id`:** On **Android**, the plugin uses `options.getString("id")` as the stable `scheduleId` for “one per day” semantics and cleanup. On **iOS**, the implementation in the repo was observed to build notification content with an internally generated id (e.g. `daily_<timestamp>`) and not obviously use the app-provided `id` from the call. If the app ever relies on a stable id on iOS for the single reminder (e.g. to cancel or replace only that reminder), it’s worth confirming in the plugin’s iOS code whether the call’s `id` is read and used; if not, consider requesting or contributing a change so iOS also uses the app-provided id for consistency with Android.
+- **Dual schedule and content fetch:** The plugin’s dual schedule runs the content-fetch job on its cron and then the user notification at the configured time; our config uses a 5-minute gap and `relationship.contentTimeout` / `fallbackBehavior: "show_default"`. The native fetcher is invoked by the plugin’s background layer when the content-fetch schedule fires; we don’t rely on JS `callbacks` in the config (we pass `callbacks: {}`). That matches the “native fetcher does the work” design.
+
+### 8.3 iOS `UNIMPLEMENTED` on `scheduleDualNotification` (other methods work)
+
+If iOS logs `scheduleNewActivityDualNotification failed: {"code":"UNIMPLEMENTED"}` while `configureNativeFetcher` succeeds, Capacitor is often rejecting the call in **JavaScript** because `scheduleDualNotification` is missing from `window.Capacitor.PluginHeaders` for `DailyNotification` (stale **Pods / Xcode binary** after upgrading the plugin). **Not** usually a missing Swift handler if `node_modules` already lists the method in `pluginMethods`.
+
+**Recovery:** `npx cap sync ios`, `cd ios/App && pod install`, Xcode **Clean Build Folder**, rebuild. See **`doc/plugin-feedback-ios-scheduleDualNotification.md`** (troubleshooting section).
+
+### 8.4 Summary
+
+The plugin repo aligns with how we use it for New Activity (dual schedule + native fetcher, no generic polling, exact alarm optional). The main follow-ups are: (1) clarify or align `cancelDailyReminder` argument shape in the plugin if needed for typing/tooling, and (2) confirm on iOS whether `scheduleDailyNotification` uses the app-provided `id` for stable single-reminder semantics.

doc/notification-permissions-and-rollovers.md

@@ -0,0 +1,238 @@
+# Notification Permissions & Rollover Handling
+
+**Date**: 2026-01-23  
+**Purpose**: Answers to questions about permission requests and rollover handling
+
+---
+
+## Question 1: Where does the notification permission request happen?
+
+### Permission Request Flow
+
+The permission request flows through multiple layers:
+
+```
+User clicks "Turn on Daily Message"
+    ↓
+PushNotificationPermission.vue
+    ↓ (line 715)
+service.requestPermissions()
+    ↓
+NotificationService.getInstance()
+    ↓ (platform detection)
+NativeNotificationService.requestPermissions()
+    ↓ (line 53)
+DailyNotification.requestPermissions()
+    ↓
+Plugin Native Code
+    ↓
+┌─────────────────────┬─────────────────────┐
+│   iOS Platform      │   Android Platform   │
+├─────────────────────┼─────────────────────┤
+│ UNUserNotification  │ ActivityCompat       │
+│ Center.current()    │ .requestPermissions()│
+│ .requestAuthorization│                     │
+│ (options: [.alert, │ (POST_NOTIFICATIONS) │
+│  .sound, .badge])   │                     │
+└─────────────────────┴─────────────────────┘
+    ↓
+Native OS Permission Dialog
+    ↓
+User grants/denies
+    ↓
+Result returned to app
+```
+
+### Code Locations
+
+**1. UI Entry Point** (`src/components/PushNotificationPermission.vue`):
+```typescript
+// Line 715
+const granted = await service.requestPermissions();
+```
+
+**2. Service Layer** (`src/services/notifications/NativeNotificationService.ts`):
+```typescript
+// Lines 49-68
+async requestPermissions(): Promise<boolean> {
+  const result = await DailyNotification.requestPermissions();
+  return result.allPermissionsGranted;
+}
+```
+
+**3. Plugin Registration** (`src/plugins/DailyNotificationPlugin.ts`):
+```typescript
+// Line 30-36
+const DailyNotification = registerPlugin<DailyNotificationPluginType>(
+  "DailyNotification"
+);
+```
+
+**4. iOS Native Implementation** (`node_modules/@timesafari/daily-notification-plugin/ios/Plugin/DailyNotificationScheduler.swift`):
+```swift
+// Lines 113-115
+func requestPermissions() async -> Bool {
+    let granted = try await notificationCenter.requestAuthorization(
+        options: [.alert, .sound, .badge]
+    )
+    return granted
+}
+```
+
+**5. Android Native Implementation** (`node_modules/@timesafari/daily-notification-plugin/android/src/main/java/com/timesafari/dailynotification/PermissionManager.java`):
+```java
+// Line 87
+ActivityCompat.requestPermissions(
+    activity,
+    new String[]{Manifest.permission.POST_NOTIFICATIONS},
+    REQUEST_CODE
+);
+```
+
+### Platform-Specific Details
+
+#### iOS
+- **API Used**: `UNUserNotificationCenter.requestAuthorization()`
+- **Options Requested**: `.alert`, `.sound`, `.badge`
+- **Dialog**: System-native iOS permission dialog
+- **Location**: First time user enables notifications
+- **Result**: Returns `true` if granted, `false` if denied
+
+#### Android
+- **API Used**: `ActivityCompat.requestPermissions()`
+- **Permission**: `POST_NOTIFICATIONS` (Android 13+)
+- **Dialog**: System-native Android permission dialog
+- **Location**: First time user enables notifications
+- **Result**: Returns `true` if granted, `false` if denied
+- **Note**: Android 12 and below don't require runtime permission (declared in manifest)
+
+### When Permission Request Happens
+
+The permission request is triggered when:
+1. User opens the notification setup dialog (`PushNotificationPermission.vue`)
+2. User clicks "Turn on Daily Message" button
+3. App detects native platform (`isNativePlatform === true`)
+4. `turnOnNativeNotifications()` method is called
+5. `service.requestPermissions()` is called (line 715)
+
+**Important**: The permission dialog only appears **once** per app installation. After that:
+- If granted: Future calls to `requestPermissions()` return `true` immediately
+- If denied: User must manually enable in system settings
+
+---
+
+## Question 2: Does the plugin handle rollovers automatically?
+
+### ✅ Yes - Rollover Handling is Automatic
+
+The plugin **automatically handles rollovers** in multiple scenarios:
+
+### 1. Initial Scheduling (Time Has Passed Today)
+
+**Location**: `ios/Plugin/DailyNotificationScheduler.swift` (lines 326-329)
+
+```swift
+// If time has passed today, schedule for tomorrow
+if scheduledDate <= now {
+    scheduledDate = calendar.date(byAdding: .day, value: 1, to: scheduledDate) ?? scheduledDate
+}
+```
+
+**Behavior**: 
+- If user schedules a notification for 9:00 AM but it's already 10:00 AM today
+- Plugin automatically schedules it for 9:00 AM **tomorrow**
+- No manual intervention needed
+
+### 2. Daily Rollover (After Notification Fires)
+
+**Location**: `ios/Plugin/DailyNotificationScheduler.swift` (lines 437-609)
+
+The plugin has a `scheduleNextNotification()` function that:
+- Automatically schedules the next day's notification after current one fires
+- Handles 24-hour rollovers with DST (Daylight Saving Time) awareness
+- Prevents duplicate rollovers with state tracking
+
+**Key Function**: `calculateNextScheduledTime()` (lines 397-435)
+```swift
+// Add 24 hours (handles DST transitions automatically)
+guard let nextDate = calendar.date(byAdding: .hour, value: 24, to: currentDate) else {
+    // Fallback to simple 24-hour addition
+    return currentScheduledTime + (24 * 60 * 60 * 1000)
+}
+```
+
+**Features**:
+- ✅ DST-safe: Uses Calendar API to handle daylight saving transitions
+- ✅ Automatic: No manual scheduling needed
+- ✅ Persistent: Survives app restarts and device reboots
+- ✅ Duplicate prevention: Tracks rollover state to prevent duplicates
+
+### 3. Rollover State Tracking
+
+**Location**: `ios/Plugin/DailyNotificationStorage.swift` (lines 161-195)
+
+The plugin tracks rollover state to prevent duplicate scheduling:
+
+```swift
+// Check if rollover was processed recently (< 1 hour ago)
+if let lastTime = lastRolloverTime,
+   (currentTime - lastTime) < (60 * 60 * 1000) {
+    // Skip - already processed
+    return false
+}
+```
+
+**Purpose**: Prevents multiple rollover attempts if notification fires multiple times
+
+### 4. Android Rollover Handling
+
+Android implementation also handles rollovers:
+- Uses `AlarmManager` with `setRepeating()` or schedules next alarm after current fires
+- Handles timezone changes and DST transitions
+- Persists across device reboots via `BootReceiver`
+
+### Rollover Scenarios Handled
+
+| Scenario | Handled? | How |
+|----------|----------|-----|
+| Time passed today | ✅ Yes | Schedules for tomorrow automatically |
+| Daily rollover | ✅ Yes | Schedules next day after notification fires |
+| DST transitions | ✅ Yes | Uses Calendar API for DST-aware calculations |
+| Device reboot | ✅ Yes | BootReceiver restores schedules |
+| App restart | ✅ Yes | Schedules persist in database |
+| Duplicate prevention | ✅ Yes | State tracking prevents duplicate rollovers |
+
+### Verification
+
+You can verify rollover handling by:
+
+1. **Check iOS logs** for rollover messages:
+   ```
+   DNP-ROLLOVER: START id=... current_time=... scheduled_time=...
+   DNP-ROLLOVER: CALC_NEXT current=... next=... diff_hours=24.00
+   ```
+
+2. **Test scenario**: Schedule notification for a time that's already passed today
+   - Expected: Notification scheduled for tomorrow at same time
+
+3. **Test scenario**: Wait for notification to fire
+   - Expected: Next day's notification automatically scheduled
+
+### Summary
+
+✅ **Permission Request**: Happens in native plugin code via platform-specific APIs:
+- iOS: `UNUserNotificationCenter.requestAuthorization()`
+- Android: `ActivityCompat.requestPermissions()`
+
+✅ **Rollover Handling**: Fully automatic:
+- Initial scheduling: If time passed, schedules for tomorrow
+- Daily rollover: Automatically schedules next day after notification fires
+- DST handling: Calendar-aware calculations
+- Duplicate prevention: State tracking prevents issues
+- Persistence: Survives app restarts and device reboots
+
+**No manual intervention needed** - the plugin handles all rollover scenarios automatically!
+
+---
+
+**Last Updated**: 2026-01-23

doc/notification-system-overview.md

@@ -0,0 +1,378 @@
+# Notification System Overview
+
+**Date**: 2026-01-23  
+**Purpose**: Understanding notification architecture and implementation guide for daily-notification-plugin
+
+---
+
+## Executive Summary
+
+Your app has **two separate notification systems** that coexist:
+
+1. **Web Push Notifications** (Web/PWA platforms)
+   - Uses service workers, VAPID keys, and a push server
+   - Requires the "Notification Push Server" setting
+   - Server-based delivery
+
+2. **Native Notifications** (iOS/Android via DailyNotificationPlugin)
+   - Uses native OS notification APIs
+   - On-device scheduling (no server needed)
+   - The "Notification Push Server" setting is **NOT used** for native
+
+The system automatically selects the correct implementation based on platform using `Capacitor.isNativePlatform()`.
+
+---
+
+## Notification Push Server Setting
+
+### Location
+- **File**: `src/views/AccountViewView.vue` (lines 506-549)
+- **UI Section**: Advanced Settings → "Notification Push Server"
+- **Database Field**: `settings.webPushServer`
+
+### Purpose
+The "Notification Push Server" setting **ONLY applies to Web Push notifications** (web/PWA platforms). It configures:
+
+1. **VAPID Key Retrieval**: The server URL used to fetch VAPID (Voluntary Application Server Identification) keys
+2. **Subscription Endpoint**: Where push subscriptions are sent
+3. **Push Message Delivery**: The server that sends push messages to browsers
+
+### How It Works (Web Push Flow)
+
+```
+User enables notification
+    ↓
+PushNotificationPermission.vue opens
+    ↓
+Fetches VAPID key from: {webPushServer}/web-push/vapid
+    ↓
+Subscribes to browser push service
+    ↓
+Sends subscription + time + message to: {webPushServer}/web-push/subscribe
+    ↓
+Server stores subscription and schedules push messages
+    ↓
+Server sends push messages at scheduled time via browser push service
+```
+
+### Key Code Locations
+
+**AccountViewView.vue** (lines 1473-1479):
+```typescript
+async onClickSavePushServer(): Promise<void> {
+  await this.$saveSettings({
+    webPushServer: this.webPushServerInput,
+  });
+  this.webPushServer = this.webPushServerInput;
+  this.notify.warning(ACCOUNT_VIEW_CONSTANTS.INFO.RELOAD_VAPID);
+}
+```
+
+**PushNotificationPermission.vue** (lines 177-221):
+- Retrieves `webPushServer` from settings
+- Fetches VAPID key from `{webPushServer}/web-push/vapid`
+- Uses VAPID key to subscribe to push notifications
+
+**PushNotificationPermission.vue** (lines 556-575):
+- Sends subscription to `/web-push/subscribe` endpoint (relative URL, handled by service worker)
+
+### Important Notes
+
+- ⚠️ **This setting is NOT used for native iOS/Android notifications**
+- The setting defaults to `DEFAULT_PUSH_SERVER` if not configured
+- Changing the server requires reloading VAPID keys (hence the warning message)
+- Local development (`http://localhost`) skips VAPID key retrieval
+
+---
+
+## Daily Notification Plugin Integration
+
+### Current Status
+
+✅ **Infrastructure Complete**:
+- Plugin registered (`src/plugins/DailyNotificationPlugin.ts`)
+- Service abstraction layer created (`src/services/notifications/`)
+- Platform detection working
+- Native implementation ready (`NativeNotificationService.ts`)
+
+🔄 **UI Integration Needed**:
+- `PushNotificationPermission.vue` still uses web push logic
+- AccountViewView notification toggles need platform detection
+- Settings storage needs to handle both systems
+
+### Architecture
+
+```
+NotificationService.getInstance()
+    ↓
+Platform Detection (Capacitor.isNativePlatform())
+    ↓
+┌─────────────────────┬─────────────────────┐
+│   Native Platform   │    Web Platform      │
+│   (iOS/Android)     │    (Web/PWA)         │
+├─────────────────────┼─────────────────────┤
+│ NativeNotification  │ WebPushNotification  │
+│ Service             │ Service              │
+│                     │                      │
+│ Uses:               │ Uses:                │
+│ - DailyNotification │ - Service Workers   │
+│   Plugin            │ - VAPID Keys         │
+│ - Native OS APIs    │ - Push Server        │
+│ - On-device alarms  │ - Server scheduling  │
+└─────────────────────┴─────────────────────┘
+```
+
+### Key Differences
+
+| Feature | Native (Plugin) | Web Push |
+|---------|----------------|----------|
+| **Server Required** | ❌ No | ✅ Yes (Notification Push Server) |
+| **Scheduling** | On-device | Server-side |
+| **Offline Delivery** | ✅ Yes | ❌ No (requires network) |
+| **Background Support** | ✅ Full | ⚠️ Limited (browser-dependent) |
+| **Permission Model** | OS-level | Browser-level |
+| **Settings Storage** | Local only | Local + server subscription |
+
+---
+
+## Implementation Recommendations
+
+### 1. Update PushNotificationPermission Component
+
+**Current State**: Only handles web push
+
+**Recommended Changes**:
+
+```typescript
+// In PushNotificationPermission.vue
+import { NotificationService } from '@/services/notifications';
+import { Capacitor } from '@capacitor/core';
+
+async open(pushType: string, callback?: ...) {
+  const isNative = Capacitor.isNativePlatform();
+  
+  if (isNative) {
+    // Use native notification service
+    const service = NotificationService.getInstance();
+    const granted = await service.requestPermissions();
+    
+    if (granted) {
+      // Show time picker UI
+      // Then schedule via service.scheduleDailyNotification()
+    }
+  } else {
+    // Existing web push logic
+    // ... current implementation ...
+  }
+}
+```
+
+### 2. Update AccountViewView Notification Toggles
+
+**Current State**: Always uses `PushNotificationPermission` component (web push)
+
+**Recommended Changes**:
+
+```typescript
+// In AccountViewView.vue
+import { NotificationService } from '@/services/notifications';
+import { Capacitor } from '@capacitor/core';
+
+async showNewActivityNotificationChoice(): Promise<void> {
+  const isNative = Capacitor.isNativePlatform();
+  
+  if (isNative) {
+    // Use native service directly
+    const service = NotificationService.getInstance();
+    // Show time picker, then schedule
+  } else {
+    // Use existing PushNotificationPermission component
+    (this.$refs.pushNotificationPermission as PushNotificationPermission)
+      .open(DAILY_CHECK_TITLE, ...);
+  }
+}
+```
+
+### 3. Settings Storage Strategy
+
+**Current Settings Fields** (from `src/db/tables/settings.ts`):
+- `notifyingNewActivityTime` - Time string for daily check
+- `notifyingReminderTime` - Time string for reminder
+- `notifyingReminderMessage` - Reminder message text
+- `webPushServer` - Push server URL (web only)
+
+**Recommendation**: These settings work for both systems:
+- ✅ `notifyingNewActivityTime` - Works for both (native stores locally, web sends to server)
+- ✅ `notifyingReminderTime` - Works for both
+- ✅ `notifyingReminderMessage` - Works for both
+- ⚠️ `webPushServer` - Only used for web push (hide on native platforms)
+
+### 4. Platform-Aware UI
+
+**Recommendations**:
+
+1. **Hide "Notification Push Server" setting on native platforms**:
+   ```vue
+   <h2 v-if="!isNativePlatform" class="text-slate-500 text-sm font-bold mb-2">
+     Notification Push Server
+   </h2>
+   ```
+
+2. **Update help text** to explain platform differences
+
+3. **Show different messaging** based on platform:
+   - Native: "Notifications are scheduled on your device"
+   - Web: "Notifications are sent via push server"
+
+---
+
+## Notification Types
+
+Your app supports two notification types:
+
+### 1. Daily Check (`DAILY_CHECK_TITLE`)
+- **Purpose**: Notify user of new activity/updates
+- **Message**: Auto-generated by server (web) or app (native)
+- **Settings Field**: `notifyingNewActivityTime`
+
+### 2. Direct Push (`DIRECT_PUSH_TITLE`)
+- **Purpose**: Daily reminder with custom message
+- **Message**: User-provided (max 100 characters)
+- **Settings Fields**: `notifyingReminderTime`, `notifyingReminderMessage`
+
+Both types can be enabled simultaneously.
+
+---
+
+## Code Flow Examples
+
+### Native Notification Flow (Recommended Implementation)
+
+```typescript
+// 1. Get service instance
+const service = NotificationService.getInstance();
+
+// 2. Request permissions
+const granted = await service.requestPermissions();
+if (!granted) {
+  // Show error, guide to settings
+  return;
+}
+
+// 3. Schedule notification
+await service.scheduleDailyNotification({
+  time: '09:00', // HH:mm format (24-hour)
+  title: 'Daily Check-In',
+  body: 'Time to check your TimeSafari activity',
+  priority: 'normal'
+});
+
+// 4. Save to settings
+await this.$saveSettings({
+  notifyingNewActivityTime: '09:00'
+});
+
+// 5. Check status
+const status = await service.getStatus();
+console.log('Enabled:', status.enabled);
+console.log('Time:', status.scheduledTime);
+```
+
+### Web Push Flow (Current Implementation)
+
+```typescript
+// 1. Open PushNotificationPermission component
+(this.$refs.pushNotificationPermission as PushNotificationPermission)
+  .open(DAILY_CHECK_TITLE, async (success, timeText) => {
+    if (success) {
+      // Component handles:
+      // - VAPID key retrieval from webPushServer
+      // - Service worker subscription
+      // - Sending subscription to server
+      
+      // Just save the time
+      await this.$saveSettings({
+        notifyingNewActivityTime: timeText
+      });
+    }
+  });
+```
+
+---
+
+## Testing Checklist
+
+### Native (iOS/Android)
+- [ ] Request permissions works
+- [ ] Notification appears at scheduled time
+- [ ] Notification survives app close
+- [ ] Notification survives device reboot
+- [ ] Both notification types can be enabled
+- [ ] Cancellation works correctly
+
+### Web Push
+- [ ] VAPID key retrieval works
+- [ ] Service worker subscription works
+- [ ] Subscription sent to server
+- [ ] Push messages received at scheduled time
+- [ ] Works with different push server URLs
+
+### Platform Detection
+- [ ] Correct service selected on iOS
+- [ ] Correct service selected on Android
+- [ ] Correct service selected on web
+- [ ] Settings UI shows/hides appropriately
+
+---
+
+## Key Files Reference
+
+### Core Notification Services
+- `src/services/notifications/NotificationService.ts` - Factory/selector
+- `src/services/notifications/NativeNotificationService.ts` - Native implementation
+- `src/services/notifications/WebPushNotificationService.ts` - Web implementation (stub)
+
+### UI Components
+- `src/components/PushNotificationPermission.vue` - Web push UI (needs update)
+- `src/views/AccountViewView.vue` - Settings UI (lines 506-549 for push server)
+
+### Settings & Constants
+- `src/db/tables/settings.ts` - Settings schema
+- `src/constants/app.ts` - `DEFAULT_PUSH_SERVER` constant
+- `src/libs/util.ts` - `DAILY_CHECK_TITLE`, `DIRECT_PUSH_TITLE`
+
+### Plugin
+- `src/plugins/DailyNotificationPlugin.ts` - Plugin registration
+
+---
+
+## Next Steps
+
+1. **Update `PushNotificationPermission.vue`** to detect platform and use appropriate service
+2. **Update `AccountViewView.vue`** notification toggles to use platform detection
+3. **Hide "Notification Push Server" setting** on native platforms
+4. **Test on real devices** (iOS and Android)
+5. **Update documentation** with platform-specific instructions
+
+---
+
+## Questions & Answers
+
+**Q: Do I need to configure the Notification Push Server for native apps?**  
+A: No. The setting is only for web push. Native notifications are scheduled on-device.
+
+**Q: Can both notification systems be active at the same time?**  
+A: No, they're mutually exclusive per platform. The app automatically selects the correct one.
+
+**Q: How do I test native notifications?**  
+A: Use `NotificationService.getInstance()` and test on a real device (simulators have limitations).
+
+**Q: What happens if I change the push server URL?**  
+A: Only affects web push. Users need to re-subscribe to push notifications with the new server.
+
+**Q: Can I use the same settings fields for both systems?**  
+A: Yes! The time and message fields work for both. Only `webPushServer` is web-specific.
+
+---
+
+**Last Updated**: 2026-01-23

doc/plan-background-jwt-pool-and-expiry.md

@@ -0,0 +1,203 @@
+# Plan: Background New Activity JWT — extended expiry + token pool
+
+**Date:** 2026-03-27 14:29 PST  
+**Status:** Draft for implementation  
+**Audience:** TimeSafari / crowd-funder developers  
+**Related:** `doc/endorser-jwt-background-prefetch-options.md`, `android/.../TimeSafariNativeFetcher.java`, `src/services/notifications/nativeFetcherConfig.ts`, `src/libs/crypto/index.ts`
+
+---
+
+## 1. Problem statement
+
+Background prefetch for New Activity calls Endorser with a Bearer JWT configured via `configureNativeFetcher`. The token previously came from `getHeaders()` → `accessToken()`, which used **`exp` ≈ 60 seconds** (`src/libs/crypto/index.ts`). Prefetch runs **minutes later** in WorkManager **without JavaScript**, so the JWT can be **expired** before the POST (`JWT_VERIFY_FAILED`).
+
+**Goals:**
+
+1. Use JWTs whose **`exp`** covers the gap between **last app-side configure** and **prefetch** (and ideally days without opening the app).
+2. Optionally support a **pool** of distinct JWT strings so Endorser can enforce **duplicate-JWT** / **one-time-use** rules without breaking daily prefetch. **Pool size** should follow **`expiryDays + buffer`** (one distinct token per day over the JWT lifetime, plus headroom for retries / edge cases); **implementation uses `BACKGROUND_JWT_POOL_SIZE = 100`** until policy changes.
+3. Keep pool size and expiry policy **easy to change** (constants / remote config later).
+
+---
+
+## 2. Guiding principles
+
+| Principle | Implication |
+|-----------|-------------|
+| **Background has no JS** | Token selection and HTTP must run in **native** (or plugin) code using **persisted** data. |
+| **Single source of truth for signing** | Continue using **`createEndorserJwtForDid`** (same keys as today); do not fork crypto in Java/Kotlin. |
+| **Configurable pool size** | One constant `BACKGROUND_JWT_POOL_SIZE`; **currently 100**. Size should satisfy **`≥ expiryDays + buffer`** (see below). |
+| **Phased delivery** | Ship **extended expiry** first; add **pool** when server duplicate rules require it or in the same release if coordinated. |
+
+### 2.1 Pool size rationale (`expiryDays + buffer`)
+
+For **one New Activity prefetch per day**, each day should use a **distinct** JWT string if the server rejects reuse. Over the JWT lifetime (aligned with **`exp`**), you need at least **one token per day** the pool might be used without regeneration.
+
+**Rule of thumb:**
+
+```text
+BACKGROUND_JWT_POOL_SIZE ≥ ceil(BACKGROUND_JWT_EXPIRY_DAYS) + BACKGROUND_JWT_POOL_BUFFER
+```
+
+- **`BACKGROUND_JWT_EXPIRY_DAYS`** — human-facing match to `exp` (e.g. **90**); convert to `BACKGROUND_JWT_EXPIRY_SECONDS` for the payload.
+- **`BACKGROUND_JWT_POOL_BUFFER`** — extra slots for **same-day retries**, manual tests, or stricter duplicate rules (e.g. **10**).
+
+**Example:** 90‑day `exp` + buffer 10 ⇒ **minimum 100** logical slots. **This plan keeps `BACKGROUND_JWT_POOL_SIZE = 100`** as the shipped default so it matches that example; if `expiryDays` or buffer change later, **bump the constant** so the inequality still holds.
+
+---
+
+## 3. Phases
+
+### Phase A — Extended expiry only (minimum viable)
+
+**Scope**
+
+- Introduce a dedicated mint path for **background / native fetcher** use (name TBD, e.g. `accessTokenForBackgroundNotifications(did)`), producing **one** JWT per configure call with:
+  - `iss`: DID (unchanged)
+  - `iat`: now
+  - `exp`: now + **`BACKGROUND_JWT_EXPIRY_SECONDS`** (derived from **`BACKGROUND_JWT_EXPIRY_DAYS`**; see §2.1 / Phase B constants — **confirm** with Endorser policy)
+  - Optional: `jti` or nonce for uniqueness if needed for logging/debug
+
+- **`configureNativeFetcherIfReady`** should pass this token (or keep using a thin wrapper) instead of reusing the **60s** `accessToken()` when configuring native fetcher **only** — **do not** change interactive `getHeaders()` / passkey caching behavior for normal API calls unless product asks for it.
+
+**Files (likely)**
+
+- `src/libs/crypto/index.ts` — new function or parameters; keep `accessToken()` default at 60s for existing callers.
+- `src/services/notifications/nativeFetcherConfig.ts` — obtain background JWT via the new mint path, not `getHeaders()`’s generic path, **or** add a dedicated branch that calls the new mint after resolving `did`.
+
+**Native**
+
+- **`TimeSafariNativeFetcher`**: still one `jwtToken` field; no pool yet. Ensure `configure()` is called whenever TS refreshes (startup, resume, Account — already partially covered).
+
+**Exit criteria**
+
+- Logcat: prefetch POST returns **200** (or non-expired 4xx) when user has not opened the app for several **minutes** after configure.
+- Endorser accepts **`exp`** far enough in the future (coordinate TTL policy).
+
+---
+
+### Phase B — Token pool (size 100; driven by `expiryDays + buffer`)
+
+**Why**
+
+- Endorser may **reject duplicate JWT strings** (same bearer used twice). One long-lived token could fail on **day 2** if the server marks each JWT as consumed.
+- A **pool** of **N** distinct JWTs (different payload, e.g. unique `jti` per token) gives **N** independent strings with the same long **`exp`**. **N** should follow **§2.1** (`expiryDays + buffer`); **100** is the initial **`BACKGROUND_JWT_POOL_SIZE`** (satisfies e.g. 90 + 10).
+
+**Scope**
+
+1. **Constants** (single place, e.g. `src/constants/backgroundJwt.ts` or next to native fetcher config):
+
+   ```text
+   BACKGROUND_JWT_EXPIRY_DAYS = 90              // align with Endorser; drives exp
+   BACKGROUND_JWT_EXPIRY_SECONDS = 90 * 24 * 60 * 60  // derived
+   BACKGROUND_JWT_POOL_BUFFER = 10            // retries / headroom; tune with server team
+   BACKGROUND_JWT_POOL_SIZE = 100               // must be >= expiryDays + buffer; adjust if policy changes
+   ```
+
+2. **Mint in TS** (uses `createEndorserJwtForDid`):
+
+   - Loop `i = 0 .. POOL_SIZE - 1`
+   - Payload: `{ iss, iat, exp, jti: `${did}#bg#${i}` or uuid }` — **confirm** `jti` format with Endorser if required.
+
+3. **Persistence** — native code must read the pool **without JS**:
+
+   - **Option B1 (preferred):** Implement in **`@timesafari/daily-notification-plugin`** (not in the app): extend **`configureNativeFetcher`** to accept an optional JWT pool, persist it for native read. **Handoff spec:** `doc/plugin-feedback-daily-notification-configureNativeFetcher-jwt-pool.md` — copy or reference that file in the plugin repo PR.
+   - **Option B2 (app-only, no plugin release):** Write JSON to **Capacitor Preferences** or **encrypted storage** from TS; **TimeSafariNativeFetcher** reads the same store on Android (requires knowing Capacitor’s Android `SharedPreferences` name/key convention or a tiny **bridge** in `MainActivity`). Use only if plugin work is deferred.
+
+4. **Selection policy in `TimeSafariNativeFetcher`** (before each POST):
+
+   - **By calendar day:** `index = (epochDay + offset) % POOL_SIZE` (stable per day).
+   - Or **sequential:** persist `lastUsedIndex` in prefs and increment (wrap). **Decision:** document chosen policy; day-based is easier to reason about for “one token per day.”
+
+5. **configureNativeFetcherIfReady** (and any “reset notifications on startup” hook):
+
+   - Regenerate full pool when user opens app (per product decision), then call configure with pool + **current** `apiBaseUrl` / `did`.
+
+6. **iOS:** When iOS native fetcher exists, mirror Android behavior.
+
+**Exit criteria**
+
+- Prefetch succeeds on **consecutive days** with duplicate-JWT enforcement enabled on a **staging** Endorser.
+- Pool **refreshes** on startup without breaking dual schedule.
+
+---
+
+## 4. Detailed tasks (checklist)
+
+### Crypto & TypeScript
+
+- [ ] Add `BACKGROUND_JWT_EXPIRY_DAYS`, `BACKGROUND_JWT_EXPIRY_SECONDS`, `BACKGROUND_JWT_POOL_BUFFER`, and `BACKGROUND_JWT_POOL_SIZE` (exported constants), with a **comment** that `POOL_SIZE >= expiryDays + buffer` (see §2.1).
+- [ ] Implement `mintBackgroundJwtPool(did: string): Promise<string[]>` (or split single + pool).
+- [ ] Ensure each JWT has **unique** `jti` (or equivalent) for duplicate detection.
+- [ ] **Do not** break existing `accessToken()` 60s behavior for unrelated features.
+- [ ] Wire `configureNativeFetcherIfReady` to pass **single extended token** (Phase A) then **pool** (Phase B).
+- [ ] On **logout / identity clear**, clear persisted pool and call plugin clear if needed.
+
+### Android
+
+- [ ] **Phase A:** No structural change if `configure()` still receives one string; verify non-null `jwtToken` after configure.
+- [ ] **Phase B:** Parse pool from persisted JSON; implement `selectTokenForRequest()`; use selected token in `Authorization` header instead of sole `jwtToken` field (keep `configure` for `apiBaseUrl` / `did`).
+- [ ] Unit or instrumentation tests optional: selection index deterministic.
+
+### Plugin (Option B1 — **daily-notification-plugin** repo)
+
+- [ ] Follow **`doc/plugin-feedback-daily-notification-configureNativeFetcher-jwt-pool.md`** (API shape, Android/iOS, versioning).
+- [ ] Release new plugin version; bump dependency in this app.
+
+### Product & server
+
+- [ ] Endorser: confirm **max `exp`**, **duplicate JWT** semantics, recommended **`jti`** format.
+- [ ] Document operational limit: if user never opens app for **longer than `exp` allows** (or longer than **pool × daily use** without refresh), prefetch may fail until next open — align with `doc/endorser-jwt-background-prefetch-options.md`.
+
+---
+
+## 5. Security notes
+
+- Longer-lived JWTs and **many** tokens increase impact if device is compromised. Mitigations: **encrypted prefs** where possible, **no logging** of full JWTs, **revocation** story with Endorser (key rotation, deny list).
+- Pool regeneration on **login** should replace old pools.
+
+---
+
+## 6. Testing plan
+
+| Test | Expected |
+|------|----------|
+| Configure → wait **> 5 min** → prefetch | **200** from `plansLastUpdatedBetween` (Phase A) |
+| Two consecutive **days** with duplicate-JWT staging | **200** both days (Phase B) |
+| Logout | Pool cleared; no stale bearer |
+| Lower `BACKGROUND_JWT_POOL_SIZE` in dev only (below `expiryDays + buffer`) | Expect possible reuse / server duplicate errors — use to reproduce failures |
+
+---
+
+## 7. Rollout / staging
+
+1. Implement Phase A behind feature flag **optional** (or direct if low risk).
+2. Verify on **test-api.endorser.ch** with server team.
+3. Phase B behind flag or same release once server duplicate rules are understood.
+
+---
+
+## 8. Where plugin documentation lives
+
+| Document | Purpose |
+|----------|---------|
+| **`doc/plan-background-jwt-pool-and-expiry.md`** (this file) | End-to-end app plan: crypto, pool sizing, native host, rollout. |
+| **`doc/plugin-feedback-daily-notification-configureNativeFetcher-jwt-pool.md`** | **Plugin-only** handoff: extend `configureNativeFetcher`, persist pool, Android/iOS notes — intended for PRs in **daily-notification-plugin** (or Cursor on that repo). |
+
+Keeping them **separate** avoids mixing consumer app tasks with plugin API contract; the plan **links** to the plugin feedback doc for Option B1.
+
+---
+
+## 9. References
+
+| Topic | Location |
+|--------|----------|
+| Current 60s `accessToken` | `src/libs/crypto/index.ts` |
+| `createEndorserJwtForDid` | `src/libs/endorserServer.ts` |
+| Native configure | `src/services/notifications/nativeFetcherConfig.ts` |
+| Android HTTP | `android/.../TimeSafariNativeFetcher.java` |
+| Options doc (TTL, refresh, BFF) | `doc/endorser-jwt-background-prefetch-options.md` |
+| Plugin: `configureNativeFetcher` + JWT pool | `doc/plugin-feedback-daily-notification-configureNativeFetcher-jwt-pool.md` |
+
+---
+
+*Update this plan when Phase A/B ship or when Endorser policy changes.*

doc/plugin-android-edit-reschedule-alarm-not-firing.md

@@ -0,0 +1,27 @@
+# Plugin: Android — Alarm set after edit doesn’t fire (cancel-before-reschedule)
+
+**Context:** Consuming app (TimeSafari) — user sets reminder at 6:57pm (fires), then edits to 7:00pm. Only one `scheduleDailyNotification` call is made (skipSchedule fix). Logs show "Scheduling OS alarm" and "Updated schedule in database" for 19:00, but the notification never fires at 7:00pm.
+
+**Likely cause (plugin):** In `NotifyReceiver.kt`, before calling `setAlarmClock(pendingIntent)` the code:
+
+1. Creates `pendingIntent` with `PendingIntent.getBroadcast(..., requestCode, intent, FLAG_UPDATE_CURRENT | FLAG_IMMUTABLE)`.
+2. Gets `existingPendingIntent` with `PendingIntent.getBroadcast(..., requestCode, intent, FLAG_NO_CREATE | FLAG_IMMUTABLE)` (same `requestCode`, same `intent`).
+3. If not null: `alarmManager.cancel(existingPendingIntent)` and **`existingPendingIntent.cancel()`**.
+4. Then calls `alarmManager.setAlarmClock(alarmClockInfo, pendingIntent)`.
+
+On Android, PendingIntent equality for caching is based on requestCode and Intent (action, component, etc.), not necessarily all extras. So `existingPendingIntent` is often the **same** (cached) PendingIntent as `pendingIntent`. Then we call **`existingPendingIntent.cancel()`**, which cancels that PendingIntent for future use. We then use the same (now cancelled) PendingIntent in **`setAlarmClock(..., pendingIntent)`**. On some devices/versions, setting an alarm with a cancelled PendingIntent can result in the alarm not firing.
+
+**Suggested fix (plugin repo):**
+
+- Remove the **`existingPendingIntent.cancel()`** call. Use only **`alarmManager.cancel(existingPendingIntent)`** to clear any existing alarm for this requestCode. That way the PendingIntent we pass to `setAlarmClock` is not cancelled; only the previous alarm is removed.
+- Optionally: only run the “cancel existing” block when we know there was a previous schedule (e.g. from DB) for this scheduleId that hasn’t fired yet, so we don’t cancel when the previous alarm already fired (e.g. user edited after first fire).
+
+**Verification:**
+
+- In the consuming app: set reminder 2–3 min from now, let it fire, then edit to 2–3 min from then and save. Capture logcat through the second scheduled time.
+- If the receiver never logs at the second time, the OS didn’t deliver the alarm; fixing the cancel-before-reschedule logic as above should be tried first in the plugin.
+
+**References:**
+
+- CONSUMING_APP_ANDROID_NOTES.md (double schedule, alarm scheduled but not firing).
+- NotifyReceiver.kt around “Cancelling existing alarm before rescheduling” and the following `setAlarmClock` use of `pendingIntent`.

doc/plugin-feedback-android-6-api23-zoneid-fix.md

@@ -0,0 +1,71 @@
+# Plugin fix: Android 6.0 (API 23) compatibility — replace java.time.ZoneId with TimeZone
+
+**Date:** 2026-02-27  
+**Target repo:** daily-notification-plugin  
+**Consuming app:** crowd-funder-for-time-pwa (TimeSafari)  
+**Platform:** Android
+
+---
+
+## Summary
+
+On Android 6.0 (API 23), the plugin crashes at runtime when scheduling a daily notification because it uses `java.time.ZoneId`, which is only available from **API 26**. Replacing that with `java.util.TimeZone.getDefault().getID()` restores compatibility with API 23 and has **no functional impact** on API 26+ (same timezone ID string, same behavior).
+
+---
+
+## Problem
+
+- **File:** `android/src/main/java/com/timesafari/dailynotification/NotifyReceiver.kt`
+- **Approximate location:** inside `scheduleExactNotification()`, when building `NotificationContentEntity` (around line 260).
+
+The code uses:
+
+```kotlin
+java.time.ZoneId.systemDefault().id
+```
+
+On API 23 this causes a runtime failure (e.g. `NoClassDefFoundError`) when the scheduling path runs, because `java.time` was added to Android only in API 26 (Oreo).
+
+---
+
+## Required change
+
+Replace the `java.time` call with the API-1–compatible equivalent.
+
+**Before:**
+
+```kotlin
+java.time.ZoneId.systemDefault().id
+```
+
+**After:**
+
+```kotlin
+java.util.TimeZone.getDefault().id
+```
+
+Use this in the same place where `NotificationContentEntity` is constructed (the parameter that stores the system timezone ID string). No other code changes are needed.
+
+---
+
+## Why this is safe on newer Android
+
+- Both `ZoneId.systemDefault().id` and `TimeZone.getDefault().id` refer to the **same** system default timezone and return the **same** IANA timezone ID string (e.g. `"America/Los_Angeles"`, `"Europe/London"`).
+- Any downstream logic that reads this string (e.g. for display or next-run calculation) behaves identically on API 26+.
+- No change to data format or semantics; this is a backward-compatible drop-in replacement.
+
+---
+
+## Verification
+
+1. **Build:** From a consuming app (e.g. crowd-funder-for-time-pwa) with `minSdkVersion = 23`, run a full Android build including the plugin. No compilation errors.
+2. **Runtime on API 23:** On an Android 6.0 device or emulator, enable daily notifications and schedule a time. The app should not crash; the notification should be scheduled and (after the delay) fire.
+3. **Runtime on API 26+:** Confirm scheduling and delivery still work as before on Android 8+.
+
+---
+
+## Context (consuming app)
+
+- App and plugin both declare `minSdkVersion = 23` (Android 6.0). AlarmManager, permissions, and notification paths in the plugin are already API-23 safe; this `java.time` usage is the only blocker for running on Android 6.0 devices.
+
+Use this document when applying the fix in the **daily-notification-plugin** repo (e.g. in Cursor). After changing the plugin, update the consuming app’s dependency (e.g. `npm update @timesafari/daily-notification-plugin` or point at the fixed commit), then `npx cap sync android` and rebuild.

doc/plugin-feedback-android-dual-schedule-native-fetch-and-timing.md

@@ -0,0 +1,126 @@
+# Plugin feedback: Android dual schedule — native fetcher not used; fetch timing wrong
+
+**Date:** 2026-03-24 21:56 PST  
+**Target repo:** `@timesafari/daily-notification-plugin` (daily-notification-plugin)  
+**Consuming app:** crowd-funder-for-time-pwa (TimeSafari)  
+**Platform:** Android (Kotlin / Java)  
+**Related:** New Activity notifications (`scheduleDualNotification` / `cancelDualSchedule`)
+
+---
+
+## Summary
+
+On Android, the **dual (New Activity) schedule** path is **not** implementing the intended contract:
+
+1. **Prefetch does not call `NativeNotificationContentFetcher`.**  
+   `ScheduleHelper.scheduleDualNotification` delegates fetch to `FetchWorker` (HTTP GET to optional `url`, or **mock JSON** when `url` is absent). The host app’s `TimeSafariNativeFetcher` is **never** invoked. Logcat shows `DNP-FETCH: Starting content fetch from: null, notificationTime=0` and **no** `TimeSafariNativeFetcher` `fetchContent` lines.
+
+2. **Fetch is not scheduled at `contentFetch.schedule` (e.g. T−5 minutes).**  
+   `FetchWorker.enqueueFetch` enqueues **immediate** `OneTimeWorkRequest` work (no `setInitialDelay` aligned to the fetch cron). The **notify** alarm is scheduled correctly for `dual_notify_*`, but there is **no** corresponding alarm/work at the **fetch** cron time. A `dual_fetch_*` row may exist in the DB with `nextRunAt`, but the **actual** fetch runs at **enable/setup time**, not at T−5.
+
+3. **Cache vs `DualScheduleHelper` / `contentTimeout`.**  
+   `DualScheduleHelper.resolveDualContentBlocking` only uses `contentCache` when the latest fetch is within `relationship.contentTimeout` (e.g. 5 minutes). If fetch runs **once at setup** and notify fires **~9+ minutes later**, cache is **stale** → `useCache=false` → default title/body from `userNotification`, even when mock payload was stored.
+
+**Recommended direction (plugin):**
+
+- For dual schedule when **no HTTP `url`** is configured (or when a flag indicates native mode), run **`NativeNotificationContentFetcher.fetchContent(FetchContext)`** (same path as `DailyNotificationFetchWorker` uses), persist results into the same `contentCache` / pipeline `DualScheduleHelper` expects.
+- **Schedule** that work (or an alarm that enqueues it) **at** `calculateNextRunTime(contentFetch.schedule)` — i.e. **before** the notify alarm, typically **5 minutes** earlier per app cron (see consuming app `timeToCronFiveMinutesBefore`).
+- Optionally align **one** scheduling mechanism: either exact alarm for fetch + notify, or WorkManager with **initial delay** to the next fetch instant (and reschedule after run).
+
+---
+
+## Symptoms (consuming app + logcat)
+
+- Notification shows **default** copy from `userNotification` (`title` / `body` from `buildDualScheduleConfig`), not API-derived or native “No updates” copy.
+- Logcat: `DNP-DUAL: Resolved dual content: useCache=false` at notify time.
+- Logcat: `DNP-FETCH: Starting content fetch from: null, notificationTime=0` followed by `Content fetch completed successfully` **at schedule/setup time**, not at T−5.
+- **No** `TimeSafariNativeFetcher` `fetchContent START` / `POST …/plansLastUpdatedBetween` during prefetch window (host registers `NativeNotificationContentFetcher` and logs on configure + fetch).
+- **No** activity at the **prefetch cron** time (e.g. 19:05 for notify at 19:10); only **notify** fires at T.
+
+---
+
+## What the consuming app sends (contract)
+
+**File:** `src/services/notifications/dualScheduleConfig.ts`
+
+- `contentFetch.enabled: true`
+- `contentFetch.schedule`: cron **5 minutes before** `userNotification.schedule` (e.g. `"25 19 * * *"` for notify `"30 19 * * *"`).
+- **No** `contentFetch.url` — intended to use **native** Endorser API via `configureNativeFetcher` + `NativeNotificationContentFetcher`.
+- `relationship.autoLink: true`, `relationship.contentTimeout: 5 * 60 * 1000`, `fallbackBehavior: "show_default"`.
+
+**Host app:** `android/.../TimeSafariNativeFetcher.java` implements `NativeNotificationContentFetcher` and calls `POST /api/v2/report/plansLastUpdatedBetween` with starred plan IDs from `updateStarredPlans`.
+
+---
+
+## Root cause (plugin code — paths to review)
+
+These paths are from a local clone of **daily-notification-plugin**; line numbers may drift.
+
+### 1. `FetchWorker` is URL/mock-only; does not call native fetcher
+
+`android/src/main/java/org/timesafari/dailynotification/FetchWorker.kt`
+
+- `enqueueFetch` passes `config.url` into `InputData`; `doWork` logs `Starting content fetch from: $url`.
+- `fetchContent(url, …)` when `url` is null/blank returns **`generateMockContent()`** — never calls `DailyNotificationPlugin.getNativeFetcherStatic().fetchContent(...)`.
+
+### 2. `scheduleDualNotification` runs fetch work immediately, not at fetch cron
+
+`android/src/main/java/org/timesafari/dailynotification/DailyNotificationPlugin.kt` — `object ScheduleHelper`, `suspend fun scheduleDualNotification(...)`
+
+- Calls `scheduleFetch(context, contentFetchConfig)` which resolves to `FetchWorker.scheduleFetchForDual` → `enqueueFetch` **without** delay tied to `contentFetchConfig.schedule`.
+- Schedules **notify** via `NotifyReceiver.scheduleExactNotification` for `dual_notify_*` at `calculateNextRunTime(userNotificationConfig.schedule)`.
+- Persists `dual_fetch_*` with `nextRunAt = calculateNextRunTime(contentFetchConfig.schedule)` but **no** matching alarm/work is scheduled for that instant in the current flow (as observed).
+
+### 3. Native fetcher exists elsewhere
+
+`android/src/main/java/org/timesafari/dailynotification/DailyNotificationFetchWorker.java`
+
+- Contains logic to call `NativeNotificationContentFetcher.fetchContent(FetchContext)` (with timeout). Dual schedule **does not** enqueue this worker for the TimeSafari `contentFetch` payload.
+
+### 4. `DualScheduleHelper` behavior is consistent with “wrong fetch time”
+
+`android/src/main/java/org/timesafari/dailynotification/DualScheduleHelper.kt`
+
+- Uses latest `contentCache` only if `(now - fetchedAt) <= contentTimeoutMs`. If fetch ran at setup and notify is **later** than `contentTimeout`, **cache is ignored** → `useCache=false` in logs.
+
+---
+
+## Acceptance criteria (plugin)
+
+After a fix, on a device with:
+
+- `configureNativeFetcher` + `updateStarredPlans` called (host app),
+- `scheduleDualNotification` with `contentFetch.enabled: true`, no `url`, cron 5 min before notify,
+
+then:
+
+1. **At or before** the notify fire time, **within** `contentTimeout`, the cache used by `DualScheduleHelper` reflects **native** fetch results when the API returns data (or empty), not only mock JSON.
+2. Logcat **includes** host tag `TimeSafariNativeFetcher` with `fetchContent START` (or equivalent) **when** prefetch runs, **or** plugin logs an explicit `NativeNotificationContentFetcher` invocation.
+3. Prefetch **does not** run only at **INITIAL_SETUP**; it runs at the **next** occurrence of `contentFetch.schedule` (and reschedules for the following day after success, same as notify rollover).
+4. **Optional:** If `url` is set, preserve HTTP GET behavior; if `url` is absent and native fetcher is registered, use native path.
+
+---
+
+## References in consuming app
+
+| Topic | Location |
+|--------|----------|
+| Dual config builder | `src/services/notifications/dualScheduleConfig.ts` |
+| `scheduleDualNotification` call | `src/views/AccountViewView.vue` (`scheduleNewActivityDualNotification`, `editNewActivityNotification`) |
+| Native fetcher | `android/app/src/main/java/app/timesafari/TimeSafariNativeFetcher.java` |
+| Registration | `MainActivity` / plugin init (host registers `DailyNotificationPlugin.setNativeFetcher`) |
+
+---
+
+## Notes for Cursor / implementers
+
+- **Do not** assume `contentFetch.url` is present; TimeSafari intentionally omits it for native API.
+- **Reuse** the same `FetchContext` / timeout semantics as `DailyNotificationFetchWorker` where possible to avoid two divergent native fetch implementations.
+- After changing timing, **verify** `WorkManager` unique work name `fetch_dual` / `cancelDualSchedule` still cancel only dual fetch and do not break daily reminder.
+
+---
+
+## Related docs in this repo
+
+- `doc/notification-from-api-call.md` — integration plan for API-driven New Activity.
+- `doc/plugin-feedback-android-scheduleDualNotification-contentFetch-json.md` — optional `timeout` / `retry*` JSON parsing (already addressed on the plugin side).

doc/plugin-feedback-android-duplicate-reminder-notification.md

@@ -0,0 +1,114 @@
+# Plugin feedback: Android duplicate reminder notification on first-time setup
+
+**Date:** 2026-02-18  
+**Generated:** 2026-02-18 17:47:06 PST  
+**Target repo:** `@timesafari/daily-notification-plugin` (https://gitea.anomalistdesign.com/trent_larson/daily-notification-plugin)  
+**Consuming app:** crowd-funder-for-time-pwa (TimeSafari)  
+**Platform:** Android
+
+## Summary
+
+When the user sets a **Reminder Notification for the first time** (toggle on → set message and time in `PushNotificationPermission`), **two notifications** fire at the scheduled time:
+
+1. **Correct one:** User’s chosen title/message, from the static reminder alarm (`scheduleId` = `daily_timesafari_reminder`).
+2. **Extra one:** Fallback message (“Daily Update” / “🌅 Good morning! Ready to make today amazing?”), from a second alarm that uses a **UUID** as `notification_id`.
+
+When the user **edits** an existing reminder (Edit Notification Details), only one notification fires. The duplicate only happens on **initial** setup.
+
+The app calls `scheduleDailyNotification` **once** per user action in both flows (first-time and edit). The duplicate is caused inside the plugin by the **prefetch worker** scheduling a second alarm via the legacy `DailyNotificationScheduler`.
+
+---
+
+## Evidence from Logcat
+
+Filter: `DNP-SCHEDULE`, `DailyNotificationWorker`, `DailyNotificationReceiver`.
+
+- **17:42:34** – Single call from app: plugin schedules the static reminder alarm (`scheduleId=daily_timesafari_reminder`, source=INITIAL_SETUP). One OS alarm is scheduled.
+- **17:45:00** – **Two** `RECEIVE_START` events:
+  - First: `display=5e373fd1-0f08-4e8f-b166-cfd46d694d82` (UUID).
+  - Second: `static_reminder id=daily_timesafari_reminder`.
+- Both run in parallel: Worker for UUID shows `DN|JIT_FRESH skip=true` and displays; Worker for `daily_timesafari_reminder` shows `DN|DISPLAY_STATIC_REMINDER` and displays. So two notifications are shown.
+
+Conclusion: two different PendingIntents fire at the same time: one with `notification_id` = UUID, one with `notification_id` = `daily_timesafari_reminder`.
+
+---
+
+## Root cause (plugin side)
+
+1. **ScheduleHelper.scheduleDailyNotification** (e.g. in `DailyNotificationPlugin.kt`):
+   - Cancels existing alarm for `scheduleId`.
+   - Schedules **one** alarm via **NotifyReceiver.scheduleExactNotification** with `reminderId = scheduleId`, `scheduleId = scheduleId`, `isStaticReminder = true` (INITIAL_SETUP). That alarm carries title/body in the intent and is the “correct” notification.
+   - Enqueues **DailyNotificationFetchWorker** (prefetch) to run 2 minutes before the same time.
+
+2. **DailyNotificationFetchWorker** runs ~2 minutes before the display time:
+   - Tries to fetch content (e.g. native fetcher). For a static-reminder-only app (no URL, no fetcher returning content), the fetch returns empty/null.
+   - Goes to **handleFailedFetch** → **useFallbackContent** → **getFallbackContent** → **createEmergencyFallbackContent(scheduledTime)**.
+   - **createEmergencyFallbackContent** builds a `NotificationContent()` (default constructor), which assigns a **random UUID** as `id`, and sets title “Daily Update” and body “🌅 Good morning! Ready to make today amazing?”.
+   - **useFallbackContent** then calls **scheduleNotificationIfNeeded(fallbackContent)**.
+
+3. **scheduleNotificationIfNeeded** uses the **legacy DailyNotificationScheduler** (AlarmManager) to schedule **another** alarm at the **same** `scheduledTime`, with `notification_id` = that UUID.
+
+So at fire time there are two alarms:
+
+- NotifyReceiver’s alarm: `notification_id` = `daily_timesafari_reminder`, `is_static_reminder` = true → correct user message.
+- DailyNotificationScheduler’s alarm: `notification_id` = UUID → fallback message.
+
+The prefetch path is intended for “fetch content then display” flows. For **static reminder** schedules, the display is already fully handled by the single NotifyReceiver alarm; the prefetch worker should not schedule a second alarm.
+
+---
+
+## Why edit doesn’t show the duplicate (in observed behavior)
+
+On edit, the app still calls the plugin once and the plugin again enqueues the prefetch worker. Possible reasons the duplicate is less obvious on edit:
+
+- Different timing (e.g. user sets a time further out, or doesn’t wait for the second notification).
+- Or the first-time run leaves the prefetch/legacy path in a state where the duplicate only appears on first setup.
+
+Regardless, the **correct fix** is to ensure that for static-reminder schedules the prefetch worker never schedules a second alarm.
+
+---
+
+## Recommended fix (in the plugin)
+
+**Option A (recommended): Do not enqueue prefetch for static reminder schedules**
+
+In **ScheduleHelper.scheduleDailyNotification** (or equivalent), when scheduling a **static reminder** (title/body from app, no URL, display already in the intent), **do not** enqueue `DailyNotificationFetchWorker` for that run. The prefetch is for “fetch content then show”; for static reminders there is nothing to fetch and the only alarm should be the one from NotifyReceiver.
+
+- No new inputData flags needed.
+- No change to DailyNotificationFetchWorker semantics for other flows.
+
+**Option B: Prefetch worker skips scheduling when display is already scheduled**
+
+- When enqueueing the prefetch work for a static-reminder schedule, pass an input flag (e.g. `display_already_scheduled` or `is_static_reminder_schedule` = true).
+- In **DailyNotificationFetchWorker**, in **useFallbackContent** (and anywhere else that calls **scheduleNotificationIfNeeded** for this work item), if that flag is set, **do not** call **scheduleNotificationIfNeeded**.
+- Ensures only the NotifyReceiver alarm fires for that time.
+
+Option A is simpler and matches the semantics: static reminder = one alarm, no prefetch.
+
+---
+
+## App-side behavior (no change required)
+
+- **First-time reminder:** Account view opens `PushNotificationPermission` without `skipSchedule`. User sets time/message and confirms. Dialog’s `turnOnNativeNotifications` calls `NotificationService.scheduleDailyNotification(...)` **once** and then the callback saves settings. No second schedule from the app.
+- **Edit reminder:** Account view opens the dialog with `skipSchedule: true`. Only the parent’s callback runs; it calls `cancelDailyNotification()` (on iOS) then `scheduleDailyNotification(...)` **once**. No double schedule from the app.
+
+So the duplicate is entirely due to the plugin’s prefetch worker scheduling an extra alarm via the legacy scheduler; fixing it in the plugin as above will resolve the issue.
+
+---
+
+## Files to consider in the plugin
+
+- **ScheduleHelper.scheduleDailyNotification** (e.g. in `DailyNotificationPlugin.kt`): where the single NotifyReceiver alarm and the prefetch work are enqueued. Either skip enqueueing prefetch for static reminder (Option A), or add inputData for “display already scheduled” (Option B).
+- **DailyNotificationFetchWorker**: `useFallbackContent` → `scheduleNotificationIfNeeded`; if using Option B, skip `scheduleNotificationIfNeeded` when the new flag is set.
+- **DailyNotificationScheduler** (legacy): used by `scheduleNotificationIfNeeded` to add the second (UUID) alarm; no change required if the worker simply stops calling it for static-reminder schedules.
+
+---
+
+## Verification
+
+After the fix:
+
+1. **First-time:** Turn on Reminder Notification, set message and time (e.g. 2–3 minutes ahead). Wait until the scheduled time. **Only one** notification should appear, with the user’s message.
+2. Logcat should show a single `RECEIVE_START` at that time (e.g. `static_reminder id=daily_timesafari_reminder`), and no second `display=<uuid>` for the same time.
+
+You can reuse the same Logcat filter as above to confirm a single receiver run per scheduled time.

doc/plugin-feedback-android-exact-alarm-settings.md

@@ -0,0 +1,74 @@
+# Plugin feedback: Android exact alarm — stop opening Settings automatically
+
+**Date:** 2026-03-09  
+**Target repo:** daily-notification-plugin  
+**Consuming app:** crowd-funder-for-time-pwa (TimeSafari)  
+**Platform:** Android
+
+## Summary
+
+When the consuming app calls `scheduleDailyNotification()` after the user has granted `POST_NOTIFICATIONS`, the plugin checks whether **exact alarms** can be scheduled (Android 12+). If not, it **opens the system Settings** (exact-alarm or app-details screen) and **rejects** the call. This is intrusive: the app prefers to schedule without forcing the user into Settings, and to inform the user about exact alarms in its own UI (e.g. a note in the success message).
+
+**Requested change:** Remove the automatic opening of Settings for exact alarm permission from `scheduleDailyNotification()`. Either:
+
+- **Option A (preferred):** Do not open Settings and do not reject when exact alarm is not granted. Proceed with scheduling (using inexact alarms if necessary when exact is unavailable), and let the consuming app handle any UX (e.g. optional hint to enable exact alarms).
+- **Option B:** Do not open Settings, but still reject with a clear error code/message when exact alarm is required and not granted, so the app can show its own message or deep-link to Settings if desired.
+
+---
+
+## Where this lives in the plugin
+
+**File:** `android/src/main/java/com/timesafari/dailynotification/DailyNotificationPlugin.kt`  
+**Method:** `scheduleDailyNotification(call: PluginCall)`  
+**Lines:** ~1057–1109 (exact line numbers may shift with edits)
+
+Current behavior:
+
+1. At the start of `scheduleDailyNotification()`, the plugin calls `canScheduleExactAlarms(context)`.
+2. If `false`:
+   - If Android S+ and `canRequestExactAlarmPermission(context)` is true: it builds `Settings.ACTION_REQUEST_SCHEDULE_EXACT_ALARM`, calls `context.startActivity(intent)`, logs **"Exact alarm permission required. Opened Settings for user to grant permission."** (tag `DNP-PLUGIN`), and rejects with `EXACT_ALARM_PERMISSION_REQUIRED`.
+   - Else: it opens app details (`Settings.ACTION_APPLICATION_DETAILS_SETTINGS`), logs **"Exact alarm permission denied. Directing user to app settings."**, and rejects with `PERMISSION_DENIED`.
+3. Only if exact alarms are allowed does the plugin continue to schedule.
+
+So the **exact alarms** feature here is: **gate scheduling on exact alarm permission and, when not granted, open Settings and reject.**
+
+---
+
+## Evidence from consumer app (logcat)
+
+Filter: `DNP-PLUGIN`, `DNP-SCHEDULE`, `DailyNotificationWorker`, `DailyNotificationReceiver`.
+
+Typical sequence when user enables daily notification:
+
+1. `DNP-PLUGIN: Created pending permission request: ... type=POST_NOTIFICATIONS`
+2. User grants notification permission.
+3. `DNP-PLUGIN: Resolving pending POST_NOTIFICATIONS request on resume: granted=true`
+4. App calls `scheduleDailyNotification(...)`.
+5. `DNP-PLUGIN: Exact alarm permission required. Opened Settings for user to grant permission.`
+
+The consumer app does **not** call any plugin API to “request exact alarm” or “open exact alarm settings”; it only calls `requestPermissions()` (POST_NOTIFICATIONS) and then `scheduleDailyNotification()`. The plugin’s own guard in `scheduleDailyNotification()` is what opens Settings.
+
+---
+
+## Consumer app context
+
+- **Permission flow:** The app requests `POST_NOTIFICATIONS` via the plugin’s `requestPermissions()`, then calls `scheduleDailyNotification()`. It does not request exact alarm permission itself.
+- **UX:** The app already shows an optional note when exact alarm is not granted (e.g. “If notifications don’t appear, enable ‘Exact alarms’ in Android Settings → Apps → TimeSafari → App settings”). It does not want the plugin to open Settings automatically.
+- **Manifest:** The app declares `SCHEDULE_EXACT_ALARM` in its AndroidManifest; the issue is only the **automatic redirect to Settings** and the **reject** when exact alarm is not yet granted.
+
+---
+
+## Suggested plugin changes
+
+1. **In `scheduleDailyNotification()`:** Remove the block that opens Settings and rejects when `!canScheduleExactAlarms(context)` (the block ~1057–1109). Do **not** call `startActivity` for `ACTION_REQUEST_SCHEDULE_EXACT_ALARM` or `ACTION_APPLICATION_DETAILS_SETTINGS` from this method.
+2. **Scheduling when exact alarm is not granted:** Prefer Option A: continue and schedule even when exact alarms are not allowed (e.g. use inexact/alarm manager APIs that don’t require exact alarm, or document that timing may be approximate). If the plugin must reject when exact is required, use Option B: reject with a specific error code/message and no `startActivity`.
+3. **Leave other APIs unchanged:** Methods such as `openExactAlarmSettings()` or `requestExactAlarmPermission()` can remain for apps that explicitly want to send the user to Settings; the change is only to stop doing it automatically inside `scheduleDailyNotification()`.
+
+---
+
+## Relation to existing docs
+
+- **Plugin:** `doc/daily-notification-plugin-android-receiver-issue.md` and `doc/daily-notification-plugin-checklist.md` describe use of `SCHEDULE_EXACT_ALARM` (not `USE_EXACT_ALARM`). This feedback does not change that; it only asks to stop auto-opening Settings in `scheduleDailyNotification()`.
+- **Consumer app:** `doc/notification-permissions-and-rollovers.md` describes the permission flow; `doc/NOTIFICATION_TROUBLESHOOTING.md` mentions exact alarms for user guidance.
+
+Use this document when implementing the change in the **daily-notification-plugin** repo (e.g. with Cursor). After changing the plugin, update the consuming app’s dependency (e.g. `npm update @timesafari/daily-notification-plugin`), then `npx cap sync android` and rebuild.

doc/plugin-feedback-android-parseUserNotificationConfig-optional-fields.md

@@ -0,0 +1,99 @@
+# Plugin feedback: Android `parseUserNotificationConfig` — optional fields vs `getBoolean` / `getString`
+
+**Date:** 2026-03-20 21:11 PST  
+**Target repo:** `@timesafari/daily-notification-plugin` (daily-notification-plugin)  
+**Consuming app:** crowd-funder-for-time-pwa (TimeSafari)  
+**Platform:** Android (Kotlin)  
+**Related:** Same class of issue as [plugin-feedback-android-scheduleDualNotification-contentFetch-json.md](./plugin-feedback-android-scheduleDualNotification-contentFetch-json.md) (`contentFetch` / `parseContentFetchConfig`).
+
+---
+
+## Summary
+
+`DailyNotificationPlugin.parseUserNotificationConfig()` uses **`JSObject` / `JSONObject` strict getters** for fields that the published TypeScript **`UserNotificationConfig`** marks as **optional** (`sound?`, `vibration?`, `priority?`, `title?`, `body?`). If a key is omitted, Android throws **`JSONException`** (e.g. *No value for vibration*), and `scheduleDualNotification` fails before scheduling.
+
+**Recommended direction (plugin):** Align Kotlin parsing with `dist/esm/definitions.d.ts` by using **optional reads + defaults**, consistent with the fix already applied for `parseContentFetchConfig` (e.g. `optIntOrNull`, or Capacitor/JSON equivalents for booleans and strings).
+
+**Recommended direction (app / already done in TimeSafari):** Send explicit `sound`, `vibration`, and `priority` (and title/body) in `buildDualScheduleConfig()` so **older plugin builds** that still use strict getters continue to work.
+
+**Does it make sense to change both sides?** **Yes** — same reasoning as for `contentFetch`: the plugin should match its public contract; the app can stay explicit for compatibility and clarity.
+
+---
+
+## Symptoms (consuming app)
+
+- In-app toast: *“Could not schedule New Activity notification. Please try again.”* (generic catch after `scheduleDualNotification` rejects.)
+- Logcat:
+
+```text
+E DNP-PLUGIN: Schedule dual notification error
+E DNP-PLUGIN: org.json.JSONException: No value for vibration
+E DNP-PLUGIN:   at org.json.JSONObject.getBoolean(JSONObject.java:419)
+E DNP-PLUGIN:   at org.timesafari.dailynotification.DailyNotificationPlugin.parseUserNotificationConfig(DailyNotificationPlugin.kt:2428)
+E DNP-PLUGIN:   at org.timesafari.dailynotification.DailyNotificationPlugin.scheduleDualNotification(DailyNotificationPlugin.kt:1392)
+```
+
+(First failure observed after `contentFetch` timeouts were fixed was **`vibration`**; the same pattern can affect **`sound`** or **`priority`** if those keys are omitted.)
+
+---
+
+## Root cause
+
+### Published TypeScript contract (`UserNotificationConfig`)
+
+From `definitions.d.ts` (representative):
+
+- `title?`, `body?`, `sound?`, `vibration?`, `priority?` — all optional.
+
+### Current Android implementation (strict)
+
+In `DailyNotificationPlugin.kt`, `parseUserNotificationConfig` (line numbers approximate; search for `parseUserNotificationConfig`):
+
+```kotlin
+private fun parseUserNotificationConfig(configJson: JSObject): UserNotificationConfig {
+    return UserNotificationConfig(
+        enabled = configJson.getBoolean("enabled") ?: true,
+        schedule = configJson.getString("schedule") ?: "0 9 * * *",
+        title = configJson.getString("title"),
+        body = configJson.getString("body"),
+        sound = configJson.getBoolean("sound"),
+        vibration = configJson.getBoolean("vibration"),
+        priority = configJson.getString("priority")
+    )
+}
+```
+
+- **`getBoolean("vibration")`** (and **`getBoolean("sound")`**) throw if the key is **missing** — optional in TS, required at runtime on Android.
+- **`getString("title")`**, **`getString("body")`**, **`getString("priority")`** likewise throw if missing (depending on `JSObject` / `JSONObject` behavior for absent keys).
+
+So minimal or TS-faithful payloads omit `vibration` → immediate `JSONException`.
+
+---
+
+## Plugin-side recommendations
+
+1. **Treat `UserNotificationConfig` optional fields as optional on Android**, mirroring `definitions.d.ts`:
+   - **`vibration`:** e.g. `optBoolean` / nullable + default **`true`** (or `false` if that matches product default — document the default).
+   - **`sound`:** same pattern; default **`true`** is typical for notifications.
+   - **`priority`:** optional string with default **`"normal"`** (or map from TS union).
+   - **`title` / `body`:** if TS allows omission, use optional reads + defaults consistent with dual-schedule UX (or reject with a clear `call.reject` message instead of a raw `JSONException`).
+
+2. **Reuse the same helper style** as `parseContentFetchConfig` after the timeout fix (`optIntOrNull`, etc.) so one codebase convention applies to all dual-schedule JSON parsing.
+
+3. **Tests:** Unit or integration test that calls `scheduleDualNotification` with a **minimal** `userNotification` object (only what TS strictly requires, if anything) and asserts scheduling succeeds on Android.
+
+4. **iOS parity:** If iOS already accepts omitted `vibration` / `sound`, Android should match; if not, align both platforms to the same `UserNotificationConfig` rules.
+
+---
+
+## App-side note (TimeSafari)
+
+`src/services/notifications/dualScheduleConfig.ts` — `buildDualScheduleConfig()` now includes **`vibration: true`** (with `sound: true`) so current native code paths succeed. Keeping this explicit is still recommended even after the plugin is fixed.
+
+---
+
+## References
+
+- Plugin: `android/.../DailyNotificationPlugin.kt` — `parseUserNotificationConfig`
+- TS: `dist/esm/definitions.d.ts` — `UserNotificationConfig`, `DualScheduleConfiguration`
+- App: `src/services/notifications/dualScheduleConfig.ts` — `buildDualScheduleConfig`

doc/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=org.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).

doc/plugin-feedback-android-rollover-after-reboot.md

@@ -0,0 +1,169 @@
+# Plugin feedback: Android rollover notification may not fire after device restart (app not launched)
+
+**Date:** 2026-02-24 18:24  
+**Target repo:** daily-notification-plugin  
+**Consuming app:** crowd-funder-for-time-pwa (TimeSafari)  
+**Platform:** Android
+
+## Summary
+
+Boot recovery can **skip** rescheduling after a device restart (it sees an “existing PendingIntent” and skips). Whether the next notification **fails to fire** as a result depends on **whether the alarm survived the reboot**: Android’s documented behavior is that AlarmManager alarms do **not** persist across reboot, but on some devices/builds they **do** (implementation-dependent). So: **(1)** *Set schedule → restart shortly after → wait for first notification:* On at least one device, the initial notification **fired** even though boot recovery skipped (alarm had survived reboot). On devices where alarms are cleared, that initial notification would not fire. **(2)** *Set schedule → first notification fires → restart → wait for rollover:* Same logic—if the rollover alarm is cleared and boot recovery skips, the rollover won’t fire. The **fix** (always reschedule in the boot path, skip idempotence there) remains correct: it makes behavior reliable regardless of alarm persistence. See [Scenario 1: observed behavior](#scenario-1-observed-behavior) and [Two distinct scenarios](#two-distinct-scenarios-same-bug-different-victim-notification).
+
+---
+
+## Definitions
+
+- **Rollover (in this doc):** The next occurrence of the daily notification. Concretely: when today’s alarm fires, the plugin runs `scheduleNextNotification()` and sets an alarm for the same time the next day. That “next day” alarm is the rollover.
+- **Boot recovery:** When the device boots, the plugin’s `BootReceiver` receives `BOOT_COMPLETED` (and/or `LOCKED_BOOT_COMPLETED`) and calls into the plugin to reschedule alarms from persisted schedule data.
+
+---
+
+## Android behavior: alarm persistence across reboot is implementation-dependent
+
+- **Documented behavior:** AlarmManager alarms are **not** guaranteed to persist across a full device reboot; the platform may clear them when the device is turned off and rebooted. Apps are expected to reschedule on `BOOT_COMPLETED`.
+- **Observed behavior:** On some devices or Android builds, alarms (e.g. from `setAlarmClock()`) **do** survive reboot. So whether the next notification fires after a reboot when boot recovery **skips** depends on the device: if the alarm survived, it can still fire; if it was cleared, it will not fire until the app is opened and reschedules.
+
+So the **reliable** way to guarantee the next notification fires after reboot is for boot recovery to **always** call `AlarmManager.setAlarmClock()` (or equivalent) again, and not to skip based on “existing PendingIntent.”
+
+---
+
+## Scenario 1: observed behavior (schedule → restart → wait for first notification)
+
+Logcat from a real test (schedule set, device restarted shortly after, app not launched):
+
+**Before reboot (initial schedule):**
+```
+02-24 18:56:36 ... Scheduling next daily alarm: id=daily_timesafari_reminder, nextRun=2026-02-24 19:00:00, source=INITIAL_SETUP
+02-24 18:56:36 ... Scheduling OS alarm: ... requestCode=53438, scheduleId=daily_timesafari_reminder ...
+```
+
+**After reboot (boot recovery):**
+```
+02-24 18:56:48 ... Skipping duplicate schedule: id=daily_timesafari_reminder, nextRun=2026-02-24 19:00:00, source=BOOT_RECOVERY
+02-24 18:56:48 ... Existing PendingIntent found for requestCode=53438 - alarm already scheduled
+```
+
+**At scheduled time (19:00:00):**
+```
+02-24 19:00:00 ... DailyNotificationReceiver: DN|RECEIVE_START action=org.timesafari.daily.NOTIFICATION
+02-24 19:00:00 ... DailyNotificationWorker: DN|DISPLAY_NOTIF_OK ...
+02-24 19:00:01 ... DN|ROLLOVER next=1772017200000 scheduleId=daily_rollover_1771930801007 ...
+```
+
+So in this run, **boot recovery skipped** (duplicate + existing PendingIntent), but the **initial notification still fired** at 19:00. That implies the alarm **survived the reboot** on this device. On devices where alarms are cleared on reboot, the same skip would mean the initial notification would **not** fire. Conclusion: scenario 1 failure is **device-dependent**; the fix (always reschedule on boot) removes that dependence.
+
+---
+
+## Two distinct scenarios (same bug, different “victim” notification)
+
+The same boot-recovery skip can affect either the **initial** notification or the **rollover** notification, depending on when the user restarts and whether the alarm survived reboot:
+
+| # | User sequence | What is lost on reboot (if alarms cleared) | What fails if boot recovery skips **and** alarm was cleared |
+|---|----------------|--------------------------------------------|--------------------------------------------------------------|
+| **1** | Set schedule → **restart shortly after** → wait for first notification | Alarm for the **first** occurrence (e.g. 19:00 same day). | **Initial** notification never fires. *(Observed on one device: alarm survived, so notification fired despite skip.)* |
+| **2** | Set schedule → **first notification fires** (rollover set) → restart → wait for next day | Alarm for the **rollover** (next day, e.g. `daily_rollover_*`). | **Rollover** notification never fires. |
+
+- **Scenario 1:** User configures a daily reminder, then reboots before the first fire. If the alarm is cleared on reboot and boot recovery skips, the first notification never fires. If the alarm survives (as in the logcat above), it can still fire.
+- **Scenario 2:** After the first fire, the plugin creates a **new** schedule (e.g. `daily_rollover_1771930801007`) and sets an alarm for the next day. If the device reboots, that rollover alarm may or may not persist. If it is cleared and boot recovery only reschedules the primary `daily_timesafari_reminder` (and skips), or does not reschedule the rollover, the rollover notification may not fire.
+
+In both cases the **fix** is the same: in the boot recovery path, skip the “existing PendingIntent” idempotence check so the plugin always re-registers the alarm(s) after reboot, making behavior reliable regardless of whether the OEM clears alarms.
+
+---
+
+## Daily notification flow (relevant parts)
+
+1. **Initial schedule (app):** User sets a daily time (e.g. 09:00). App calls `scheduleDailyNotification({ time, title, body, id })`. Plugin stores schedule and sets an alarm for the next occurrence (e.g. tomorrow 09:00 if today 09:00 has passed).
+2. **When the alarm fires:** `DailyNotificationReceiver` runs, shows the notification, and the plugin calls `scheduleNextNotification()` (rollover), which schedules the **next day** at the same time via `NotifyReceiver.scheduleExactNotification(..., ScheduleSource.ROLLOVER_ON_FIRE)`.
+3. **After reboot:** No alarm exists. `BootReceiver` runs (without the app being launched). It should load the schedule from the DB, compute the next run time, and call the same scheduling path to re-register the alarm with AlarmManager.
+
+If step 3 does **not** actually register an alarm (because boot recovery skips), and the device **cleared** alarms on reboot, the next notification will not fire until the user opens the app. If the alarm survived reboot (device-dependent), it can still fire despite the skip.
+
+---
+
+## Evidence that boot recovery can skip rescheduling
+
+Boot recovery repeatedly logs that it is **skipping** reschedule (see also `doc/plugin-feedback-android-post-reboot-fallback-text.md` and the Scenario 1 logcat above):
+
+```
+Skipping duplicate schedule: id=daily_timesafari_reminder, nextRun=..., source=BOOT_RECOVERY
+Existing PendingIntent found for requestCode=53438 - alarm already scheduled
+```
+
+So boot recovery **does not** call `AlarmManager.setAlarmClock()` in those runs; it relies on “existing PendingIntent” and skips. The “existing PendingIntent” comes from the plugin’s idempotence check (e.g. `PendingIntent.getBroadcast(..., FLAG_NO_CREATE)`), which can still return non-null after reboot (e.g. cached by package/requestCode/Intent identity). That does **not** prove an alarm is still registered: on some devices alarms are cleared on reboot, so after a skip there would be no alarm and the next notification would not fire. On other devices (as in the Scenario 1 test above) the alarm can survive, so the notification still fires despite the skip. So the **risk** of a missed notification after reboot is **device-dependent**; the fix (always reschedule on boot) removes that dependence.
+
+---
+
+## Root cause (plugin side)
+
+1. **Idempotence in `scheduleExactNotification`:** Before scheduling, the plugin checks for an “existing” PendingIntent (and possibly DB state). If found, it skips scheduling to avoid duplicates.
+2. **Boot recovery uses the same path:** When `BootReceiver` runs, it calls into the same scheduling logic with `source = BOOT_RECOVERY` and **without** skipping the idempotence check (default `skipPendingIntentIdempotence = false` or equivalent).
+3. **After reboot:** The “existing PendingIntent” check can still succeed (e.g. cached), so boot recovery skips and does not call `AlarmManager.setAlarmClock()`. On devices where alarms are cleared on reboot, no alarm is re-registered and the next notification will not fire until the app is opened. On devices where alarms survive (as in the Scenario 1 test), the notification can still fire.
+
+So the **reliable** behavior is: **boot recovery should always re-register the alarm after reboot** (e.g. by skipping the PendingIntent idempotence check in the boot path), so that the app does not depend on implementation-dependent alarm persistence.
+
+---
+
+## Recommended fix (in the plugin)
+
+**Idea:** In the **boot recovery** path only, force a real reschedule and avoid the “existing PendingIntent” skip. After reboot there is no alarm; treating it as “already scheduled” is wrong.
+
+**Concrete options:**
+
+1. **Skip PendingIntent idempotence when source is BOOT_RECOVERY**  
+   When calling `NotifyReceiver.scheduleExactNotification` from boot recovery (e.g. from `ReactivationManager.rescheduleAlarmForBoot` or from `BootReceiver`), pass a flag so that the “existing PendingIntent” check is **skipped** (e.g. `skipPendingIntentIdempotence = true` or a dedicated `forceRescheduleAfterBoot = true`).  
+   That way, boot recovery always calls `AlarmManager.setAlarmClock()` (or equivalent) and re-registers the alarm, even if `PendingIntent.getBroadcast(..., FLAG_NO_CREATE)` still returns non-null from a pre-reboot cache.
+
+2. **Separate boot path that never skips**  
+   Alternatively, implement a dedicated “reschedule for boot” path that does not go through the same idempotence branch as user/manual reschedule. That path should always compute the next run time from the persisted schedule and call AlarmManager to set the alarm, without checking for an “existing” PendingIntent.
+
+3. **Do not rely on PendingIntent existence as “alarm is set” after reboot**  
+   If the plugin currently infers “alarm already scheduled” from “PendingIntent exists,” that inference is wrong after reboot. Either skip that check when the call is from boot recovery, or after reboot always re-register and only use idempotence for in-process duplicate prevention (e.g. when the user taps “Save” twice in a short time).
+
+**Recommendation:** Option 1 is the smallest change: in the boot recovery call site(s), pass `skipPendingIntentIdempotence = true` (or the equivalent flag) so that scheduling is not skipped and the alarm is always re-registered after reboot.
+
+**Will this cause duplicate alarms when the alarm survived reboot?** No. When boot recovery calls `setAlarmClock()` (or equivalent), it uses the same `scheduleId` and thus the same `requestCode` and same Intent (and hence the same logical PendingIntent) as the existing alarm. On Android, setting an alarm with a PendingIntent that matches one already registered **replaces** that alarm; it does not add a second one. So you end up with one alarm either way—either the one that survived reboot (now effectively “confirmed” by the second call) or the one just set if the previous one had been cleared. No duplicate notifications.
+
+---
+
+## Verification after fix
+
+1. Schedule a daily notification for a time a few minutes in the future (or use a test build that allows short intervals).
+2. Let it fire once so the plugin schedules the rollover (next day).
+3. **Restart the device** and do **not** open the app.
+4. Wait until the next scheduled time (next day, or the same day if testing with a second alarm a few minutes later).
+5. Confirm that the notification **does** fire.
+6. In logcat after reboot, you should see boot recovery **not** logging “Skipping duplicate schedule” / “Existing PendingIntent found” for this schedule, and you should see the alarm being set (e.g. “Scheduling OS alarm” or similar).
+
+---
+
+## App-side behavior
+
+No change is required in the consuming app for this bug. The app does not reschedule after reboot; that is the plugin’s responsibility via `BootReceiver` and boot recovery. Fixing the plugin so that boot recovery always re-registers the alarm (and does not skip due to PendingIntent idempotence) is sufficient.
+
+---
+
+## Short summary for plugin maintainers
+
+**Issue:** After an Android device restart, boot recovery skips rescheduling when it finds an “existing PendingIntent.” On devices where AlarmManager clears alarms on reboot, that skip means the next daily notification (initial or rollover) will not fire until the app is opened. On devices where alarms survive reboot, the notification can still fire (as observed in a Scenario 1 test). So the failure is device-dependent; the plugin should not rely on alarm persistence.
+
+**Fix:** In the boot recovery path, when calling `scheduleExactNotification` (or the equivalent), pass a flag to **skip** the “existing PendingIntent” idempotence check (e.g. `skipPendingIntentIdempotence = true`), so that the alarm is always re-registered after reboot and behavior is reliable on all devices.
+
+---
+
+## For Cursor (plugin repo) — actionable fix
+
+Use this section when applying the fix in the **daily-notification-plugin** repo (e.g. with Cursor).
+
+**Goal:** When rescheduling after boot, **always** register the alarm with AlarmManager. Do not skip because “existing PendingIntent” was found (that check can be true after reboot even though the alarm was cleared).
+
+**Change:** At every call site where the plugin invokes `NotifyReceiver.scheduleExactNotification` (or the Kotlin equivalent) for **boot recovery** (i.e. when the schedule source is `BOOT_RECOVERY` or the call is from `BootReceiver` / `ReactivationManager.rescheduleAlarmForBoot`), pass **`skipPendingIntentIdempotence = true`** so that the idempotence check is skipped and the alarm is always set.
+
+**Files to look at (plugin Android code):**
+
+- **ReactivationManager.kt** — Find `rescheduleAlarmForBoot` (or similar). It likely calls `NotifyReceiver.scheduleExactNotification(...)`. Ensure that call passes `skipPendingIntentIdempotence = true` (and `source = ScheduleSource.BOOT_RECOVERY` if applicable).
+- **BootReceiver.kt** — If it calls `scheduleExactNotification` or invokes ReactivationManager for boot, ensure that path passes `skipPendingIntentIdempotence = true`.
+
+**Method signature (for reference):**  
+`NotifyReceiver.scheduleExactNotification(context, triggerAtMillis, config, isStaticReminder, reminderId, scheduleId, source, skipPendingIntentIdempotence)`. The last parameter is what must be `true` for boot recovery.
+
+**Verification:** After the change, trigger a device reboot (app not launched), then inspect logcat. You should **not** see “Skipping duplicate schedule” / “Existing PendingIntent found” for `source=BOOT_RECOVERY`; you should see “Scheduling OS alarm” (or equivalent) so the alarm is re-registered.

doc/plugin-feedback-android-rollover-double-fire-and-user-content.md

@@ -0,0 +1,133 @@
+# Plugin feedback: Android rollover — two notifications, neither with user content
+
+**Date:** 2026-02-26 18:03  
+**Target repo:** daily-notification-plugin  
+**Consuming app:** crowd-funder-for-time-pwa (TimeSafari)  
+**Platform:** Android
+
+## Summary
+
+When waiting for the rollover notification at the scheduled time:
+
+1. **Two different notifications fired** — one ~3 minutes before the schedule (21:53), one on the dot (21:56). They showed different text (neither the user’s).
+2. **Neither notification contained the user-set content** — both used Room/fallback content (`DN|DISPLAY_USE_ROOM_CONTENT`, `skip JIT`), not the static reminder path.
+3. **Main-thread DB access** — receiver logged `db_fallback_failed` with "Cannot access database on the main thread".
+
+Fixes are required in the **daily-notification-plugin** (and optionally one app-side improvement). This doc gives the diagnosis and recommended changes.
+
+---
+
+## Evidence from Logcat
+
+Filter: `DNP-SCHEDULE`, `DailyNotificationWorker`, `DailyNotificationReceiver`.
+
+### First notification (21:53 — 3 minutes before schedule)
+
+- `display=68ea176c-c9c0-4ef3-bd0c-61b67c8a3982` (UUID-style id)
+- `DN|WORK_ENQUEUE db_fallback_failed` — DB access on main thread when building work input
+- `DN|DISPLAY_USE_ROOM_CONTENT id=68ea176c-... (skip JIT)` — content from Room, not static reminder
+- After display: `DN|ROLLOVER next=1772113980000 scheduleId=daily_rollover_1772027581028 static=false`
+- New schedule created for **next day at 21:53**
+
+### Second notification (21:56 — on the dot)
+
+- `display=notify_1772027760000` (time-based id; 1772027760000 = 2026-02-25 21:56)
+- `DN|DISPLAY_USE_ROOM_CONTENT id=notify_1772027760000 (skip JIT)` — again Room content, not user text
+- After display: `DN|ROLLOVER next=1772114160000 scheduleId=daily_rollover_1772027760210 static=false`
+- New schedule created for **next day at 21:56**
+
+So the user’s chosen time was **21:56**. The 21:53 alarm was a **separate** schedule (from a previous rollover or prefetch that used 21:53).
+
+---
+
+## Root causes
+
+### 1. Two alarms for two different times
+
+- **21:53** — Alarm with `notification_id` = UUID (`68ea176c-...`). This matches the “prefetch fallback” or “legacy scheduler” path: when prefetch fails or a rollover is created with a time that doesn’t match the **current** user schedule, the plugin can schedule an alarm with a **random UUID** and default content (see `doc/plugin-feedback-android-duplicate-reminder-notification.md`). So at some point an alarm was set for 21:53 (e.g. a previous day’s rollover for 21:53, or a prefetch that scheduled fallback for 21:53).
+- **21:56** — Alarm with `notification_id` = `notify_1772027760000`. This is the “real” schedule (user chose 21:56). The id is time-based, not the app’s static reminder id `daily_timesafari_reminder`.
+
+So there are **two logical schedules** active: one for 21:53 (stale or from prefetch) and one for 21:56. When the user reschedules to 21:56, the plugin must **cancel all previous alarms** for this reminder, including any rollover or prefetch-created alarm for 21:53 (and any other `daily_rollover_*` or UUID-based alarms that belong to the same logical reminder). Otherwise both fire and the user sees two notifications with different text.
+
+**Plugin fix:** When the app calls `scheduleDailyNotification` with a given `scheduleId` (e.g. `daily_timesafari_reminder`):
+
+- Cancel **every** alarm that belongs to this reminder: the main schedule, all rollover schedules (`daily_rollover_*` that map to this reminder), and any prefetch-scheduled display alarm (UUID) that was created for this reminder.
+- For static reminders, **do not** enqueue prefetch work that will create a second alarm (see duplicate-reminder doc). If prefetch is already disabled for static reminders, then the 21:53 UUID alarm likely came from an **old rollover** (previous day’s fire at 21:53). So rollover must either (a) use a **stable** schedule id that gets cancelled when the user reschedules (e.g. same `scheduleId` or a known prefix), or (b) the plugin must cancel by “logical reminder” (e.g. all schedules whose next run is for this reminder) when the user sets a new time.
+
+### 2. User content not used (USE_ROOM_CONTENT, skip JIT)
+
+- There is **no** `DN|DISPLAY_STATIC_REMINDER` in the logs. So the worker did **not** receive (or use) static reminder title/body.
+- Both runs show `DN|DISPLAY_USE_ROOM_CONTENT ... (skip JIT)`: content is loaded from Room by `notification_id` and JIT/fetcher is skipped. So the worker is using **Room content keyed by the run’s notification_id** (UUID or `notify_*`), not by the app’s reminder id `daily_timesafari_reminder`.
+
+The app stores title/body when it calls `scheduleDailyNotification`; the plugin should store that in a way that survives rollover and is used when the alarm fires. If the **Intent** carries `notification_id` = `notify_1772027760000` (or a UUID) and no title/body (e.g. after reboot or when the rollover PendingIntent doesn’t carry extras), the worker looks up Room by that id. The entity for `daily_timesafari_reminder` (user title/body) is a **different** key, so the worker either finds nothing or finds fallback content written by prefetch for that run.
+
+**Plugin fix (see also `doc/plugin-feedback-android-post-reboot-fallback-text.md`):**
+
+- **Receiver:** When the Intent has `notification_id` but **missing** title/body (or `is_static_reminder` is false), resolve the “logical” reminder id (e.g. from `schedule_id` extra, or from a mapping: rollover schedule id → `daily_timesafari_reminder`, or from NotificationContentEntity by schedule id). Load title/body from DB (Schedule or NotificationContentEntity) for that reminder and pass them into the Worker with `is_static_reminder = true`.
+- **Worker:** When displaying, if input has static reminder title/body, use them and do not overwrite with Room content keyed by run-specific id. When loading from Room by `notification_id`, if the run’s id is a rollover or time-based id, also look up the **canonical** reminder id (e.g. `daily_timesafari_reminder`) and prefer that entity’s title/body if present, so rollover displays user text.
+- **Rollover scheduling:** When scheduling the next day’s alarm (ROLLOVER_ON_FIRE), pass title/body (or a stable reminder id) so the next fire’s Intent or Worker input can resolve user content. Optionally store title/body on the Schedule entity so boot recovery and rollover can always load them.
+
+### 3. Main-thread database access
+
+- `DN|WORK_ENQUEUE db_fallback_failed id=68ea176c-... err=Cannot access database on the main thread...`
+
+The receiver is trying to read from the DB (e.g. to fill in title/body when extras are missing) on the main thread. Room disallows this.
+
+**Plugin fix:** In `DailyNotificationReceiver.enqueueNotificationWork`, do **not** call Room/DB on the main thread. Either (a) enqueue the work with the Intent extras only and let the **Worker** load title/body from DB on a background thread, or (b) use a coroutine/background executor in the receiver to load from DB and then enqueue work with the result. Prefer (a) unless the receiver must decide work parameters synchronously.
+
+---
+
+## Relation to existing docs
+
+- **Duplicate reminder** (`doc/plugin-feedback-android-duplicate-reminder-notification.md`): Prefetch should not schedule a second alarm for static reminders. That would prevent a **second** alarm at the **same** time. Here we also have a **second** alarm at a **different** time (21:53 vs 21:56), so in addition the plugin must cancel **all** alarms for the reminder when the user reschedules (including old rollover times).
+- **Post-reboot fallback text** (`doc/plugin-feedback-android-post-reboot-fallback-text.md`): Same idea — resolve title/body from DB when Intent lacks them; use canonical reminder id / NotificationContentEntity so rollover and post-reboot show user text.
+- **Rollover after reboot** (`doc/plugin-feedback-android-rollover-after-reboot.md`): Boot recovery should always re-register alarms. Not the direct cause of “two notifications at two times” but relevant for consistency.
+
+---
+
+## App-side behavior
+
+- The app calls `scheduleDailyNotification` once with `id: "daily_timesafari_reminder"`, `time`, `title`, and `body`. It does not manage rollover or prefetch; that is all plugin-side.
+- **Optional app-side mitigation:** When the user **changes** the reminder time (or turns the reminder off then on with a new time), the app could call a plugin API to “cancel all daily notification alarms for this app” before calling `scheduleDailyNotification` again, if the plugin exposes such a method. That would reduce the chance of leftover 21:53 alarms. The **correct** fix is still plugin-side: when scheduling for `daily_timesafari_reminder`, cancel every existing alarm that belongs to that reminder (including rollover and prefetch-created ones).
+
+---
+
+## Verification after plugin fixes
+
+1. Set a daily reminder for 21:56 with **distinct** custom title/body.
+2. Wait for the notification (or set it 1–2 minutes ahead). **One** notification at 21:56 with your custom text.
+3. Let it fire once so rollover is scheduled for next day 21:56. Optionally reboot; next day **one** notification at 21:56 with your custom text.
+4. Change time to 21:58 and save. Wait until 21:56 and 21:58: **no** notification at 21:56; **one** at 21:58 with your text.
+5. Logcat: no `db_fallback_failed`; for the display that shows user text, either `DN|DISPLAY_STATIC_REMINDER` or Room lookup by canonical id with user title/body.
+
+---
+
+## Short summary for plugin maintainers
+
+- **Two notifications:** Two different alarms were active (21:53 and 21:56). When the user sets 21:56, the plugin must cancel **all** alarms for this reminder (main + rollover + any prefetch-created), not only the “primary” schedule. For static reminders, prefetch must not schedule a second alarm (see duplicate-reminder doc).
+- **Wrong content:** Worker used Room content keyed by run id (UUID / `notify_*`), not the app’s reminder id. Resolve canonical reminder id and load title/body from DB in receiver or worker; pass static reminder data into Worker when Intent lacks it; when scheduling rollover, preserve title/body (or stable reminder id) so the next fire shows user text.
+- **Main-thread DB:** Receiver must not access Room on the main thread; move DB read to Worker or background in receiver.
+
+---
+
+## For Cursor (plugin repo) — actionable handoff
+
+Use this section when applying fixes in the **daily-notification-plugin** repo (e.g. with Cursor). You can paste or @-mention this doc as context.
+
+**Goal:** (1) Only one notification at the user’s chosen time, with user-set title/body. (2) No main-thread DB access in the receiver.
+
+**Changes:**
+
+1. **Cancel all alarms for the reminder when the app reschedules**  
+   When `scheduleDailyNotification` is called with a given `scheduleId` (e.g. `daily_timesafari_reminder`), cancel every alarm that belongs to this reminder: the main schedule, all rollover schedules (`daily_rollover_*` that correspond to this reminder), and any prefetch-created display alarm (UUID). That prevents a second notification at a stale time (e.g. 21:53 when the user set 21:56).
+
+2. **Static reminder: no second alarm from prefetch**  
+   For static reminders, do not enqueue prefetch work that schedules a second alarm (see duplicate-reminder doc). Prefetch is for “fetch content then display”; for static reminders the single NotifyReceiver alarm is enough.
+
+3. **Use user title/body when displaying (receiver + worker)**  
+   When the Intent has `notification_id` but missing title/body (or `is_static_reminder` false), resolve the canonical reminder id (e.g. from `schedule_id`, or rollover id → reminder id, or NotificationContentEntity by schedule). Load title/body from DB and pass into Worker with `is_static_reminder = true`. In the worker, when displaying rollover or time-based runs, prefer content for the canonical reminder id so user text is shown. When scheduling rollover (ROLLOVER_ON_FIRE), pass or persist title/body (or stable reminder id) so the next day’s fire can resolve them.
+
+4. **No DB on main thread in receiver**  
+   In `DailyNotificationReceiver.enqueueNotificationWork`, do not call Room/DB on the main thread. Either enqueue work with Intent extras only and let the Worker load title/body on a background thread, or use a coroutine/background executor in the receiver before enqueueing.
+
+**Files to look at (plugin Android):** ScheduleHelper / NotifyReceiver (cancel all alarms for reminder; schedule with correct id); DailyNotificationReceiver (no main-thread DB; optionally pass static reminder data from DB on background thread); DailyNotificationWorker (use static reminder input; resolve canonical id from Room when run id is rollover/notify_*); DailyNotificationFetchWorker (do not schedule second alarm for static reminders).

doc/plugin-feedback-android-rollover-interval-bugs.md

@@ -0,0 +1,104 @@
+# Plugin feedback: Android rollover interval – two bugs (logcat evidence)
+
+**Date:** 2026-03-04  
+**Target:** daily-notification-plugin (Android)  
+**Feature:** `rolloverIntervalMinutes` (e.g. 10 minutes for testing)  
+**Result:** Two bugs prevent rollover notifications from firing every 10 minutes when the user does not open the app.
+
+---
+
+## Test setup
+
+- Schedule set with **rolloverIntervalMinutes=10** (e.g. first run 20:05).
+- Expected: notification at 20:05, 20:15, 20:25, 20:35, 20:40 (after user edit), 20:50, 21:00, 21:10, 21:20, …
+- User did **not** open the app between 20:25 and 20:36, or between 21:10 and 21:20.
+
+---
+
+## Bug 1: Rollover interval not applied when the firing run is a rollover schedule
+
+### Observed
+
+- **20:25** – Notification fired (room content; work id UUID, scheduleId `daily_rollover_1772540701872`).
+- **20:35** – **No notification.**
+
+### Logcat evidence (20:25 fire)
+
+There is **no** `DN|ROLLOVER_INTERVAL` or `DN|ROLLOVER_NEXT using_interval_minutes=10` in this block. Next run is set to **next day** at 20:25, not today 20:35:
+
+```
+03-03 20:25:01.844 D/DailyNotificationWorker: DN|RESCHEDULE_START id=29e1e984-d8b2-49ea-bb69-68b923fe4428
+03-03 20:25:01.874 D/DailyNotificationWorker: DN|ROLLOVER next=1772627100000 scheduleId=daily_rollover_1772540701872 static=false
+03-03 20:25:01.928 I/DNP-SCHEDULE: Scheduling next daily alarm: id=daily_rollover_1772540701872, nextRun=2026-03-04 20:25:00, source=ROLLOVER_ON_FIRE
+```
+
+Compare with a fire that **does** use the interval (e.g. 20:15):
+
+```
+03-03 20:15:01.860 D/DailyNotificationWorker: DN|ROLLOVER_INTERVAL scheduleId=daily_timesafari_reminder minutes=10
+03-03 20:15:01.862 D/DailyNotificationWorker: DN|ROLLOVER_NEXT using_interval_minutes=10 next=1772540700870
+03-03 20:15:01.870 D/DailyNotificationWorker: DN|ROLLOVER next=1772540700870 scheduleId=daily_timesafari_reminder static=false
+```
+
+### Root cause
+
+When the notification that just fired was scheduled from a **previous** rollover (i.e. work id is UUID / scheduleId is `daily_rollover_*`), the rollover path appears to use **+24 hours** and never reads or applies the stored `rolloverIntervalMinutes`. The interval is only applied when the firing schedule is the main/canonical one (e.g. `daily_timesafari_reminder`).
+
+### Required fix
+
+When scheduling the next run after a notification fires (rollover path), **always** resolve the **logical** schedule (e.g. map `daily_rollover_*` back to the main schedule id) and read the stored `rolloverIntervalMinutes` for that reminder. If present and > 0, set next trigger = current trigger + that many minutes (using the same logic as the path that already logs `ROLLOVER_INTERVAL` / `ROLLOVER_NEXT`). Only use +24 hours when the interval is absent or 0.
+
+---
+
+## Bug 2: ROLLOVER_ON_FIRE reschedule skipped as “duplicate” so next alarm is never set
+
+### Observed
+
+- **21:10** – Notification fired; worker correctly computes next = 21:20 (epoch 1772544000862).
+- **21:20** – **No notification.**
+
+### Logcat evidence (21:10 fire)
+
+Worker applies interval and requests next at 21:20; schedule layer skips and does **not** set the alarm:
+
+```
+03-03 21:10:01.281 D/DailyNotificationWorker: DN|ROLLOVER_INTERVAL scheduleId=daily_timesafari_reminder minutes=10
+03-03 21:10:01.284 D/DailyNotificationWorker: DN|ROLLOVER_NEXT using_interval_minutes=10 next=1772544000862
+03-03 21:10:01.294 D/DailyNotificationWorker: DN|ROLLOVER next=1772544000862 scheduleId=daily_timesafari_reminder static=false
+03-03 21:10:01.313 W/DNP-SCHEDULE: Skipping duplicate schedule: id=daily_timesafari_reminder, nextRun=2026-03-03 21:20:00, source=ROLLOVER_ON_FIRE
+03-03 21:10:01.314 W/DNP-SCHEDULE: Existing PendingIntent found for requestCode=53438 - alarm already scheduled
+03-03 21:10:01.332 I/DailyNotificationWorker: DN|RESCHEDULE_OK ...
+```
+
+So the worker reports RESCHEDULE_OK, but the scheduler did **not** call through to set the OS alarm for 21:20. The “existing” PendingIntent was for the alarm that **just fired** (21:10). Idempotence is preventing the **update** to the new trigger time.
+
+### Root cause
+
+Duplicate/idempotence logic (e.g. “Existing PendingIntent found for requestCode=53438”) is applied in a way that skips scheduling when the same schedule id is used with a **new** trigger time. For `source=ROLLOVER_ON_FIRE`, the same schedule id is **supposed** to be updated to a new trigger time every time a rollover fires. Skipping when only the trigger time changes breaks the rollover chain.
+
+### Required fix
+
+For `source=ROLLOVER_ON_FIRE`, do **not** skip scheduling when the only “match” is the same schedule id with a **different** `nextRun`/trigger time. Either:
+
+- Treat “same schedule id, different trigger time” as an **update**: cancel the existing alarm (or PendingIntent) for that schedule and set the new one for the new trigger time, or
+- In the idempotence check, require that the **existing** alarm’s trigger time equals the **requested** trigger time before skipping; if the requested time is different, proceed with cancel + set.
+
+After the fix, when the 21:10 alarm fires and the worker requests next at 21:20, the schedule layer should cancel the 21:10 alarm and set a new alarm for 21:20 (same schedule id, new trigger).
+
+---
+
+## Desired behavior (for reference)
+
+Once both bugs are fixed:
+
+- Rollover notifications should keep being scheduled every `rolloverIntervalMinutes` (e.g. 10 minutes) **without the user opening the app** between fires.
+- Flow: alarm fires → Receiver → Worker (display + reschedule) → schedule layer sets next alarm. All of this runs when the alarm fires; no app launch required.
+
+---
+
+## Summary table
+
+| Time   | Expected              | Actual        | Bug |
+|--------|------------------------|---------------|-----|
+| 20:35  | Rollover notification  | No notification | **Bug 1:** Rollover from `daily_rollover_*` path uses +24h instead of `rolloverIntervalMinutes`. |
+| 21:20  | Rollover notification  | No notification | **Bug 2:** Schedule layer skips with “Skipping duplicate schedule” / “Existing PendingIntent found”; 21:20 alarm never set. |

doc/plugin-feedback-android-scheduleDualNotification-contentFetch-json.md

@@ -0,0 +1,117 @@
+# Plugin feedback: Android `scheduleDualNotification` — `JSONException: No value for timeout`
+
+**Date:** 2026-03-20 18:21 PST  
+**Target repo:** `@timesafari/daily-notification-plugin` (daily-notification-plugin)  
+**Consuming app:** crowd-funder-for-time-pwa (TimeSafari)  
+**Platform:** Android (Kotlin)  
+**Plugin version observed:** 2.1.2 (from app `node_modules`)
+
+---
+
+## Summary
+
+Scheduling the **New Activity** dual notification on Android fails with a native `JSONException` because `DailyNotificationPlugin.parseContentFetchConfig()` uses **`JSONObject.getInt()`** for `timeout`, `retryAttempts`, and `retryDelay`. Those keys are **absent** from the app’s `contentFetch` object built by `buildDualScheduleConfig()`. The plugin’s own TypeScript `ContentFetchConfig` marks those fields as **optional**, so the Android parser is stricter than the published contract.
+
+**Recommended direction:**
+
+1. **Plugin (primary):** Parse optional numeric fields with defaults (e.g. `optInt` / nullable + defaults) so payloads that omit them do not crash and match `definitions.d.ts`.
+2. **App (secondary / compatibility):** Include explicit `timeout`, `retryAttempts`, and `retryDelay` on `contentFetch` so older plugin versions that still use `getInt` continue to work.
+
+**Does it make sense to change both sides?** **Yes.** Fixing the plugin aligns behavior with the documented API and protects any consumer that omits those fields. Fixing the app is still valuable for **older shipped plugin builds** and makes network behavior explicit. Together you get backward compatibility, clearer intent, and no silent reliance on undocumented defaults.
+
+---
+
+## Symptoms (consuming app)
+
+- In-app toast: *“Could not schedule New Activity notification. Please try again.”* (generic error path after `scheduleDualNotification` rejects.)
+- Logcat (filtered on DNP / plugin tags):
+
+```text
+E DNP-PLUGIN: Schedule dual notification error
+E DNP-PLUGIN: org.json.JSONException: No value for timeout
+E DNP-PLUGIN:   at org.json.JSONObject.getInt(JSONObject.java:487)
+E DNP-PLUGIN:   at org.timesafari.dailynotification.DailyNotificationPlugin.parseContentFetchConfig(DailyNotificationPlugin.kt:2403)
+E DNP-PLUGIN:   at org.timesafari.dailynotification.DailyNotificationPlugin.scheduleDualNotification(DailyNotificationPlugin.kt:1391)
+```
+
+---
+
+## Root cause
+
+### Call path
+
+`scheduleDualNotification` reads `config.contentFetch` and passes it to `parseContentFetchConfig`:
+
+- File: `android/.../DailyNotificationPlugin.kt`
+- `scheduleDualNotification` ~1391: `parseContentFetchConfig(contentFetchObj)`
+- `parseContentFetchConfig` ~2397–2411: uses `getInt` for three keys.
+
+### Strict Android parsing
+
+Illustrative (exact line numbers may shift between releases):
+
+```kotlin
+// parseContentFetchConfig — timeout / retry fields are required via getInt()
+timeout = configJson.getInt("timeout"),
+retryAttempts = configJson.getInt("retryAttempts"),
+retryDelay = configJson.getInt("retryDelay"),
+```
+
+`getInt` throws if the key is missing → first missing key in practice is `timeout` → `JSONException: No value for timeout`.
+
+### App payload today (consuming app)
+
+File: `src/services/notifications/dualScheduleConfig.ts` — `buildDualScheduleConfig()` sets `contentFetch` to:
+
+- `enabled`, `schedule`, `callbacks` only (no `timeout`, `retryAttempts`, `retryDelay`, no `url`).
+
+That matches the **TypeScript** contract in the plugin’s `dist/esm/definitions.d.ts`, where `timeout`, `retryAttempts`, and `retryDelay` are **optional** on `ContentFetchConfig`.
+
+### Contract mismatch
+
+| Layer | `timeout` / `retryAttempts` / `retryDelay` |
+|--------|--------------------------------------------|
+| TS `ContentFetchConfig` | Optional (`?`) |
+| Android `parseContentFetchConfig` | Required (`getInt` — throws if absent) |
+
+The consuming app followed the TS API; Android rejected it at runtime.
+
+---
+
+## Plugin-side recommendations
+
+1. **Use optional reads with defaults** for `timeout`, `retryAttempts`, and `retryDelay` (and any similar fields), e.g. Kotlin/Capacitor equivalents of `optInt` or `getInteger` with fallbacks documented in `ContentFetchConfig`.
+2. **Document defaults** in the plugin README or API docs if they are applied on native when omitted.
+3. **Consider tests** that call `scheduleDualNotification` with a minimal `contentFetch` (only `enabled`, `schedule`, `callbacks`) and assert scheduling succeeds on Android.
+4. **Optional:** If `url` is also read in a way that assumes presence, align with TS (`url?`) the same way.
+
+---
+
+## App-side recommendations (later; crowd-funder-for-time-pwa)
+
+When you implement the app fix:
+
+- Extend `contentFetch` in `buildDualScheduleConfig()` (`src/services/notifications/dualScheduleConfig.ts`) to include explicit integers, for example aligned with existing app/network conventions (the app’s `capacitor.config.ts` already uses a `timeout` value in one place — reuse or document chosen values).
+- Ensure **both** code paths that build dual config stay in sync (e.g. `AccountViewView.vue` uses `buildDualScheduleConfig` for New Activity scheduling and for `updateDualScheduleConfig` fallback).
+
+This unblocks users on **current** plugin versions that still require those keys.
+
+---
+
+## References (paths in consuming app workspace)
+
+- App config builder: `src/services/notifications/dualScheduleConfig.ts`
+- Native scheduling entry: `node_modules/@timesafari/daily-notification-plugin/android/.../DailyNotificationPlugin.kt` (`scheduleDualNotification`, `parseContentFetchConfig`)
+
+---
+
+## Answer: change both plugin and app?
+
+**Yes, it makes sense to change both**, for different reasons:
+
+| Side | Why |
+|------|-----|
+| **Plugin** | Fixes the real bug: native behavior must match the published optional TS fields; avoids breaking any client that sends a minimal `contentFetch`. |
+| **App** | Defense in depth and support for **already-shipped** plugin binaries that will not get the Kotlin fix until users update the app. Explicit values also document intended fetch/retry behavior in one place. |
+
+If you only fix the plugin, new app releases still need users to update the **native** binary. If you only fix the app, any other consumer of the plugin or future minimal payloads can hit the same crash until the plugin is fixed.

doc/plugin-feedback-daily-notification-configureNativeFetcher-jwt-pool.md

@@ -0,0 +1,95 @@
+# Plugin feedback: `configureNativeFetcher` — optional JWT pool for background API calls
+
+**Date:** 2026-03-27 PST  
+**Target repo:** `@timesafari/daily-notification-plugin` (daily-notification-plugin)  
+**Consuming app:** crowd-funder-for-time-pwa (TimeSafari)  
+**Related app plan:** `doc/plan-background-jwt-pool-and-expiry.md` (Phase B, Option B1)
+
+---
+
+## Summary
+
+The host app’s **`NativeNotificationContentFetcher`** (`TimeSafariNativeFetcher` on Android) calls Endorser with a Bearer JWT set via **`configureNativeFetcher`**. For **background** prefetch, the token must stay valid until WorkManager runs (often **minutes later**); Endorser may also reject **duplicate** JWT strings across days.
+
+The **app** will mint a **pool** of distinct JWTs (see app plan) and needs the plugin to **accept and persist** that pool so native code can select a token **without JavaScript** at prefetch time.
+
+**Requested change (plugin):** extend **`configureNativeFetcher`** to accept an optional **JWT pool** alongside the existing **`jwtToken`**, persist it in the same storage the host already relies on (e.g. SharedPreferences / app group), and document how **`NativeNotificationContentFetcher`** implementations should read it.
+
+---
+
+## Motivation
+
+| Issue | Why plugin support helps |
+|-------|---------------------------|
+| Single short-lived `jwtToken` | Expires before background fetch |
+| Server duplicate-JWT rules | Need many distinct bearer strings over time |
+| No JS in WorkManager | Pool must be readable **only** from native |
+
+---
+
+## Proposed API (TypeScript / Capacitor)
+
+**Extend** existing `configureNativeFetcher` options (names indicative — align with plugin naming conventions):
+
+```ts
+configureNativeFetcher(options: {
+  apiBaseUrl: string;
+  activeDid: string;
+  /** Primary token; keep for backward compatibility and Phase A (single long-lived JWT). */
+  jwtToken: string;
+  /**
+   * Optional. Distinct JWT strings for background use (e.g. one per day slot).
+   * If omitted, behavior matches today (single jwtToken only).
+   */
+  jwtTokens?: string[];
+});
+```
+
+**Alternatives** (if size limits matter for bridge payload):
+
+- `jwtTokenPoolJson: string` — JSON array string of JWT strings (single string across the bridge).
+
+**Validation (plugin):**
+
+- If `jwtTokens` present: length **≤** a sane cap (host will use ~100; plugin may enforce max e.g. 128).
+- Empty array: treat as “no pool” (same as omitting).
+
+---
+
+## Android
+
+1. **Parse** new fields in `DailyNotificationPlugin.configureNativeFetcher` (or equivalent).
+2. **Persist** pool under the same prefs namespace used for other TimeSafari / dual-schedule data, or a **documented** key prefix (e.g. `jwt_token_pool` as JSON array string).
+3. **Document** for host implementers: `NativeNotificationContentFetcher` should:
+   - Prefer **pool entry** for `fetchContent` when pool is non-empty (selection policy is **host** responsibility — e.g. day index % length), **or**
+   - Expose a small helper the host fetcher calls to resolve “current” bearer.
+4. **Clear** pool when `configureNativeFetcher` is called with a new identity / empty pool / logout path (coordinate with host).
+5. **Backward compatibility:** if only `jwtToken` is sent, behavior **unchanged** from current release.
+
+---
+
+## iOS
+
+When `configureNativeFetcher` exists on iOS, mirror Android: accept optional pool, persist, document read path for native fetcher.
+
+---
+
+## Versioning & release
+
+- Bump **plugin semver** (minor: new optional fields).
+- Publish package; consuming app bumps **`@timesafari/daily-notification-plugin`** and updates `nativeFetcherConfig.ts` to pass `jwtTokens` when Phase B ships.
+
+---
+
+## References (host app)
+
+| Topic | Location |
+|--------|----------|
+| End-to-end plan (Phase A/B, pool sizing) | `doc/plan-background-jwt-pool-and-expiry.md` |
+| Android fetcher | `android/.../TimeSafariNativeFetcher.java` |
+| Current configure call | `src/services/notifications/nativeFetcherConfig.ts` |
+| JWT options (expired token context) | `doc/endorser-jwt-background-prefetch-options.md` |
+
+---
+
+*This document is intended to be copied or linked from PRs in **daily-notification-plugin**; keep app-specific details in the app plan.*

doc/plugin-feedback-ios-scheduleDualNotification.md

@@ -0,0 +1,140 @@
+# Plugin Feedback: Implement scheduleDualNotification on iOS
+
+**Target repo:** daily-notification-plugin (iOS native layer)  
+**Purpose:** Document for implementing or fixing `scheduleDualNotification` on iOS so the consuming app (TimeSafari / crowd-funder) can enable “New Activity” notifications.  
+**Consuming app doc:** `doc/notification-new-activity-lay-of-the-land.md`
+
+---
+
+## Troubleshooting: `UNIMPLEMENTED` on iOS (Capacitor 6)
+
+If **`configureNativeFetcher`** (or other DailyNotification methods) work but **`scheduleDualNotification`** still fails with **`{"code":"UNIMPLEMENTED"}`** and you **do not** see a native log line like `To Native -> DailyNotification scheduleDualNotification`, the failure is often **not** missing Swift code—it is **Capacitor’s JavaScript layer** rejecting the call because the method is **not listed** in `window.Capacitor.PluginHeaders` for `DailyNotification`. Those headers are built at runtime from the **compiled** plugin’s `pluginMethods` list (`CAPBridgedPlugin`).
+
+**Fix in the consuming app (usual cause: stale Pods / binary):**
+
+1. Ensure `node_modules/@timesafari/daily-notification-plugin` includes `scheduleDualNotification` in `DailyNotificationPlugin.swift`’s `pluginMethods` (v2.1.0+).
+2. From the project root: `npx cap sync ios`
+3. `cd ios/App && pod install` (or delete `Pods` + `Podfile.lock` and `pod install` if upgrading the plugin).
+4. Xcode: **Product → Clean Build Folder**, then rebuild and run on device/simulator.
+
+**Verify:** Safari → Develop → attach to the app WebView → Console: inspect `window.Capacitor.PluginHeaders` and confirm the `DailyNotification` entry’s `methods` array includes `{ name: "scheduleDualNotification", ... }`.
+
+If a full clean rebuild still doesn't fix it, clear Xcode's **system** DerivedData (quit Xcode, run `rm -rf ~/Library/Developer/Xcode/DerivedData/*TimeSafari*`, reopen and rebuild). On launch the app logs `[Capacitor] DNP PluginHeaders methods: [...]`; if that list omits `scheduleDualNotification`, the native binary is still stale.
+
+If the method **is** present in headers but scheduling still fails, debug the Swift implementation (reject message, BG tasks, etc.).
+
+### Misleading `UNIMPLEMENTED` before `scheduleDualNotification`
+
+Capacitor’s `registerPlugin` proxy returns a **callable stub for every property name**. So `if (DailyNotification?.updateStarredPlans)` is **always truthy** even when iOS does not expose `updateStarredPlans` in `pluginMethods`. Calling that stub throws **`UNIMPLEMENTED`** in JS **before** any `To Native -> DailyNotification scheduleDualNotification` line appears—so logs look like “dual schedule is unimplemented” when the real failure was **`updateStarredPlans`**.
+
+**Consuming-app fix:** treat `updateStarredPlans` as optional: catch `UNIMPLEMENTED` and continue, or only call after verifying the method name exists on `PluginHeaders` for `DailyNotification`. If the plugin adds `updateStarredPlans` natively later, starred-plan filtering will start working without app changes.
+
+---
+
+## Current behavior
+
+- The **consuming app** calls `DailyNotification.scheduleDualNotification({ config })` from TypeScript when the user turns on “New Activity Notification” and picks a time (native iOS).
+- On **iOS**, the plugin rejects with **`code: "UNIMPLEMENTED"`** (observed in Xcode: `[AccountViewView] scheduleNewActivityDualNotification failed: {"code":"UNIMPLEMENTED"}`).
+- On **Android**, the same call is expected to work (dual schedule: content fetch + user notification).
+
+The app has already:
+
+- Called `configureNativeFetcher({ apiBaseUrl, activeDid, jwtToken })` so the plugin can use the native fetcher for API-driven content.
+- Called `updateStarredPlans({ planIds })` so the fetcher knows which plans to query.
+- Built a `config` object that matches the plugin’s `DualScheduleConfiguration` (see below).
+
+So the missing piece on iOS is a **working implementation** of `scheduleDualNotification` that accepts this config and schedules the dual flow (content fetch at one time, user notification at a later time).
+
+---
+
+## Call from the consuming app
+
+```ts
+await DailyNotification.scheduleDualNotification({ config });
+```
+
+`config` is built by the app’s `buildDualScheduleConfig({ notifyTime })` and has the following shape.
+
+---
+
+## Config shape the app sends
+
+The app sends a single `config` object that matches the plugin’s `DualScheduleConfiguration` (see `definitions.ts`). Example for `notifyTime: "18:30"` (6:30 PM):
+
+```json
+{
+  "contentFetch": {
+    "enabled": true,
+    "schedule": "25 18 * * *",
+    "callbacks": {}
+  },
+  "userNotification": {
+    "enabled": true,
+    "schedule": "30 18 * * *",
+    "title": "New Activity",
+    "body": "Check your starred projects and offers for updates.",
+    "sound": true,
+    "priority": "normal"
+  },
+  "relationship": {
+    "autoLink": true,
+    "contentTimeout": 300000,
+    "fallbackBehavior": "show_default"
+  }
+}
+```
+
+- **Cron format:** `"minute hour * * *"` (daily at that local time).
+- **contentFetch.schedule:** 5 minutes **before** the user’s chosen time (e.g. 18:25 for notify at 18:30).
+- **userNotification.schedule:** The user’s chosen time (e.g. 18:30).
+- **contentFetch.callbacks:** The app sends `{}`; the actual fetch is done by the **native fetcher** (already configured via `configureNativeFetcher`). The plugin should run the content-fetch job at the contentFetch cron and use the native fetcher to get content; at userNotification time it should show a notification using that content or the fallback title/body.
+- **relationship.contentTimeout:** Milliseconds to wait for content before showing the notification (app uses 5 minutes = 300000).
+- **relationship.fallbackBehavior:** `"show_default"` means if content isn’t ready in time, show the notification with the default title/body from `userNotification`.
+
+The app does **not** send `contentFetch.url` or `contentFetch.timesafariConfig`; it relies on the native fetcher and `configureNativeFetcher` / `updateStarredPlans` for API behavior.
+
+---
+
+## Expected plugin behavior (iOS)
+
+1. **Accept** the `config` argument (object with `contentFetch`, `userNotification`, and optional `relationship`).
+2. **Parse** the cron expressions for `contentFetch.schedule` and `userNotification.schedule` (e.g. using a shared cron parser or the same approach as Android).
+3. **Schedule** two things:
+   - **Content fetch:** At the time given by `contentFetch.schedule`, run the **native notification content fetcher** (the one configured via `configureNativeFetcher`). Store the result in the plugin’s cache (or equivalent) for use when the user notification fires.
+   - **User notification:** At the time given by `userNotification.schedule`, show a local notification. Use cached content from the fetch if available and within `relationship.contentTimeout`; otherwise use `userNotification.title` and `userNotification.body` (per `relationship.fallbackBehavior: "show_default"`).
+4. **Do not** reject with `UNIMPLEMENTED`; resolve the promise once scheduling has succeeded (or reject with a descriptive error if scheduling fails).
+5. **cancelDualSchedule()** should cancel both the content-fetch schedule and the user-notification schedule so the user can turn off New Activity from the app.
+
+Alignment with **Android** (if implemented there) is desirable: same config shape, same semantics (prefetch then notify, fallback to default title/body). The plugin’s **definitions.ts** already defines `DualScheduleConfiguration`, `ContentFetchConfig`, `UserNotificationConfig`, and the `scheduleDualNotification` / `cancelDualSchedule` API.
+
+---
+
+## Where to look in the plugin (iOS)
+
+- **Plugin entry:** `ios/Plugin/DailyNotificationPlugin.swift` (or equivalent)—find the handler for `scheduleDualNotification` (e.g. method that receives `call.getObject("config")`).
+- **Android reference:** `android/` implementation of `scheduleDualNotification` and how it schedules WorkManager/alarms for content fetch and for the user notification.
+- **Definitions:** `src/definitions.ts` — `DualScheduleConfiguration`, `scheduleDualNotification`, `cancelDualSchedule`.
+- **Native fetcher:** The app configures the native fetcher before calling `scheduleDualNotification`; the iOS plugin should invoke that same fetcher when the content-fetch job runs (BGAppRefreshTask or equivalent), not a URL from the config.
+
+---
+
+## Acceptance criteria
+
+- [ ] On iOS, calling `DailyNotification.scheduleDualNotification({ config })` with the config shape above **does not** reject with `code: "UNIMPLEMENTED"`.
+- [ ] The content-fetch job is scheduled at `contentFetch.schedule` and uses the configured native fetcher to fetch content.
+- [ ] The user notification is scheduled at `userNotification.schedule` and shows with API-derived content when available, or with `userNotification.title` / `userNotification.body` as fallback.
+- [ ] Calling `DailyNotification.cancelDualSchedule()` cancels both schedules on iOS.
+- [ ] Behavior is consistent with Android where applicable (same config, same lifecycle).
+
+---
+
+## Relationship to consuming app
+
+The consuming app will continue to call:
+
+1. `configureNativeFetcher(...)` on startup and when enabling New Activity.
+2. `updateStarredPlans({ planIds })` when enabling or when Account view loads with New Activity on.
+3. `scheduleDualNotification({ config })` when the user turns on New Activity and picks a time.
+4. `cancelDualSchedule()` when the user turns off New Activity.
+
+No change to the app’s config shape or call order is planned; the fix is entirely on the plugin iOS side to implement or correct `scheduleDualNotification` (and ensure `cancelDualSchedule` clears the dual schedule).

doc/plugin-fix-android-DailyNotificationWorker-duplicate-scheduleId.md

@@ -0,0 +1,96 @@
+# Plugin fix: Android compile error — duplicate `scheduleId` in `handleDisplayNotification`
+
+**Date:** 2026-03-20  
+**Target repo:** `@timesafari/daily-notification-plugin` (daily-notification-plugin)  
+**Consuming app:** crowd-funder-for-time-pwa (TimeSafari)  
+**Platform:** Android (Java)
+
+---
+
+## Summary
+
+The Android module fails to compile with **two** `javac` errors: `variable scheduleId is already defined in method handleDisplayNotification(String)`. The method already declares `String scheduleId` at the start of the `try` block; two nested blocks incorrectly **redeclare** `String scheduleId`, which Java forbids in the same method scope. Remove the redundant declarations and reuse the existing variable (or assign without `String` if you ever need to refresh it).
+
+---
+
+## Problem
+
+- **File:** `android/src/main/java/org/timesafari/dailynotification/DailyNotificationWorker.java`
+- **Method:** `private Result handleDisplayNotification(String notificationId)`
+
+**Compiler output (representative):**
+
+```text
+DailyNotificationWorker.java:162: error: variable scheduleId is already defined in method handleDisplayNotification(String)
+                String scheduleId = inputData.getString("schedule_id");
+                       ^
+DailyNotificationWorker.java:193: error: variable scheduleId is already defined in method handleDisplayNotification(String)
+                String scheduleId = inputData.getString("schedule_id");
+                       ^
+```
+
+**Root cause:** At the top of the `try` block, the code already has:
+
+```java
+Data inputData = getInputData();
+String scheduleId = inputData.getString("schedule_id");
+```
+
+Later, inside:
+
+1. The `if (isStaticReminder) { ... }` branch — a line like `String scheduleId = inputData.getString("schedule_id");` (around line 162).
+2. The `else { ... }` branch — the same pattern (around line 193).
+
+In Java, a local variable name cannot be declared again in nested blocks that share the enclosing method’s scope for that name. These inner `String scheduleId` lines are **illegal** and break `:timesafari-daily-notification-plugin:compileDebugJavaWithJavac`.
+
+**Functional note:** Both inner reads use the same key (`"schedule_id"`) as the outer declaration, so they add **no** new information; the fix is to **delete** those inner declarations and keep using `scheduleId` from the first assignment.
+
+---
+
+## Required change
+
+**Option A (recommended):** Delete the two redundant lines entirely:
+
+- Remove the inner `String scheduleId = inputData.getString("schedule_id");` in the **static reminder** branch (post-reboot/rollover comment block).
+- Remove the inner `String scheduleId = inputData.getString("schedule_id");` in the **regular notification** branch (rollover/notify_* comment block).
+
+All subsequent uses of `scheduleId` in those branches should continue to refer to the variable declared immediately after `getInputData()`.
+
+**Option B (only if you must re-read input later):** Replace redeclaration with assignment:
+
+```java
+scheduleId = inputData.getString("schedule_id");
+```
+
+Do **not** prefix with `String` again inside the same method.
+
+---
+
+## Verification
+
+1. **Compile:** From the plugin repo, run the Android Java compile for the library (or assemble debug). Expect **zero** errors for `DailyNotificationWorker.java`.
+2. **Consuming app:** Bump/publish the plugin version, update `package.json` in TimeSafari, `npm install`, `npx cap sync android`, then run the usual Android debug build (e.g. `./scripts/build-android.sh --test` or `assembleDebug`). The task `:timesafari-daily-notification-plugin:compileDebugJavaWithJavac` must succeed.
+3. **Behavior:** No intended behavior change: `schedule_id` is still read once per worker run from `getInputData()` and used for dual-prefix checks, static reminder DB fallback, and canonical content by `schedule_id` in the non-static path.
+
+---
+
+## Context (how this was found)
+
+- Observed when running `npm run build:android:test:run` on crowd-funder-for-time-pwa; Vite/TypeScript succeeded; Gradle failed on the plugin’s Java sources under `node_modules/.../DailyNotificationWorker.java`.
+- Line numbers in published packages may drift slightly; search for `handleDisplayNotification` and duplicate `String scheduleId` inside that method.
+
+---
+
+## Cursor prompt (paste into plugin repo)
+
+You can paste the block below into Cursor in the **daily-notification-plugin** workspace:
+
+```text
+Fix Android compile errors in DailyNotificationWorker.java: in handleDisplayNotification(String notificationId), scheduleId is declared once after getInputData(). Remove the two illegal inner redeclarations "String scheduleId = inputData.getString(\"schedule_id\");" (static reminder branch and else branch). Reuse the outer scheduleId variable. Do not shadow or redeclare String scheduleId in the same method. Verify compileDebugJavaWithJavac passes.
+```
+
+---
+
+## After the fix
+
+Release a new plugin version and update the consuming app’s dependency so `node_modules` is not hand-edited (edits there are lost on `npm install`).

doc/plugin-fix-scheduleExactNotification-calls.md

@@ -0,0 +1,108 @@
+# Plugin fix: Update Java call sites for scheduleExactNotification (8th parameter)
+
+## Problem
+
+After adding the 8th parameter `skipPendingIntentIdempotence: Boolean = false` to `NotifyReceiver.scheduleExactNotification()` in NotifyReceiver.kt, the Java callers still pass only 7 arguments. That causes a compilation error when building an app that depends on the plugin:
+
+```
+error: method scheduleExactNotification in class NotifyReceiver cannot be applied to given types;
+  required: Context,long,UserNotificationConfig,boolean,String,String,ScheduleSource,boolean
+  found:    Context,long,UserNotificationConfig,boolean,<null>,String,ScheduleSource
+  reason: actual and formal argument lists differ in length
+```
+
+**Affected files (in the plugin repo):**
+- `android/src/main/java/org/timesafari/dailynotification/DailyNotificationReceiver.java`
+- `android/src/main/java/org/timesafari/dailynotification/DailyNotificationWorker.java`
+
+## Current Kotlin signature (NotifyReceiver.kt)
+
+```kotlin
+fun scheduleExactNotification(
+    context: Context,
+    triggerAtMillis: Long,
+    config: UserNotificationConfig,
+    isStaticReminder: Boolean = false,
+    reminderId: String? = null,
+    scheduleId: String? = null,
+    source: ScheduleSource = ScheduleSource.MANUAL_RESCHEDULE,
+    skipPendingIntentIdempotence: Boolean = false  // 8th parameter
+)
+```
+
+## Required change
+
+In both Java files, add the **8th argument** to every call to `NotifyReceiver.scheduleExactNotification(...)`.
+
+### 1. DailyNotificationReceiver.java
+
+**Location:** around line 441, inside `scheduleNextNotification()`.
+
+**Current call:**
+```java
+org.timesafari.dailynotification.NotifyReceiver.scheduleExactNotification(
+    context,
+    nextScheduledTime,
+    config,
+    false, // isStaticReminder
+    null,  // reminderId
+    scheduleId,
+    org.timesafari.dailynotification.ScheduleSource.ROLLOVER_ON_FIRE
+);
+```
+
+**Fixed call (add 8th argument):**
+```java
+org.timesafari.dailynotification.NotifyReceiver.scheduleExactNotification(
+    context,
+    nextScheduledTime,
+    config,
+    false, // isStaticReminder
+    null,  // reminderId
+    scheduleId,
+    org.timesafari.dailynotification.ScheduleSource.ROLLOVER_ON_FIRE,
+    false  // skipPendingIntentIdempotence – rollover path does not skip
+);
+```
+
+### 2. DailyNotificationWorker.java
+
+**Location:** around line 584, inside `scheduleNextNotification()`.
+
+**Current call:**
+```java
+org.timesafari.dailynotification.NotifyReceiver.scheduleExactNotification(
+    getApplicationContext(),
+    nextScheduledTime,
+    config,
+    false, // isStaticReminder
+    null,  // reminderId
+    scheduleId,
+    org.timesafari.dailynotification.ScheduleSource.ROLLOVER_ON_FIRE
+);
+```
+
+**Fixed call (add 8th argument):**
+```java
+org.timesafari.dailynotification.NotifyReceiver.scheduleExactNotification(
+    getApplicationContext(),
+    nextScheduledTime,
+    config,
+    false, // isStaticReminder
+    null,  // reminderId
+    scheduleId,
+    org.timesafari.dailynotification.ScheduleSource.ROLLOVER_ON_FIRE,
+    false  // skipPendingIntentIdempotence – rollover path does not skip
+);
+```
+
+## Other call sites
+
+Kotlin call sites (NotifyReceiver.kt, DailyNotificationPlugin.kt, ReactivationManager.kt, BootReceiver.kt) use **named parameters**, so they already get the default for `skipPendingIntentIdempotence` and do not need changes. Only the **Java** call sites use positional arguments, so only the two files above need the 8th argument added. If you add new Java call sites later, pass the 8th parameter explicitly: `false` for rollover/fire paths, `true` only where the caller has just cancelled this schedule and you intend to skip the PendingIntent idempotence check.
+
+## Verification
+
+After updating the plugin:
+
+1. Build the plugin (e.g. `./gradlew :timesafari-daily-notification-plugin:compileDebugJavaWithJavac` or full Android build from a consuming app).
+2. Ensure there are no “actual and formal argument lists differ in length” errors.

doc/plugin-spec-rollover-interval-minutes.md

@@ -0,0 +1,148 @@
+# Plugin spec: Configurable rollover interval (e.g. 10 minutes for testing)
+
+**Date:** 2026-03-03  
+**Target repo:** daily-notification-plugin  
+**Consuming app:** crowd-funder-for-time-pwa (TimeSafari)  
+**Platforms:** iOS and Android
+
+## Summary
+
+The consuming app needs to support **rapid testing** of daily notification rollover on device. Today, after a notification fires, the plugin always schedules the next occurrence **24 hours** later. We need an **optional** parameter so the app can request a different interval (e.g. **10 minutes**) for dev/testing. When that parameter is present, the plugin must:
+
+1. Use the given interval (in minutes) when scheduling the **next** occurrence after a notification fires (rollover).
+2. **Persist** that interval with the schedule so that it survives **device reboot** and is used again when:
+   - Boot recovery reschedules alarms from stored data, and
+   - Any subsequent rollover runs (after the next notification fires).
+
+If the interval is not persisted, then after a device restart the plugin would no longer know to use 10 minutes and would fall back to 24 hours; rapid testing after reboot would break. So persistence is a **required** part of this feature.
+
+---
+
+## API contract (app → plugin)
+
+### Method: `scheduleDailyNotification` (or equivalent used for the app’s daily reminder)
+
+**Add an optional parameter:**
+
+- **Name:** `rolloverIntervalMinutes` (or equivalent, e.g. `repeatIntervalMinutes`).
+- **Type:** `number` (integer), optional.
+- **Meaning:** When the scheduled notification fires, schedule the **next** occurrence this many **minutes** after the current trigger time (instead of 24 hours). When **absent** or not provided, behavior is unchanged: next occurrence is **24 hours** later (current behavior).
+
+**Example (pseudocode):**
+
+- App calls: `scheduleDailyNotification({ id, time, title, body, ..., rolloverIntervalMinutes: 10 })`.
+- Plugin stores the schedule **including** `rolloverIntervalMinutes: 10`.
+- When the notification fires, plugin computes next trigger = current trigger + 10 minutes (instead of + 24 hours), and schedules that.
+- When the device reboots, boot recovery loads the schedule, sees `rolloverIntervalMinutes: 10`, and uses it when (a) computing the next run time for reschedule and (b) any future rollover after the next fire.
+
+**Example (normal production, no param):**
+
+- App calls: `scheduleDailyNotification({ id, time, title, body })` (no `rolloverIntervalMinutes`).
+- Plugin stores the schedule with no interval (or default 24h).
+- Rollover and boot recovery behave as today: next occurrence 24 hours later.
+
+---
+
+## Persistence requirement (critical for device restart)
+
+The rollover interval must be **stored with the schedule** in the plugin’s persistent storage (e.g. Room on Android, UserDefaults/DB on iOS), not only kept in memory. Concretely:
+
+1. **When the app calls `scheduleDailyNotification` with `rolloverIntervalMinutes`:**
+   - Persist that value in the same place you persist the rest of the schedule (e.g. Schedule entity, or equivalent table/row that is read on boot and on rollover).
+
+2. **When computing the next occurrence (rollover path, after a notification fires):**
+   - Read the stored `rolloverIntervalMinutes` for that schedule.
+   - If present and > 0: next trigger = current trigger + `rolloverIntervalMinutes` minutes.
+   - If absent or 0: next trigger = current trigger + 24 hours (existing behavior).
+
+3. **When boot recovery runs (after device restart):**
+   - Load schedules from persistent storage (including the stored `rolloverIntervalMinutes`).
+   - When rescheduling each alarm, use the stored interval to compute the next run time (same logic as rollover: if interval is set, use it; otherwise 24 hours).
+   - When the next notification fires after reboot, the rollover path will again read the same stored value, so the 10-minute (or whatever) interval continues to apply.
+
+4. **When the app calls `scheduleDailyNotification` without `rolloverIntervalMinutes` (or to turn off fast rollover):**
+   - Overwrite the stored schedule so that the interval is cleared or set to default (24h). Subsequent rollovers and boot recovery then use 24 hours again.
+
+**Why this matters:** Without persisting the interval, a device restart would lose the “10 minutes” setting; rollover and boot recovery would have no way to know to use 10 minutes and would default to 24 hours. Rapid testing after reboot would not work.
+
+---
+
+## Platform-specific notes
+
+### Android
+
+- **Storage:** Add `rollover_interval_minutes` (or equivalent) to the Schedule entity (or wherever the app’s reminder schedule is stored) and persist it when handling `scheduleDailyNotification`. Use it in:
+  - Rollover path (e.g. when scheduling next alarm after notification fires).
+  - Boot recovery path (when rebuilding alarms from DB after `BOOT_COMPLETED`).
+- **Next trigger:** Current trigger time + `rolloverIntervalMinutes` minutes (using `Calendar` or equivalent so DST/timezone is handled correctly; same care as for 24h rollover).
+
+### iOS
+
+- **Storage:** Add the same field to whatever persistent structure holds the schedule (e.g. the same place that stores time, title, body, id). Persist it when the app calls the schedule method.
+- **Rollover:** In `scheduleNextNotification()` (or equivalent), read the stored interval; if set, use `Calendar.date(byAdding: .minute, value: rolloverIntervalMinutes, to: currentDate)` (or equivalent) instead of adding 24 hours.
+- **App launch / recovery:** If the plugin has any path that restores or reschedules after app launch or system events, use the stored interval there as well so behavior is consistent.
+
+---
+
+## Edge cases and defaults
+
+- **Parameter absent:** Do not change current behavior. Next occurrence = 24 hours later.
+- **Parameter = 0 or negative:** Treat as “use default”; same as absent (24 hours).
+- **Parameter > 0 (e.g. 10):** Next occurrence = current trigger + that many minutes.
+- **Existing schedules (created before this feature):** No stored interval → treat as 24 hours. No migration required beyond “missing field = default”.
+
+---
+
+## App-side behavior (for context)
+
+- The app will only pass `rolloverIntervalMinutes` when a **dev-only** setting is enabled (e.g. “Use 10-minute rollover for testing” in the Notifications section). Production users will not set it.
+- The app will pass it on every `scheduleDailyNotification` call when the user has that setting on (first-time enable and edit). When the user turns the setting off, the app will call `scheduleDailyNotification` without the parameter (so the plugin can persist “no interval” / 24h).
+
+---
+
+## Verification (plugin repo)
+
+1. **Rollover with interval:** Schedule with `rolloverIntervalMinutes: 10`. Trigger the notification (or wait). Confirm the **next** scheduled time is ~10 minutes after the current trigger (not 24 hours). Let it fire again; confirm the following occurrence is again ~10 minutes later.
+2. **Persistence:** Schedule with `rolloverIntervalMinutes: 10`, then **restart the device** (do not open the app). After boot, confirm (via logs or next fire) that the rescheduled alarm uses the 10-minute interval (e.g. next fire is 10 minutes after the last stored trigger, not 24 hours). After that notification fires, confirm the **next** rollover is still 10 minutes later.
+3. **Default:** Schedule without `rolloverIntervalMinutes`. Confirm next occurrence is 24 hours later. Reboot; confirm boot recovery still uses 24 hours.
+4. **Turn off:** Schedule with 10 minutes, then have the app call `scheduleDailyNotification` again with the same id/time but **no** `rolloverIntervalMinutes`. Confirm stored interval is cleared and next rollover is 24 hours.
+
+---
+
+## Short summary for plugin maintainers
+
+- **New optional parameter:** `rolloverIntervalMinutes?: number` on the schedule method used for the app’s daily reminder.
+- **When set (e.g. 10):** After a notification fires, schedule the next occurrence in that many **minutes** instead of 24 hours.
+- **Must persist:** Store the value with the schedule in the plugin’s DB/storage. Use it in **rollover** and in **boot recovery** so that after a device restart the same interval is used. Without persistence, the feature would not work after reboot.
+- **When absent:** Behavior unchanged (24-hour rollover). No migration needed for existing schedules.
+
+---
+
+## For Cursor (plugin repo) — actionable handoff
+
+Use this section when implementing this feature in the **daily-notification-plugin** repo (e.g. with Cursor). You can paste or @-mention this doc as context.
+
+**Goal:** Support an optional `rolloverIntervalMinutes` (or equivalent) on the daily reminder schedule API. When provided (e.g. `10`), schedule the next occurrence that many minutes after the current trigger instead of 24 hours. **Persist this value** with the schedule so that rollover and boot recovery both use it; after a device restart, the same interval must still apply.
+
+**Concrete tasks:**
+
+1. **API:** In the plugin interface used by the app (e.g. `scheduleDailyNotification`), add an optional parameter `rolloverIntervalMinutes?: number`. Document that when absent, next occurrence is 24 hours (current behavior).
+
+2. **Storage (Android):** In the Schedule entity (or equivalent), add a column/field for the rollover interval (e.g. `rollover_interval_minutes` nullable Int). When handling `scheduleDailyNotification`, persist the value if present; if absent, store null or 0 to mean “24 hours”.
+
+3. **Storage (iOS):** Add the same field to the persistent structure that holds the reminder schedule. Persist it when the app calls the schedule method.
+
+4. **Rollover (both platforms):** In the code that runs when a scheduled notification fires and schedules the next occurrence:
+   - Read the stored `rolloverIntervalMinutes` for that schedule.
+   - If present and > 0: next trigger = current trigger + that many minutes (using Calendar/date APIs that respect timezone/DST).
+   - Else: next trigger = current trigger + 24 hours (existing behavior).
+   - Persist the same interval on the new schedule record so the next rollover still uses it.
+
+5. **Boot recovery (both platforms):** In the path that runs after device reboot and reschedules from stored data:
+   - Load the stored `rolloverIntervalMinutes` with each schedule.
+   - When computing “next run time” for reschedule, use the same logic: if interval set, current trigger + that many minutes; else + 24 hours.
+   - Do not rely on in-memory state; always read from persisted storage so behavior is correct after restart.
+
+6. **Clearing the interval:** When the app calls `scheduleDailyNotification` without `rolloverIntervalMinutes` (e.g. user turned off “fast rollover” in the app), overwrite the stored schedule so the interval field is null/0. Subsequent rollovers and boot recovery then use 24 hours.
+
+7. **Tests:** Add or extend tests for: (a) rollover with 10 minutes, (b) boot recovery with stored 10-minute interval, (c) default 24h when parameter absent or cleared.

electron/package-lock.json

@@ -56,6 +56,7 @@
       "version": "6.0.2",
       "resolved": "https://registry.npmjs.org/@capacitor-community/sqlite/-/sqlite-6.0.2.tgz",
       "integrity": "sha512-sj+2SPLu7E/3dM3xxcWwfNomG+aQHuN96/EFGrOtp4Dv30/2y5oIPyi6hZGjQGjPc5GDNoTQwW7vxWNzybjuMg==",
+      "license": "MIT",
       "dependencies": {
         "jeep-sqlite": "^2.7.2"
       },
@@ -129,6 +130,7 @@
       "resolved": "https://registry.npmjs.org/@capacitor/core/-/core-6.2.1.tgz",
       "integrity": "sha512-urZwxa7hVE/BnA18oCFAdizXPse6fCKanQyEqpmz6cBJ2vObwMpyJDG5jBeoSsgocS9+Ax+9vb4ducWJn0y2qQ==",
       "license": "MIT",
+      "peer": true,
       "dependencies": {
         "tslib": "^2.1.0"
       }
@@ -1069,6 +1071,7 @@
       "integrity": "sha512-j3fVLgvTo527anyYyJOGTYJbG+vnnQYvE0m5mmkc1TK+nxAppkCLMIL0aZ4dblVCNoGShhm+kzE4ZUykBoMg4g==",
       "dev": true,
       "license": "MIT",
+      "peer": true,
       "dependencies": {
         "fast-deep-equal": "^3.1.1",
         "fast-json-stable-stringify": "^2.0.0",
@@ -2874,16 +2877,6 @@
       "integrity": "sha512-MSjYzcWNOA0ewAHpz0MxpYFvwg6yjy1NG3xteoqz644VCo/RPgnr1/GGt+ic3iJTzQ8Eu3TdM14SawnVUmGE6A==",
       "license": "MIT"
     },
-    "node_modules/encoding": {
-      "version": "0.1.13",
-      "resolved": "https://registry.npmjs.org/encoding/-/encoding-0.1.13.tgz",
-      "integrity": "sha512-ETBauow1T35Y/WZMkio9jiM0Z5xjHHmJ4XmjZOq1l/dXz3lr2sRn87nJy20RupqSh1F2m3HHPSp8ShIPQJrJ3A==",
-      "license": "MIT",
-      "optional": true,
-      "dependencies": {
-        "iconv-lite": "^0.6.2"
-      }
-    },
     "node_modules/end-of-stream": {
       "version": "1.4.5",
       "resolved": "https://registry.npmjs.org/end-of-stream/-/end-of-stream-1.4.5.tgz",

ios/App/App.xcodeproj/project.pbxproj

@@ -3,7 +3,7 @@
 	archiveVersion = 1;
 	classes = {
 	};
-	objectVersion = 70;
+	objectVersion = 56;
 	objects = {
 
 /* Begin PBXBuildFile section */
@@ -15,6 +15,7 @@
 		504EC3121FED79650016851F /* LaunchScreen.storyboard in Resources */ = {isa = PBXBuildFile; fileRef = 504EC3101FED79650016851F /* LaunchScreen.storyboard */; };
 		50B271D11FEDC1A000F3C39B /* public in Resources */ = {isa = PBXBuildFile; fileRef = 50B271D01FEDC1A000F3C39B /* public */; };
 		97EF2DC6FD76C3643D680B8D /* Pods_App.framework in Frameworks */ = {isa = PBXBuildFile; fileRef = 90DCAFB4D8948F7A50C13800 /* Pods_App.framework */; };
+		B7E1C4F82A9D3E506F1B2C8D /* TimeSafariNativeFetcher.swift in Sources */ = {isa = PBXBuildFile; fileRef = A3F8E2D91B4C5E60718293A4 /* TimeSafariNativeFetcher.swift */; };
 		C86585DF2ED456DE00824752 /* TimeSafariShareExtension.appex in Embed Foundation Extensions */ = {isa = PBXBuildFile; fileRef = C86585D52ED456DE00824752 /* TimeSafariShareExtension.appex */; settings = {ATTRIBUTES = (RemoveHeadersOnCopy, ); }; };
 		C8C56E142EE0474B00737D0E /* SharedImageUtility.swift in Sources */ = {isa = PBXBuildFile; fileRef = C8C56E132EE0474B00737D0E /* SharedImageUtility.swift */; };
 		C8C56E162EE064CB00737D0E /* SharedImagePlugin.swift in Sources */ = {isa = PBXBuildFile; fileRef = C8C56E152EE064CA00737D0E /* SharedImagePlugin.swift */; };
@@ -55,6 +56,7 @@
 		504EC3131FED79650016851F /* Info.plist */ = {isa = PBXFileReference; lastKnownFileType = text.plist.xml; path = Info.plist; sourceTree = "<group>"; };
 		50B271D01FEDC1A000F3C39B /* public */ = {isa = PBXFileReference; lastKnownFileType = folder; path = public; sourceTree = "<group>"; };
 		90DCAFB4D8948F7A50C13800 /* Pods_App.framework */ = {isa = PBXFileReference; explicitFileType = wrapper.framework; includeInIndex = 0; path = Pods_App.framework; sourceTree = BUILT_PRODUCTS_DIR; };
+		A3F8E2D91B4C5E60718293A4 /* TimeSafariNativeFetcher.swift */ = {isa = PBXFileReference; lastKnownFileType = sourcecode.swift; path = TimeSafariNativeFetcher.swift; sourceTree = "<group>"; };
 		C86585D52ED456DE00824752 /* TimeSafariShareExtension.appex */ = {isa = PBXFileReference; explicitFileType = "wrapper.app-extension"; includeInIndex = 0; path = TimeSafariShareExtension.appex; sourceTree = BUILT_PRODUCTS_DIR; };
 		C86585E52ED4577F00824752 /* App.entitlements */ = {isa = PBXFileReference; lastKnownFileType = text.plist.entitlements; path = App.entitlements; sourceTree = "<group>"; };
 		C8C56E132EE0474B00737D0E /* SharedImageUtility.swift */ = {isa = PBXFileReference; lastKnownFileType = sourcecode.swift; path = SharedImageUtility.swift; sourceTree = "<group>"; };
@@ -64,7 +66,7 @@
 /* End PBXFileReference section */
 
 /* Begin PBXFileSystemSynchronizedBuildFileExceptionSet section */
-		C86585E32ED456DE00824752 /* PBXFileSystemSynchronizedBuildFileExceptionSet */ = {
+		C86585E32ED456DE00824752 /* Exceptions for "TimeSafariShareExtension" folder in "TimeSafariShareExtension" target */ = {
 			isa = PBXFileSystemSynchronizedBuildFileExceptionSet;
 			membershipExceptions = (
 				Info.plist,
@@ -77,7 +79,7 @@
 		C86585D62ED456DE00824752 /* TimeSafariShareExtension */ = {
 			isa = PBXFileSystemSynchronizedRootGroup;
 			exceptions = (
-				C86585E32ED456DE00824752 /* PBXFileSystemSynchronizedBuildFileExceptionSet */,
+				C86585E32ED456DE00824752 /* Exceptions for "TimeSafariShareExtension" folder in "TimeSafariShareExtension" target */,
 			);
 			explicitFileTypes = {
 			};
@@ -140,6 +142,7 @@
 			children = (
 				C8C56E152EE064CA00737D0E /* SharedImagePlugin.swift */,
 				C8C56E132EE0474B00737D0E /* SharedImageUtility.swift */,
+				A3F8E2D91B4C5E60718293A4 /* TimeSafariNativeFetcher.swift */,
 				C86585E52ED4577F00824752 /* App.entitlements */,
 				50379B222058CBB4000EE86E /* capacitor.config.json */,
 				504EC3071FED79650016851F /* AppDelegate.swift */,
@@ -174,9 +177,9 @@
 				504EC3011FED79650016851F /* Frameworks */,
 				504EC3021FED79650016851F /* Resources */,
 				012076E8FFE4BF260A79B034 /* Fix Privacy Manifest */,
-				3525031ED1C96EF4CF6E9959 /* [CP] Embed Pods Frameworks */,
 				96A7EF592DF3366D00084D51 /* Fix Privacy Manifest */,
 				C86585E02ED456DE00824752 /* Embed Foundation Extensions */,
+				3FE25897CF40A571D4AC2ACE /* [CP] Copy Pods Resources */,
 			);
 			buildRules = (
 			);
@@ -204,8 +207,6 @@
 				C86585D62ED456DE00824752 /* TimeSafariShareExtension */,
 			);
 			name = TimeSafariShareExtension;
-			packageProductDependencies = (
-			);
 			productName = TimeSafariShareExtension;
 			productReference = C86585D52ED456DE00824752 /* TimeSafariShareExtension.appex */;
 			productType = "com.apple.product-type.app-extension";
@@ -293,19 +294,19 @@
 			shellScript = "\"${PROJECT_DIR}/app_privacy_manifest_fixer/fixer.sh\" \n";
 			showEnvVarsInLog = 0;
 		};
-		3525031ED1C96EF4CF6E9959 /* [CP] Embed Pods Frameworks */ = {
+		3FE25897CF40A571D4AC2ACE /* [CP] Copy Pods Resources */ = {
 			isa = PBXShellScriptBuildPhase;
 			buildActionMask = 2147483647;
 			files = (
 			);
 			inputPaths = (
 			);
-			name = "[CP] Embed Pods Frameworks";
+			name = "[CP] Copy Pods Resources";
 			outputPaths = (
 			);
 			runOnlyForDeploymentPostprocessing = 0;
 			shellPath = /bin/sh;
-			shellScript = "\"${PODS_ROOT}/Target Support Files/Pods-App/Pods-App-frameworks.sh\"\n";
+			shellScript = "\"${PODS_ROOT}/Target Support Files/Pods-App/Pods-App-resources.sh\"\n";
 			showEnvVarsInLog = 0;
 		};
 		92977BEA1068CC097A57FC77 /* [CP] Check Pods Manifest.lock */ = {
@@ -359,6 +360,7 @@
 				C8C56E162EE064CB00737D0E /* SharedImagePlugin.swift in Sources */,
 				504EC3081FED79650016851F /* AppDelegate.swift in Sources */,
 				C8C56E142EE0474B00737D0E /* SharedImageUtility.swift in Sources */,
+				B7E1C4F82A9D3E506F1B2C8D /* TimeSafariNativeFetcher.swift in Sources */,
 			);
 			runOnlyForDeploymentPostprocessing = 0;
 		};
@@ -522,9 +524,10 @@
 			baseConfigurationReference = EAEC6436E595F7CD3A1C9E96 /* Pods-App.debug.xcconfig */;
 			buildSettings = {
 				ASSETCATALOG_COMPILER_APPICON_NAME = AppIcon;
+				CLANG_ENABLE_MODULES = YES;
 				CODE_SIGN_ENTITLEMENTS = App/App.entitlements;
 				CODE_SIGN_STYLE = Automatic;
-				CURRENT_PROJECT_VERSION = 50;
+				CURRENT_PROJECT_VERSION = 65;
 				DEVELOPMENT_TEAM = GM3FS5JQPH;
 				ENABLE_APP_SANDBOX = NO;
 				ENABLE_USER_SCRIPT_SANDBOXING = NO;
@@ -534,7 +537,7 @@
 					"$(inherited)",
 					"@executable_path/Frameworks",
 				);
-				MARKETING_VERSION = 1.1.5;
+				MARKETING_VERSION = 1.3.8;
 				OTHER_SWIFT_FLAGS = "$(inherited) \"-D\" \"COCOAPODS\" \"-DDEBUG\"";
 				PRODUCT_BUNDLE_IDENTIFIER = app.timesafari;
 				PRODUCT_NAME = "$(TARGET_NAME)";
@@ -550,9 +553,10 @@
 			baseConfigurationReference = E2E9297D5D02C549106C77F9 /* Pods-App.release.xcconfig */;
 			buildSettings = {
 				ASSETCATALOG_COMPILER_APPICON_NAME = AppIcon;
+				CLANG_ENABLE_MODULES = YES;
 				CODE_SIGN_ENTITLEMENTS = App/App.entitlements;
 				CODE_SIGN_STYLE = Automatic;
-				CURRENT_PROJECT_VERSION = 50;
+				CURRENT_PROJECT_VERSION = 65;
 				DEVELOPMENT_TEAM = GM3FS5JQPH;
 				ENABLE_APP_SANDBOX = NO;
 				ENABLE_USER_SCRIPT_SANDBOXING = NO;
@@ -562,7 +566,7 @@
 					"$(inherited)",
 					"@executable_path/Frameworks",
 				);
-				MARKETING_VERSION = 1.1.5;
+				MARKETING_VERSION = 1.3.8;
 				PRODUCT_BUNDLE_IDENTIFIER = app.timesafari;
 				PRODUCT_NAME = "$(TARGET_NAME)";
 				SWIFT_ACTIVE_COMPILATION_CONDITIONS = "";
@@ -580,7 +584,7 @@
 				CLANG_ENABLE_OBJC_WEAK = YES;
 				CODE_SIGN_ENTITLEMENTS = TimeSafariShareExtension/TimeSafariShareExtension.entitlements;
 				CODE_SIGN_STYLE = Automatic;
-				CURRENT_PROJECT_VERSION = 50;
+				CURRENT_PROJECT_VERSION = 65;
 				DEVELOPMENT_TEAM = GM3FS5JQPH;
 				GCC_C_LANGUAGE_STANDARD = gnu17;
 				GENERATE_INFOPLIST_FILE = YES;
@@ -594,7 +598,7 @@
 					"@executable_path/../../Frameworks",
 				);
 				LOCALIZATION_PREFERS_STRING_CATALOGS = YES;
-				MARKETING_VERSION = 1.1.5;
+				MARKETING_VERSION = 1.3.8;
 				MTL_ENABLE_DEBUG_INFO = INCLUDE_SOURCE;
 				MTL_FAST_MATH = YES;
 				PRODUCT_BUNDLE_IDENTIFIER = app.timesafari.TimeSafariShareExtension;
@@ -618,7 +622,7 @@
 				CLANG_ENABLE_OBJC_WEAK = YES;
 				CODE_SIGN_ENTITLEMENTS = TimeSafariShareExtension/TimeSafariShareExtension.entitlements;
 				CODE_SIGN_STYLE = Automatic;
-				CURRENT_PROJECT_VERSION = 50;
+				CURRENT_PROJECT_VERSION = 65;
 				DEVELOPMENT_TEAM = GM3FS5JQPH;
 				GCC_C_LANGUAGE_STANDARD = gnu17;
 				GENERATE_INFOPLIST_FILE = YES;
@@ -632,7 +636,7 @@
 					"@executable_path/../../Frameworks",
 				);
 				LOCALIZATION_PREFERS_STRING_CATALOGS = YES;
-				MARKETING_VERSION = 1.1.5;
+				MARKETING_VERSION = 1.3.8;
 				MTL_FAST_MATH = YES;
 				PRODUCT_BUNDLE_IDENTIFIER = app.timesafari.TimeSafariShareExtension;
 				PRODUCT_NAME = "$(TARGET_NAME)";

ios/App/App/AppDelegate.swift

@@ -1,13 +1,21 @@
 import UIKit
 import Capacitor
 import CapacitorCommunitySqlite
+import TimesafariDailyNotificationPlugin
+import UserNotifications
 
 @UIApplicationMain
-class AppDelegate: UIResponder, UIApplicationDelegate {
+class AppDelegate: UIResponder, UIApplicationDelegate, UNUserNotificationCenterDelegate {
 
     var window: UIWindow?
 
     func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool {
+        // New Activity / dual schedule: plugin requires a registered native fetcher before configureNativeFetcher (parity with Android setNativeFetcher).
+        DailyNotificationPlugin.registerNativeFetcher(TimeSafariNativeFetcher.shared)
+
+        // Set notification center delegate so notifications show in foreground and rollover is triggered
+        UNUserNotificationCenter.current().delegate = self
+
         // Initialize SQLite
         //let sqlite = SQLite()
         //sqlite.initialize()
@@ -73,9 +81,44 @@ class AppDelegate: UIResponder, UIApplicationDelegate {
     func applicationDidBecomeActive(_ application: UIApplication) {
         // Restart any tasks that were paused (or not yet started) while the application was inactive. If the application was previously in the background, optionally refresh the user interface.
         
+        // Re-set notification delegate when app becomes active (in case Capacitor resets it)
+        UNUserNotificationCenter.current().delegate = self
+
         // Check for shared image from Share Extension when app becomes active
         checkForSharedImageOnActivation()
     }
+
+    // MARK: - UNUserNotificationCenterDelegate
+
+    /// Show notifications when app is in foreground and post DailyNotificationDelivered for rollover.
+    func userNotificationCenter(_ center: UNUserNotificationCenter, willPresent notification: UNNotification, withCompletionHandler completionHandler: @escaping (UNNotificationPresentationOptions) -> Void) {
+        let userInfo = notification.request.content.userInfo
+        if let notificationId = userInfo["notification_id"] as? String {
+            let scheduledTime: Int64? = {
+                if let v = userInfo["scheduled_time"] as? Int64 { return v }
+                if let n = userInfo["scheduled_time"] as? NSNumber { return n.int64Value }
+                if let i = userInfo["scheduled_time"] as? Int { return Int64(i) }
+                return nil
+            }()
+            if let scheduledTime = scheduledTime {
+                NotificationCenter.default.post(
+                    name: NSNotification.Name("DailyNotificationDelivered"),
+                    object: nil,
+                    userInfo: ["notification_id": notificationId, "scheduled_time": scheduledTime]
+                )
+            }
+        }
+        if #available(iOS 14.0, *) {
+            completionHandler([.banner, .sound, .badge])
+        } else {
+            completionHandler([.alert, .sound, .badge])
+        }
+    }
+
+    /// Handle notification tap/interaction.
+    func userNotificationCenter(_ center: UNUserNotificationCenter, didReceive response: UNNotificationResponse, withCompletionHandler completionHandler: @escaping () -> Void) {
+        completionHandler()
+    }
     
     /**
      * Check for shared image when app launches or becomes active

ios/App/App/Info.plist

@@ -2,6 +2,13 @@
 <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
 <plist version="1.0">
 <dict>
+	<key>BGTaskSchedulerPermittedIdentifiers</key>
+	<array>
+		<string>org.timesafari.dailynotification.fetch</string>
+		<string>org.timesafari.dailynotification.notify</string>
+		<string>org.timesafari.dailynotification.content-fetch</string>
+		<string>org.timesafari.dailynotification.notification-delivery</string>
+	</array>
 	<key>CFBundleDevelopmentRegion</key>
 	<string>en</string>
 	<key>CFBundleDisplayName</key>
@@ -18,6 +25,17 @@
 	<string>APPL</string>
 	<key>CFBundleShortVersionString</key>
 	<string>$(MARKETING_VERSION)</string>
+	<key>CFBundleURLTypes</key>
+	<array>
+		<dict>
+			<key>CFBundleURLName</key>
+			<string>app.timesafari</string>
+			<key>CFBundleURLSchemes</key>
+			<array>
+				<string>timesafari</string>
+			</array>
+		</dict>
+	</array>
 	<key>CFBundleVersion</key>
 	<string>$(CURRENT_PROJECT_VERSION)</string>
 	<key>LSRequiresIPhoneOS</key>
@@ -26,6 +44,13 @@
 	<string>Time Safari allows you to take photos, and also scan QR codes from contacts.</string>
 	<key>NSPhotoLibraryUsageDescription</key>
 	<string>Time Safari allows you to upload photos.</string>
+	<key>NSUserNotificationAlertStyle</key>
+	<string>alert</string>
+	<key>UIBackgroundModes</key>
+	<array>
+		<string>fetch</string>
+		<string>processing</string>
+	</array>
 	<key>UILaunchStoryboardName</key>
 	<string>LaunchScreen</string>
 	<key>UIMainStoryboardFile</key>
@@ -47,16 +72,5 @@
 	</array>
 	<key>UIViewControllerBasedStatusBarAppearance</key>
 	<true/>
-	<key>CFBundleURLTypes</key>
-	<array>
-		<dict>
-			<key>CFBundleURLName</key>
-			<string>app.timesafari</string>
-			<key>CFBundleURLSchemes</key>
-			<array>
-				<string>timesafari</string>
-			</array>
-		</dict>
-	</array>
 </dict>
 </plist>

ios/App/App/TimeSafariNativeFetcher.swift

@@ -0,0 +1,215 @@
+import Foundation
+import TimesafariDailyNotificationPlugin
+
+/// Native content fetcher for API-driven New Activity notifications on iOS.
+/// Mirrors `TimeSafariNativeFetcher.java` (POST `plansLastUpdatedBetween`, starred plans, JWT pool, pagination).
+final class TimeSafariNativeFetcher: NativeNotificationContentFetcher {
+    static let shared = TimeSafariNativeFetcher()
+
+    private let endpoint = "/api/v2/report/plansLastUpdatedBetween"
+    private let readTimeoutSec: TimeInterval = 15
+    private let maxRetries = 3
+    private let retryDelayMs = 1_000
+
+    /// Matches plugin `updateStarredPlans` storage (`DailyNotificationPlugin.swift`).
+    private let prefsStarredKey = "daily_notification_timesafari.starredPlanIds"
+    /// Matches Java `TimeSafariNativeFetcher` prefs namespace `daily_notification_timesafari` + `last_acked_jwt_id`.
+    private let prefsLastAckedKey = "daily_notification_timesafari.last_acked_jwt_id"
+
+    private var apiBaseUrl: String?
+    private var activeDid: String?
+    private var jwtToken: String?
+    private var jwtTokenPool: [String]?
+
+    private init() {}
+
+    func configure(apiBaseUrl: String, activeDid: String, jwtToken: String, jwtTokenPool: [String]?) {
+        self.apiBaseUrl = apiBaseUrl.trimmingCharacters(in: .whitespacesAndNewlines).replacingOccurrences(
+            of: "/$",
+            with: "",
+            options: .regularExpression
+        )
+        self.activeDid = activeDid
+        self.jwtToken = jwtToken
+        self.jwtTokenPool = (jwtTokenPool?.isEmpty == false) ? jwtTokenPool : nil
+    }
+
+    func fetchContent(context: FetchContext) async throws -> [NotificationContent] {
+        try await fetchContentWithRetry(context: context, retryCount: 0)
+    }
+
+    /// One pool entry per UTC day (epoch day mod pool size); else primary `jwtToken` — same as Java.
+    private func selectBearerTokenForRequest() -> String? {
+        guard let pool = jwtTokenPool, !pool.isEmpty else { return jwtToken }
+        let epochDay = Int64(Date().timeIntervalSince1970 * 1000) / (24 * 60 * 60 * 1000)
+        let idx = Int(epochDay) % pool.count
+        let t = pool[idx]
+        if t.isEmpty { return jwtToken }
+        return t
+    }
+
+    private func fetchContentWithRetry(context: FetchContext, retryCount: Int) async throws -> [NotificationContent] {
+        guard let base = apiBaseUrl, !base.isEmpty,
+              activeDid != nil,
+              let bearer = selectBearerTokenForRequest(), !bearer.isEmpty
+        else {
+            NSLog("[TimeSafariNativeFetcher] Not configured; call configureNativeFetcher from JS first.")
+            return []
+        }
+
+        guard let url = URL(string: base + endpoint) else {
+            return []
+        }
+
+        var request = URLRequest(url: url)
+        request.httpMethod = "POST"
+        request.setValue("application/json", forHTTPHeaderField: "Content-Type")
+        request.setValue("Bearer \(bearer)", forHTTPHeaderField: "Authorization")
+        request.timeoutInterval = readTimeoutSec
+
+        let planIds = getStarredPlanIds()
+        var afterId = getLastAcknowledgedJwtId() ?? "0"
+        if afterId.isEmpty { afterId = "0" }
+
+        let body: [String: Any] = [
+            "planIds": planIds,
+            "afterId": afterId,
+        ]
+        request.httpBody = try JSONSerialization.data(withJSONObject: body)
+
+        NSLog(
+            "[TimeSafariNativeFetcher] POST \(endpoint) planCount=\(planIds.count) afterId=\(afterId.prefix(12))…"
+        )
+
+        let config = URLSessionConfiguration.ephemeral
+        config.timeoutIntervalForRequest = readTimeoutSec
+        config.timeoutIntervalForResource = readTimeoutSec
+        let session = URLSession(configuration: config)
+
+        do {
+            let (data, response) = try await session.data(for: request)
+            guard let http = response as? HTTPURLResponse else {
+                return []
+            }
+
+            if http.statusCode == 200 {
+                let bodyStr = String(data: data, encoding: .utf8) ?? ""
+                let contents = parseApiResponse(responseBody: bodyStr, context: context)
+                if !contents.isEmpty {
+                    updateLastAckedJwtIdFromResponse(responseBody: bodyStr)
+                }
+                return contents
+            }
+
+            if retryCount < maxRetries && (http.statusCode >= 500 || http.statusCode == 429) {
+                let delayMs = retryDelayMs * (1 << retryCount)
+                try await Task.sleep(nanoseconds: UInt64(delayMs) * 1_000_000)
+                return try await fetchContentWithRetry(context: context, retryCount: retryCount + 1)
+            }
+
+            NSLog("[TimeSafariNativeFetcher] API error \(http.statusCode)")
+            return []
+        } catch {
+            NSLog("[TimeSafariNativeFetcher] Fetch failed: \(error.localizedDescription)")
+            if retryCount < maxRetries {
+                let delayMs = retryDelayMs * (1 << retryCount)
+                try await Task.sleep(nanoseconds: UInt64(delayMs) * 1_000_000)
+                return try await fetchContentWithRetry(context: context, retryCount: retryCount + 1)
+            }
+            return []
+        }
+    }
+
+    private func getStarredPlanIds() -> [String] {
+        guard let jsonStr = UserDefaults.standard.string(forKey: prefsStarredKey),
+              !jsonStr.isEmpty, jsonStr != "[]",
+              let data = jsonStr.data(using: .utf8),
+              let arr = try? JSONSerialization.jsonObject(with: data) as? [Any]
+        else {
+            return []
+        }
+        return arr.compactMap { $0 as? String }
+    }
+
+    private func getLastAcknowledgedJwtId() -> String? {
+        let s = UserDefaults.standard.string(forKey: prefsLastAckedKey)
+        return (s?.isEmpty == false) ? s : nil
+    }
+
+    private func updateLastAckedJwtIdFromResponse(responseBody: String) {
+        guard let data = responseBody.data(using: .utf8),
+              let root = try? JSONSerialization.jsonObject(with: data) as? [String: Any],
+              let dataArray = root["data"] as? [[String: Any]], !dataArray.isEmpty
+        else { return }
+
+        let lastItem = dataArray[dataArray.count - 1]
+        var jwtId: String?
+        if let j = lastItem["jwtId"] as? String {
+            jwtId = j
+        } else if let plan = lastItem["plan"] as? [String: Any], let j = plan["jwtId"] as? String {
+            jwtId = j
+        }
+        if let jwtId = jwtId, !jwtId.isEmpty {
+            UserDefaults.standard.set(jwtId, forKey: prefsLastAckedKey)
+        }
+    }
+
+    private func extractProjectDisplayTitle(_ item: [String: Any]) -> String {
+        if let plan = item["plan"] as? [String: Any],
+           let name = plan["name"] as? String,
+           !name.trimmingCharacters(in: .whitespacesAndNewlines).isEmpty {
+            return name.trimmingCharacters(in: .whitespacesAndNewlines)
+        }
+        return "Unnamed Project"
+    }
+
+    private func extractJwtIdFromItem(_ item: [String: Any]) -> String? {
+        if let plan = item["plan"] as? [String: Any], let j = plan["jwtId"] as? String, !j.isEmpty {
+            return j
+        }
+        if let j = item["jwtId"] as? String, !j.isEmpty { return j }
+        return nil
+    }
+
+    private func parseApiResponse(responseBody: String, context: FetchContext) -> [NotificationContent] {
+        guard let data = responseBody.data(using: .utf8),
+              let root = try? JSONSerialization.jsonObject(with: data) as? [String: Any],
+              let dataArray = root["data"] as? [[String: Any]], !dataArray.isEmpty
+        else {
+            return []
+        }
+
+        let firstItem = dataArray[0]
+        let firstTitle = extractProjectDisplayTitle(firstItem)
+        let jwtId = extractJwtIdFromItem(firstItem)
+        let nowMs = Int64(Date().timeIntervalSince1970 * 1000)
+        let scheduledMs: Int64 = context.scheduledTimeMillis ?? (nowMs + 3_600_000)
+
+        let n = dataArray.count
+        let quotedFirst = "\u{201C}\(firstTitle)\u{201D}"
+        let title: String
+        let body: String
+        if n == 1 {
+            title = "Starred Project Update"
+            body = "\(quotedFirst) has been updated."
+        } else {
+            title = "Starred Project Updates"
+            let more = n - 1
+            body = "\(quotedFirst) + \(more) more have been updated."
+        }
+
+        let id = "endorser_\(jwtId ?? "batch_\(nowMs)")"
+        return [
+            NotificationContent(
+                id: id,
+                title: title,
+                body: body,
+                scheduledTime: scheduledMs,
+                fetchedAt: nowMs,
+                url: apiBaseUrl,
+                payload: nil,
+                etag: nil
+            ),
+        ]
+    }
+}

ios/App/Podfile

@@ -1,7 +1,8 @@
 require_relative '../../node_modules/@capacitor/ios/scripts/pods_helpers'
 
 platform :ios, '13.0'
-use_frameworks!
+# Static linkage helps isolate SQLCipher from Apple's system SQLite module/headers.
+use_frameworks! :linkage => :static
 
 # workaround to avoid Xcode caching of Pods that requires
 # Product -> Clean Build Folder after new Cordova plugins installed
@@ -20,6 +21,7 @@ def capacitor_pods
   pod 'CapacitorShare', :path => '../../node_modules/@capacitor/share'
   pod 'CapacitorStatusBar', :path => '../../node_modules/@capacitor/status-bar'
   pod 'CapawesomeCapacitorFilePicker', :path => '../../node_modules/@capawesome/capacitor-file-picker'
+  pod 'TimesafariDailyNotificationPlugin', :path => '../../node_modules/@timesafari/daily-notification-plugin'
 end
 
 target 'App' do
@@ -27,11 +29,92 @@ target 'App' do
   # Add your Pods here
 end
 
+def merge_sqlite_omit_load_extension_definition(config)
+  defs = config.build_settings['GCC_PREPROCESSOR_DEFINITIONS']
+  if defs.nil?
+    config.build_settings['GCC_PREPROCESSOR_DEFINITIONS'] = ['$(inherited)', 'SQLITE_OMIT_LOAD_EXTENSION']
+  elsif defs.is_a?(Array)
+    unless defs.any? { |d| d.to_s.include?('SQLITE_OMIT_LOAD_EXTENSION') }
+      config.build_settings['GCC_PREPROCESSOR_DEFINITIONS'] = defs + ['SQLITE_OMIT_LOAD_EXTENSION']
+    end
+  else
+    s = defs.to_s
+    unless s.include?('SQLITE_OMIT_LOAD_EXTENSION')
+      config.build_settings['GCC_PREPROCESSOR_DEFINITIONS'] = "#{s} SQLITE_OMIT_LOAD_EXTENSION".squeeze(' ').strip
+    end
+  end
+end
+
+def strip_system_sqlite_from_pod_config(config)
+  bad_header = lambda do |path|
+    p = path.to_s
+    p.include?('/usr/include') || p.include?('/usr/local/include')
+  end
+  %w[HEADER_SEARCH_PATHS USER_HEADER_SEARCH_PATHS].each do |key|
+    paths = config.build_settings[key]
+    next unless paths
+    if paths.is_a?(Array)
+      config.build_settings[key] = paths.reject(&bad_header)
+    else
+      kept = paths.to_s.split(/\s+/).reject(&bad_header)
+      config.build_settings[key] = kept.join(' ')
+    end
+  end
+  %w[OTHER_LDFLAGS OTHER_LIBTOOLFLAGS].each do |key|
+    val = config.build_settings[key]
+    next unless val
+    if val.is_a?(Array)
+      config.build_settings[key] = val.reject do |x|
+        s = x.to_s
+        s.match?(/libsqlite3\.tbd/) || s == '-l"sqlite3"' || s.match?(/-l\s*sqlite3\b/)
+      end
+    else
+      s = val.to_s.gsub(/\s*-l"sqlite3"\s+/, ' ')
+           .gsub(/\s*-l\s*sqlite3\b/, ' ')
+           .gsub(/[^\s]*libsqlite3\.tbd[^\s]*/, ' ')
+      config.build_settings[key] = s.squeeze(' ').strip
+    end
+  end
+end
+
 post_install do |installer|
   assertDeploymentTarget(installer)
   installer.pods_project.targets.each do |target|
     target.build_configurations.each do |config|
       config.build_settings['EXCLUDED_ARCHS[sdk=iphonesimulator*]'] = 'arm64'
+      config.build_settings['CLANG_ALLOW_NON_MODULAR_INCLUDES_IN_FRAMEWORK_MODULES'] = 'YES'
+      merge_sqlite_omit_load_extension_definition(config)
+      strip_system_sqlite_from_pod_config(config)
     end
   end
 end
+
+# Aggregate Pods-App xcconfigs merge -l"sqlite3" from dependencies; that pulls in Apple's
+# libsqlite3 alongside SQLCipher. Strip it after CocoaPods writes the files (post_install is too early).
+# Also strip SQLCipher header-guard macros leaked into GCC_PREPROCESSOR_DEFINITIONS: Swift explicit
+# modules build the SDK SQLite3.modulemap PCM with the same -D flags; _SQLITE3_H_=1 empties sqlite3.h
+# and breaks sqlite3ext.h (unknown sqlite3_* types).
+def strip_aggregate_pods_app_xcconfig(contents)
+  # Unlink system libsqlite3 (SQLCipher is the only SQLite).
+  patched = contents.gsub(/\s+-l"sqlite3"\s+/, ' ')
+                    .gsub(/\s+-lsqlite3\b/, ' ')
+  # SQLCipher leaks sqlite3*.h guard macros into GCC_PREPROCESSOR_DEFINITIONS; Swift explicit
+  # modules must not inherit them when building the SDK SQLite3 module.
+  %w[_SQLITE3_H_=1 _FTS5_H=1 _SQLITE3RTREE_H_=1].each do |macro|
+    escaped = Regexp.escape(macro)
+    patched.gsub!(/(?:^|\s)-D#{escaped}(?=\s|$)/, ' ')
+    patched.gsub!(/(?:^|\s)#{escaped}(?=\s|$)/, ' ')
+  end
+  patched.gsub(/[ \t]+/, ' ')
+end
+
+post_integrate do |installer|
+  support = File.join(installer.sandbox.root, 'Target Support Files', 'Pods-App')
+  %w[Pods-App.debug.xcconfig Pods-App.release.xcconfig].each do |name|
+    path = File.join(support, name)
+    next unless File.exist?(path)
+    contents = File.read(path)
+    patched = strip_aggregate_pods_app_xcconfig(contents)
+    File.write(path, patched) if patched != contents
+  end
+end

ios/App/Podfile.lock

@@ -81,12 +81,14 @@ PODS:
   - nanopb/decode (2.30910.0)
   - nanopb/encode (2.30910.0)
   - PromisesObjC (2.4.0)
-  - SQLCipher (4.9.0):
-    - SQLCipher/standard (= 4.9.0)
-  - SQLCipher/common (4.9.0)
-  - SQLCipher/standard (4.9.0):
+  - SQLCipher (4.10.0):
+    - SQLCipher/standard (= 4.10.0)
+  - SQLCipher/common (4.10.0)
+  - SQLCipher/standard (4.10.0):
     - SQLCipher/common
-  - ZIPFoundation (0.9.19)
+  - TimesafariDailyNotificationPlugin (3.0.0):
+    - Capacitor
+  - ZIPFoundation (0.9.20)
 
 DEPENDENCIES:
   - "Capacitor (from `../../node_modules/@capacitor/ios`)"
@@ -100,6 +102,7 @@ DEPENDENCIES:
   - "CapacitorShare (from `../../node_modules/@capacitor/share`)"
   - "CapacitorStatusBar (from `../../node_modules/@capacitor/status-bar`)"
   - "CapawesomeCapacitorFilePicker (from `../../node_modules/@capawesome/capacitor-file-picker`)"
+  - "TimesafariDailyNotificationPlugin (from `../../node_modules/@timesafari/daily-notification-plugin`)"
 
 SPEC REPOS:
   trunk:
@@ -141,6 +144,8 @@ EXTERNAL SOURCES:
     :path: "../../node_modules/@capacitor/status-bar"
   CapawesomeCapacitorFilePicker:
     :path: "../../node_modules/@capawesome/capacitor-file-picker"
+  TimesafariDailyNotificationPlugin:
+    :path: "../../node_modules/@timesafari/daily-notification-plugin"
 
 SPEC CHECKSUMS:
   Capacitor: c95400d761e376be9da6be5a05f226c0e865cebf
@@ -166,9 +171,10 @@ SPEC CHECKSUMS:
   MLKitVision: 90922bca854014a856f8b649d1f1f04f63fd9c79
   nanopb: 438bc412db1928dac798aa6fd75726007be04262
   PromisesObjC: f5707f49cb48b9636751c5b2e7d227e43fba9f47
-  SQLCipher: 31878d8ebd27e5c96db0b7cb695c96e9f8ad77da
-  ZIPFoundation: b8c29ea7ae353b309bc810586181fd073cb3312c
+  SQLCipher: eb79c64049cb002b4e9fcb30edb7979bf4706dfc
+  TimesafariDailyNotificationPlugin: 4a344236630d9209234d46a417d351ac9c27e1b0
+  ZIPFoundation: dfd3d681c4053ff7e2f7350bc4e53b5dba3f5351
 
-PODFILE CHECKSUM: 5fa870b031c7c4e0733e2f96deaf81866c75ff7d
+PODFILE CHECKSUM: bf247ff01f83709ef1010f328f5fb4ab5370cb41
 
 COCOAPODS: 1.16.2

package.json

@@ -1,9 +1,9 @@
 {
   "name": "timesafari",
-  "version": "1.1.5",
-  "description": "Time Safari Application",
+  "version": "1.4.1-beta",
+  "description": "Gift Economies Application",
   "author": {
-    "name": "Time Safari Team"
+    "name": "Gift Economies Team"
   },
   "scripts": {
     "lint": "eslint --ext .js,.ts,.vue --ignore-path .gitignore src",
@@ -138,7 +138,7 @@
   },
   "dependencies": {
     "@capacitor-community/electron": "^5.0.1",
-    "@capacitor-community/sqlite": "6.0.2",
+    "@capacitor-community/sqlite": "^6.0.2",
     "@capacitor-mlkit/barcode-scanning": "^6.0.0",
     "@capacitor/android": "^6.2.0",
     "@capacitor/app": "^6.0.0",
@@ -161,12 +161,12 @@
     "@fortawesome/free-solid-svg-icons": "^6.5.1",
     "@fortawesome/vue-fontawesome": "^3.0.6",
     "@jlongster/sql.js": "^1.6.7",
-    "@nostr/tools": "npm:@jsr/nostr__tools@^2.15.0",
     "@peculiar/asn1-ecc": "^2.3.8",
     "@peculiar/asn1-schema": "^2.3.8",
     "@pvermeer/dexie-encrypted-addon": "^3.0.0",
     "@simplewebauthn/browser": "^10.0.0",
     "@simplewebauthn/server": "^10.0.0",
+    "@timesafari/daily-notification-plugin": "git+https://gitea.anomalistdesign.com/trent_larson/daily-notification-plugin.git#master",
     "@tweenjs/tween.js": "^21.1.1",
     "@types/qrcode": "^1.5.5",
     "@veramo/core": "^5.6.0",
@@ -189,6 +189,7 @@
     "dexie-export-import": "^4.1.4",
     "did-jwt": "^7.4.7",
     "did-resolver": "^4.1.0",
+    "diff": "^8.0.2",
     "dotenv": "^16.0.3",
     "electron-builder": "^26.0.12",
     "ethereum-cryptography": "^2.1.3",
@@ -202,9 +203,10 @@
     "lru-cache": "^10.2.0",
     "luxon": "^3.4.4",
     "merkletreejs": "^0.3.11",
+    "nostr-tools": "^2.15.0",
     "notiwind": "^2.0.2",
     "papaparse": "^5.4.1",
-    "pina": "^0.20.2204228",
+    "pinia": "^2.1.7",
     "pinia-plugin-persistedstate": "^3.2.1",
     "qr-code-generator-vue3": "^1.4.21",
     "qrcode": "^1.5.4",
@@ -233,6 +235,7 @@
     "@commitlint/cli": "^18.6.1",
     "@commitlint/config-conventional": "^18.6.2",
     "@playwright/test": "^1.54.2",
+    "@tailwindcss/typography": "^0.5.19",
     "@types/dom-webcodecs": "^0.1.7",
     "@types/jest": "^30.0.0",
     "@types/js-yaml": "^4.0.9",

playwright.config-local.ts

@@ -57,7 +57,7 @@ export default defineConfig({
     // },
     {
       name: 'chromium',
-      testMatch: /^(?!.*\/(35-record-gift-from-image-share|40-add-contact)\.spec\.ts).+\.spec\.ts$/,
+      testMatch: /^(?!.*\/(35-record-gift-from-image-share)\.spec\.ts).+\.spec\.ts$/,
       use: {
         ...devices['Desktop Chrome'],
         permissions: ["clipboard-read"],
@@ -65,7 +65,7 @@ export default defineConfig({
     },
     {
       name: 'firefox',
-      testMatch: /^(?!.*\/(35-record-gift-from-image-share|40-add-contact)\.spec\.ts).+\.spec\.ts$/,
+      testMatch: /^(?!.*\/(35-record-gift-from-image-share)\.spec\.ts).+\.spec\.ts$/,
       use: { ...devices['Desktop Firefox'] },
     },
 

scripts/auto-run.sh

@@ -204,7 +204,7 @@ run_android() {
         safe_execute "Launching app" "adb -s $device_id shell am start -n app.timesafari.app/app.timesafari.MainActivity"
     else
         log_info "Launching emulator and installing app"
-        safe_execute "Launching app" "npx cap run android"
+        safe_execute "Launching app" "npx cap run android --no-sync"
     fi
 }
 

scripts/build-android.sh

@@ -75,6 +75,146 @@ validate_dependencies() {
     log_success "All critical dependencies validated successfully"
 }
 
+# Function to detect and set JAVA_HOME for Android builds
+setup_java_home() {
+    log_info "Setting up Java environment..."
+    
+    # If JAVA_HOME is already set and valid, use it
+    if [ -n "$JAVA_HOME" ] && [ -x "$JAVA_HOME/bin/java" ]; then
+        log_debug "Using existing JAVA_HOME: $JAVA_HOME"
+        export JAVA_HOME
+        return 0
+    fi
+    
+    # Try to find Java in Android Studio's bundled JBR
+    local android_studio_jbr="/Applications/Android Studio.app/Contents/jbr/Contents/Home"
+    if [ -d "$android_studio_jbr" ] && [ -x "$android_studio_jbr/bin/java" ]; then
+        export JAVA_HOME="$android_studio_jbr"
+        log_info "Found Java in Android Studio: $JAVA_HOME"
+        if [ -x "$JAVA_HOME/bin/java" ]; then
+            log_debug "Java version: $(\"$JAVA_HOME/bin/java\" -version 2>&1 | head -1 || echo 'Unable to get version')"
+        fi
+        return 0
+    fi
+    
+    # Try alternative Android Studio location (older versions)
+    local android_studio_jre="/Applications/Android Studio.app/Contents/jre/Contents/Home"
+    if [ -d "$android_studio_jre" ] && [ -x "$android_studio_jre/bin/java" ]; then
+        export JAVA_HOME="$android_studio_jre"
+        log_info "Found Java in Android Studio (legacy): $JAVA_HOME"
+        log_debug "Java version: $(\"$JAVA_HOME/bin/java\" -version 2>&1 | head -1)"
+        return 0
+    fi
+    
+    # Try to use /usr/libexec/java_home on macOS
+    if [ "$(uname)" = "Darwin" ] && command -v /usr/libexec/java_home >/dev/null 2>&1; then
+        local java_home_output=$(/usr/libexec/java_home 2>/dev/null)
+        if [ -n "$java_home_output" ] && [ -x "$java_home_output/bin/java" ]; then
+            export JAVA_HOME="$java_home_output"
+            log_info "Found Java via java_home utility: $JAVA_HOME"
+            log_debug "Java version: $(\"$JAVA_HOME/bin/java\" -version 2>&1 | head -1)"
+            return 0
+        fi
+    fi
+    
+    # Try to find java in PATH
+    if command -v java >/dev/null 2>&1; then
+        local java_path=$(command -v java)
+        # Resolve symlinks to find actual Java home (portable approach)
+        local java_real="$java_path"
+        # Try different methods to resolve symlinks
+        if [ -L "$java_path" ]; then
+            if command -v readlink >/dev/null 2>&1; then
+                java_real=$(readlink "$java_path" 2>/dev/null || echo "$java_path")
+            elif command -v realpath >/dev/null 2>&1; then
+                java_real=$(realpath "$java_path" 2>/dev/null || echo "$java_path")
+            fi
+        fi
+        local java_home_candidate=$(dirname "$(dirname "$java_real")")
+        if [ -d "$java_home_candidate" ] && [ -x "$java_home_candidate/bin/java" ]; then
+            export JAVA_HOME="$java_home_candidate"
+            log_info "Found Java in PATH: $JAVA_HOME"
+            log_debug "Java version: $(\"$JAVA_HOME/bin/java\" -version 2>&1 | head -1)"
+            return 0
+        fi
+    fi
+    
+    # If we get here, Java was not found
+    log_error "Java Runtime not found!"
+    log_error "Please ensure one of the following:"
+    log_error "  1. Android Studio is installed (includes bundled Java)"
+    log_error "  2. JAVA_HOME is set to a valid Java installation"
+    log_error "  3. Java is available in your PATH"
+    log_error ""
+    log_error "On macOS, Android Studio typically includes Java at:"
+    log_error "  /Applications/Android Studio.app/Contents/jbr/Contents/Home"
+    return 1
+}
+
+# Function to detect and set ANDROID_HOME for Android builds
+setup_android_home() {
+    log_info "Setting up Android SDK environment..."
+    
+    # If ANDROID_HOME is already set and valid, use it
+    if [ -n "$ANDROID_HOME" ] && [ -d "$ANDROID_HOME" ]; then
+        log_debug "Using existing ANDROID_HOME: $ANDROID_HOME"
+        export ANDROID_HOME
+        return 0
+    fi
+    
+    # Check for local.properties file in android directory
+    local local_props="android/local.properties"
+    if [ -f "$local_props" ]; then
+        local sdk_dir=$(grep "^sdk.dir=" "$local_props" 2>/dev/null | cut -d'=' -f2 | sed 's/^[[:space:]]*//;s/[[:space:]]*$//' | sed "s|^file://||")
+        if [ -n "$sdk_dir" ] && [ -d "$sdk_dir" ]; then
+            export ANDROID_HOME="$sdk_dir"
+            log_info "Found Android SDK in local.properties: $ANDROID_HOME"
+            return 0
+        fi
+    fi
+    
+    # Try common macOS locations for Android SDK
+    local common_locations=(
+        "$HOME/Library/Android/sdk"
+        "$HOME/Android/Sdk"
+        "$HOME/.android/sdk"
+    )
+    
+    for sdk_path in "${common_locations[@]}"; do
+        if [ -d "$sdk_path" ] && [ -d "$sdk_path/platform-tools" ]; then
+            export ANDROID_HOME="$sdk_path"
+            log_info "Found Android SDK: $ANDROID_HOME"
+            
+            # Write to local.properties if it doesn't exist or doesn't have sdk.dir
+            if [ ! -f "$local_props" ] || ! grep -q "^sdk.dir=" "$local_props" 2>/dev/null; then
+                log_info "Writing Android SDK location to local.properties"
+                mkdir -p android
+                if [ -f "$local_props" ]; then
+                    echo "" >> "$local_props"
+                    echo "sdk.dir=$ANDROID_HOME" >> "$local_props"
+                else
+                    echo "sdk.dir=$ANDROID_HOME" > "$local_props"
+                fi
+            fi
+            
+            return 0
+        fi
+    done
+    
+    # If we get here, Android SDK was not found
+    log_error "Android SDK not found!"
+    log_error "Please ensure one of the following:"
+    log_error "  1. ANDROID_HOME is set to a valid Android SDK location"
+    log_error "  2. Android SDK is installed at one of these locations:"
+    log_error "     - $HOME/Library/Android/sdk (macOS default)"
+    log_error "     - $HOME/Android/Sdk"
+    log_error "  3. android/local.properties contains sdk.dir pointing to SDK"
+    log_error ""
+    log_error "You can find your SDK location in Android Studio:"
+    log_error "  Preferences > Appearance & Behavior > System Settings > Android SDK"
+    return 1
+}
+
 # Function to validate Android assets and resources
 validate_android_assets() {
     log_info "Validating Android assets and resources..."
@@ -326,6 +466,18 @@ print_header "TimeSafari Android Build Process"
 # Validate dependencies before proceeding
 validate_dependencies
 
+# Setup Java environment for Gradle
+setup_java_home || {
+    log_error "Failed to setup Java environment. Cannot proceed with Android build."
+    exit 1
+}
+
+# Setup Android SDK environment for Gradle
+setup_android_home || {
+    log_error "Failed to setup Android SDK environment. Cannot proceed with Android build."
+    exit 1
+}
+
 # Validate Android assets and resources
 validate_android_assets || {
     log_error "Android asset validation failed. Please fix the issues above and try again."
@@ -493,11 +645,13 @@ if [ "$BUILD_AAB" = true ]; then
 fi
 
 # Step 11: Auto-run app if requested
+# cap run runs sync by default, which would overwrite capacitor.plugins.json again;
+# we already synced and ran restore-local-plugins.js above, so skip sync here.
 if [ "$AUTO_RUN" = true ]; then
     log_step "Auto-running Android app..."
-    safe_execute "Launching app" "npx cap run android" || {
+    safe_execute "Launching app" "npx cap run android --no-sync" || {
         log_error "Failed to launch Android app"
-        log_info "You can manually run with: npx cap run android"
+        log_info "You can manually run with: npx cap run android --no-sync"
         exit 9
     }
     log_success "Android app launched successfully!"

scripts/build-electron.sh

@@ -215,9 +215,9 @@ clean_electron_artifacts() {
         safe_execute "Cleaning Electron app directory" "rm -rf electron/app"
     fi
     
-    # Clean TypeScript compilation artifacts
+    # Clean TypeScript compilation artifacts (exclude hand-maintained electron-plugins.js)
     if [[ -d "electron/src" ]]; then
-        safe_execute "Cleaning TypeScript artifacts" "find electron/src -name '*.js' -delete 2>/dev/null || true"
+        safe_execute "Cleaning TypeScript artifacts" "find electron/src -name '*.js' ! -path 'electron/src/rt/electron-plugins.js' -delete 2>/dev/null || true"
         safe_execute "Cleaning TypeScript artifacts" "find electron/src -name '*.js.map' -delete 2>/dev/null || true"
     fi
     

scripts/build-ios.sh

@@ -222,7 +222,8 @@ build_ios_app() {
     
     if [ "$BUILD_TYPE" = "debug" ]; then
         build_config="Debug"
-        destination="platform=iOS Simulator,name=iPhone 15 Pro"
+        # Any Simulator — avoids hardcoding a device name (e.g. iPhone 15 Pro) that may not exist in newer Xcode runtimes
+        destination="generic/platform=iOS Simulator"
     else
         build_config="Release"
         destination="platform=iOS,id=auto"
@@ -232,15 +233,21 @@ build_ios_app() {
     
     cd ios/App
     
-    # Build the app
-    xcodebuild -workspace App.xcworkspace \
+    # Build the app:
+    # -quiet: skip the huge export VAR dump (compiler warnings still show unless suppressed below).
+    # SWIFT_SUPPRESS_WARNINGS / GCC_WARN_INHIBIT_ALL_WARNINGS: quiet CLI output from Pods + plugins;
+    #   build in Xcode for full diagnostics. Real errors still fail the build.
+    xcodebuild -quiet \
+               -workspace App.xcworkspace \
                -scheme "$scheme" \
                -configuration "$build_config" \
                -destination "$destination" \
                build \
                CODE_SIGN_IDENTITY="" \
                CODE_SIGNING_REQUIRED=NO \
-               CODE_SIGNING_ALLOWED=NO
+               CODE_SIGNING_ALLOWED=NO \
+               SWIFT_SUPPRESS_WARNINGS=YES \
+               GCC_WARN_INHIBIT_ALL_WARNINGS=YES
     
     cd ../..
     
@@ -349,10 +356,56 @@ if [ "$CLEAN_ONLY" = true ]; then
     exit 0
 fi
 
+# Xcode 26 / CocoaPods workaround for cap sync (used by sync-only and full build)
+# Temporarily downgrade project.pbxproj objectVersion 70 -> 56 so pod install succeeds.
+run_cap_sync_with_workaround() {
+    local PROJECT_FILE="ios/App/App.xcodeproj/project.pbxproj"
+
+    if [ ! -f "$PROJECT_FILE" ]; then
+        log_error "Project file not found: $PROJECT_FILE (run full build first?)"
+        return 1
+    fi
+
+    local current_version
+    current_version=$(grep "objectVersion" "$PROJECT_FILE" | head -1 | grep -o "[0-9]\+" || echo "")
+
+    if [ -z "$current_version" ]; then
+        log_error "Could not determine project format version for Capacitor sync"
+        return 1
+    fi
+
+    if [ "$current_version" = "70" ]; then
+        log_debug "Applying Xcode 26 workaround for Capacitor sync: temporarily downgrading to format 56"
+
+        if ! sed -i '' 's/objectVersion = 70;/objectVersion = 56;/' "$PROJECT_FILE"; then
+            log_error "Failed to downgrade project format for Capacitor sync"
+            return 1
+        fi
+
+        log_info "Running Capacitor sync..."
+        if ! npx cap sync ios; then
+            log_error "Capacitor sync failed"
+            sed -i '' 's/objectVersion = 56;/objectVersion = 70;/' "$PROJECT_FILE" || true
+            return 1
+        fi
+
+        log_debug "Restoring project format to 70 after Capacitor sync..."
+        sed -i '' 's/objectVersion = 56;/objectVersion = 70;/' "$PROJECT_FILE" || true
+        log_success "Capacitor sync completed successfully"
+    else
+        log_debug "Project format is $current_version, running Capacitor sync normally"
+        if ! npx cap sync ios; then
+            log_error "Capacitor sync failed"
+            return 1
+        fi
+        log_success "Capacitor sync completed successfully"
+    fi
+}
+
 # Handle sync-only mode
 if [ "$SYNC_ONLY" = true ]; then
-    log_info "Sync-only mode: syncing with Capacitor"
-    safe_execute "Syncing with Capacitor" "npx cap sync ios" || exit 6
+    log_info "Sync-only mode: syncing with Capacitor (with Xcode 26 workaround if needed)"
+    safe_execute "Syncing with Capacitor" "run_cap_sync_with_workaround" || exit 6
     log_success "Sync completed successfully!"
     exit 0
 fi
@@ -404,7 +457,24 @@ elif [ "$BUILD_MODE" = "production" ]; then
     safe_execute "Building Capacitor version (production)" "npm run build:capacitor -- --mode production" || exit 3
 fi
 
-# Step 6: Install CocoaPods dependencies (with Xcode 26 workaround)
+# Step 6: Fix Daily Notification Plugin podspec name (must run before pod install)
+# ===================================================================
+# The Podfile expects TimesafariDailyNotificationPlugin.podspec, but the plugin
+# package only includes CapacitorDailyNotification.podspec. This script creates
+# the expected podspec file before CocoaPods tries to resolve dependencies.
+# ===================================================================
+log_info "Fixing Daily Notification Plugin podspec name..."
+if [ -f "./scripts/fix-daily-notification-podspec.sh" ]; then
+    if ./scripts/fix-daily-notification-podspec.sh; then
+        log_success "Daily Notification Plugin podspec created"
+    else
+        log_warn "Failed to create podspec (may already exist)"
+    fi
+else
+    log_warn "fix-daily-notification-podspec.sh not found, skipping"
+fi
+
+# Step 6.5: Install CocoaPods dependencies (with Xcode 26 workaround)
 # ===================================================================
 # WORKAROUND: Xcode 26 / CocoaPods Compatibility Issue
 # ===================================================================
@@ -416,13 +486,13 @@ fi
 # it back to 70 when opened, which is fine.
 #
 # NOTE: Both explicit pod install AND Capacitor sync (which runs pod install
-# internally) need this workaround. See run_pod_install_with_workaround()
-# and run_cap_sync_with_workaround() functions below.
+# internally) need this workaround. run_pod_install_with_workaround() is below;
+# run_cap_sync_with_workaround() is defined earlier (used by --sync and Step 6.6).
 #
 # TO REMOVE THIS WORKAROUND IN THE FUTURE:
 # 1. Check if xcodeproj gem has been updated: bundle exec gem list xcodeproj
 # 2. Test if pod install works without the workaround
-# 3. If it works, remove both workaround functions below
+# 3. If it works, remove run_pod_install_with_workaround() and run_cap_sync_with_workaround()
 # 4. Replace with:
 #    - safe_execute "Installing CocoaPods dependencies" "cd ios/App && bundle exec pod install && cd ../.." || exit 6
 #    - safe_execute "Syncing with Capacitor" "npx cap sync ios" || exit 6
@@ -488,56 +558,7 @@ run_pod_install_with_workaround() {
 
 safe_execute "Installing CocoaPods dependencies" "run_pod_install_with_workaround" || exit 6
 
-# Step 6.5: Sync with Capacitor (also needs workaround since it runs pod install internally)
-# Capacitor sync internally runs pod install, so we need to apply the workaround here too
-run_cap_sync_with_workaround() {
-    local PROJECT_FILE="ios/App/App.xcodeproj/project.pbxproj"
-    
-    # Check current format version
-    local current_version=$(grep "objectVersion" "$PROJECT_FILE" | head -1 | grep -o "[0-9]\+" || echo "")
-    
-    if [ -z "$current_version" ]; then
-        log_error "Could not determine project format version for Capacitor sync"
-        return 1
-    fi
-    
-    # Only apply workaround if format is 70
-    if [ "$current_version" = "70" ]; then
-        log_debug "Applying Xcode 26 workaround for Capacitor sync: temporarily downgrading to format 56"
-        
-        # Downgrade to format 56 (supported by CocoaPods)
-        if ! sed -i '' 's/objectVersion = 70;/objectVersion = 56;/' "$PROJECT_FILE"; then
-            log_error "Failed to downgrade project format for Capacitor sync"
-            return 1
-        fi
-        
-        # Run Capacitor sync (which will run pod install internally)
-        log_info "Running Capacitor sync..."
-        if ! npx cap sync ios; then
-            log_error "Capacitor sync failed"
-            # Try to restore format even on failure
-            sed -i '' 's/objectVersion = 56;/objectVersion = 70;/' "$PROJECT_FILE" || true
-            return 1
-        fi
-        
-        # Restore to format 70
-        log_debug "Restoring project format to 70 after Capacitor sync..."
-        if ! sed -i '' 's/objectVersion = 56;/objectVersion = 70;/' "$PROJECT_FILE"; then
-            log_warn "Failed to restore project format to 70 (Xcode will upgrade it automatically)"
-        fi
-        
-        log_success "Capacitor sync completed successfully"
-    else
-        # Format is not 70, run sync normally
-        log_debug "Project format is $current_version, running Capacitor sync normally"
-        if ! npx cap sync ios; then
-            log_error "Capacitor sync failed"
-            return 1
-        fi
-        log_success "Capacitor sync completed successfully"
-    fi
-}
-
+# Step 6.6: Sync with Capacitor (uses run_cap_sync_with_workaround defined above for Xcode 26)
 safe_execute "Syncing with Capacitor" "run_cap_sync_with_workaround" || exit 6
 
 # Step 7: Generate assets
@@ -550,16 +571,19 @@ safe_execute "Building iOS app" "build_ios_app" || exit 5
 if [ "$BUILD_IPA" = true ]; then
     log_info "Building IPA package..."
     cd ios/App
-    xcodebuild -workspace App.xcworkspace \
+    xcodebuild -quiet \
+               -workspace App.xcworkspace \
                -scheme App \
                -configuration Release \
                -archivePath build/App.xcarchive \
                archive \
                CODE_SIGN_IDENTITY="" \
                CODE_SIGNING_REQUIRED=NO \
-               CODE_SIGNING_ALLOWED=NO
+               CODE_SIGNING_ALLOWED=NO \
+               SWIFT_SUPPRESS_WARNINGS=YES \
+               GCC_WARN_INHIBIT_ALL_WARNINGS=YES
     
-    xcodebuild -exportArchive \
+    xcodebuild -quiet -exportArchive \
                -archivePath build/App.xcarchive \
                -exportPath build/ \
                -exportOptionsPlist exportOptions.plist

scripts/check-alarm-logs.sh

@@ -0,0 +1,70 @@
+#!/bin/bash
+# check-alarm-logs.sh
+# Author: Matthew Raymer
+# Description: Check logs around a specific time to see if alarm fired
+
+# Function to find adb command
+find_adb() {
+    # Check if adb is in PATH
+    if command -v adb >/dev/null 2>&1; then
+        echo "adb"
+        return 0
+    fi
+    
+    # Check for ANDROID_HOME
+    if [ -n "$ANDROID_HOME" ] && [ -x "$ANDROID_HOME/platform-tools/adb" ]; then
+        echo "$ANDROID_HOME/platform-tools/adb"
+        return 0
+    fi
+    
+    # Check for local.properties
+    local local_props="android/local.properties"
+    if [ -f "$local_props" ]; then
+        local sdk_dir=$(grep "^sdk.dir=" "$local_props" 2>/dev/null | cut -d'=' -f2 | sed 's/^[[:space:]]*//;s/[[:space:]]*$//' | sed "s|^file://||")
+        if [ -n "$sdk_dir" ] && [ -x "$sdk_dir/platform-tools/adb" ]; then
+            echo "$sdk_dir/platform-tools/adb"
+            return 0
+        fi
+    fi
+    
+    # Try common macOS locations
+    local common_locations=(
+        "$HOME/Library/Android/sdk"
+        "$HOME/Android/Sdk"
+        "$HOME/.android/sdk"
+    )
+    
+    for sdk_path in "${common_locations[@]}"; do
+        if [ -x "$sdk_path/platform-tools/adb" ]; then
+            echo "$sdk_path/platform-tools/adb"
+            return 0
+        fi
+    done
+    
+    # Not found
+    return 1
+}
+
+# Find adb
+ADB_CMD=$(find_adb)
+if [ $? -ne 0 ] || [ -z "$ADB_CMD" ]; then
+    echo "Error: adb command not found!"
+    exit 1
+fi
+
+echo "Checking logs for alarm activity..."
+echo "Looking for: DN|RECEIVE_START, AlarmManager, DailyNotification, timesafari"
+echo ""
+
+# Check recent logs for alarm-related activity
+echo "=== Recent alarm/receiver logs ==="
+"$ADB_CMD" logcat -d | grep -iE "DN|RECEIVE_START|RECEIVE_ERR|alarm.*timesafari|daily.*notification|com\.timesafari\.daily" | tail -20
+
+echo ""
+echo "=== All AlarmManager activity (last 50 lines) ==="
+"$ADB_CMD" logcat -d | grep -i "AlarmManager" | tail -50
+
+echo ""
+echo "=== Check if alarm is still scheduled ==="
+echo "Run this to see all scheduled alarms:"
+echo "  $ADB_CMD shell dumpsys alarm | grep -A 5 timesafari"

scripts/enhanced-migration-validator.sh

@@ -116,7 +116,7 @@ echo "=============================="
 
 # Analyze critical files identified in the assessment
 critical_files=(
-   src/components/MembersList.vue"
+   src/components/MeetingMembersList.vue"
     "src/views/ContactsView.vue"
     src/views/OnboardMeetingSetupView.vue"
   src/db/databaseUtil.ts"

scripts/fix-daily-notification-podspec.sh

@@ -0,0 +1,35 @@
+#!/bin/bash
+# Fix Daily Notification Plugin Podspec Name
+# Creates a podspec with the expected name for Capacitor sync
+
+PLUGIN_DIR="node_modules/@timesafari/daily-notification-plugin"
+PODSPEC_ACTUAL="CapacitorDailyNotification.podspec"
+PODSPEC_EXPECTED="TimesafariDailyNotificationPlugin.podspec"
+
+if [ -f "$PLUGIN_DIR/$PODSPEC_ACTUAL" ] && [ ! -f "$PLUGIN_DIR/$PODSPEC_EXPECTED" ]; then
+  echo "Creating podspec: $PODSPEC_EXPECTED"
+  cat > "$PLUGIN_DIR/$PODSPEC_EXPECTED" << 'EOF'
+require 'json'
+
+package = JSON.parse(File.read(File.join(__dir__, 'package.json')))
+
+Pod::Spec.new do |s|
+  s.name = 'TimesafariDailyNotificationPlugin'
+  s.version = package['version']
+  s.summary = package['description']
+  s.license = package['license']
+  s.homepage = package['repository']['url']
+  s.author = package['author']
+  s.source = { :git => package['repository']['url'], :tag => s.version.to_s }
+  s.source_files = 'ios/Plugin/**/*.{swift,h,m,c,cc,mm,cpp}'
+  s.ios.deployment_target  = '13.0'
+  s.dependency 'Capacitor'
+  s.swift_version = '5.1'
+end
+EOF
+  echo "✓ Podspec created successfully"
+elif [ -f "$PLUGIN_DIR/$PODSPEC_EXPECTED" ]; then
+  echo "ℹ Podspec already exists"
+else
+  echo "⚠ Actual podspec not found at $PLUGIN_DIR/$PODSPEC_ACTUAL"
+fi

scripts/git-hooks/README.md

@@ -38,7 +38,7 @@ The `pre-commit` hook automatically checks for debug code when committing to pro
 - Test files: `*.test.js`, `*.spec.ts`, `*.test.vue`
 - Scripts: `scripts/` directory
 - Test directories: `test-*` directories
-- Documentation: `docs/`, `*.md`, `*.txt`
+- Documentation: `doc/`, `*.md`, `*.txt`
 - Config files: `*.json`, `*.yml`, `*.yaml`
 - IDE files: `.cursor/` directory
 

scripts/git-hooks/debug-checker.config

@@ -52,7 +52,7 @@ SKIP_PATTERNS=(
     "^test-.*/"                     # Test directories (must end with /)
     "^\.git/"                       # Git directory
     "^node_modules/"                # Dependencies
-    "^docs/"                        # Documentation
+    "^doc/"                         # Documentation
     "^\.cursor/"                    # Cursor IDE files
     "\.md$"                         # Markdown files
     "\.txt$"                        # Text files

scripts/simple-validator.sh

@@ -93,7 +93,7 @@ echo "=========================="
 
 # Critical files from our assessment
 files=(
-   src/components/MembersList.vue"
+   src/components/MeetingMembersList.vue"
     "src/views/ContactsView.vue"
     src/views/OnboardMeetingSetupView.vue"
   src/db/databaseUtil.ts"

scripts/test-notification-receiver.sh

@@ -0,0 +1,104 @@
+#!/bin/bash
+# test-notification-receiver.sh
+# Author: Matthew Raymer
+# Description: Test script to manually trigger the DailyNotificationReceiver
+# to verify it's working correctly
+
+# Function to find adb command
+find_adb() {
+    # Check if adb is in PATH
+    if command -v adb >/dev/null 2>&1; then
+        echo "adb"
+        return 0
+    fi
+    
+    # Check for ANDROID_HOME
+    if [ -n "$ANDROID_HOME" ] && [ -x "$ANDROID_HOME/platform-tools/adb" ]; then
+        echo "$ANDROID_HOME/platform-tools/adb"
+        return 0
+    fi
+    
+    # Check for local.properties
+    local local_props="android/local.properties"
+    if [ -f "$local_props" ]; then
+        local sdk_dir=$(grep "^sdk.dir=" "$local_props" 2>/dev/null | cut -d'=' -f2 | sed 's/^[[:space:]]*//;s/[[:space:]]*$//' | sed "s|^file://||")
+        if [ -n "$sdk_dir" ] && [ -x "$sdk_dir/platform-tools/adb" ]; then
+            echo "$sdk_dir/platform-tools/adb"
+            return 0
+        fi
+    fi
+    
+    # Try common macOS locations
+    local common_locations=(
+        "$HOME/Library/Android/sdk"
+        "$HOME/Android/Sdk"
+        "$HOME/.android/sdk"
+    )
+    
+    for sdk_path in "${common_locations[@]}"; do
+        if [ -x "$sdk_path/platform-tools/adb" ]; then
+            echo "$sdk_path/platform-tools/adb"
+            return 0
+        fi
+    done
+    
+    # Not found
+    return 1
+}
+
+# Find adb
+ADB_CMD=$(find_adb)
+if [ $? -ne 0 ] || [ -z "$ADB_CMD" ]; then
+    echo "Error: adb command not found!"
+    echo ""
+    echo "Please ensure one of the following:"
+    echo "  1. adb is in your PATH"
+    echo "  2. ANDROID_HOME is set and points to Android SDK"
+    echo "  3. Android SDK is installed at:"
+    echo "     - $HOME/Library/Android/sdk (macOS default)"
+    echo "     - $HOME/Android/Sdk"
+    echo ""
+    echo "You can find your SDK location in Android Studio:"
+    echo "  Preferences > Appearance & Behavior > System Settings > Android SDK"
+    exit 1
+fi
+
+echo "Testing DailyNotificationReceiver..."
+echo "Using adb: $ADB_CMD"
+echo ""
+
+# Get the package name
+PACKAGE_NAME="app.timesafari.app"
+INTENT_ACTION="org.timesafari.daily.NOTIFICATION"
+
+echo "Package: $PACKAGE_NAME"
+echo "Intent Action: $INTENT_ACTION"
+echo ""
+
+# Check if device is connected
+if ! "$ADB_CMD" devices | grep -q $'\tdevice'; then
+    echo "Error: No Android device/emulator connected!"
+    echo ""
+    echo "Please:"
+    echo "  1. Start an Android emulator in Android Studio, or"
+    echo "  2. Connect a physical device via USB"
+    echo ""
+    echo "Then run: $ADB_CMD devices"
+    exit 1
+fi
+
+# Test 1: Send broadcast intent to trigger receiver (without ID - simulates current bug)
+echo "Test 1: Sending broadcast intent to DailyNotificationReceiver (without ID)..."
+"$ADB_CMD" shell am broadcast -a "$INTENT_ACTION" -n "$PACKAGE_NAME/org.timesafari.dailynotification.DailyNotificationReceiver"
+
+echo ""
+echo "Test 2: Sending broadcast intent WITH ID (to test if receiver works with ID)..."
+"$ADB_CMD" shell am broadcast -a "$INTENT_ACTION" -n "$PACKAGE_NAME/org.timesafari.dailynotification.DailyNotificationReceiver" --es "id" "timesafari_daily_reminder"
+
+echo ""
+echo "Check logcat for 'DN|RECEIVE_START' to see if receiver was triggered"
+echo "Test 1 should show 'missing_id' error"
+echo "Test 2 should work correctly (if plugin supports it)"
+echo ""
+echo "To monitor logs, run:"
+echo "  $ADB_CMD logcat | grep -E 'DN|RECEIVE_START|DailyNotification'"

scripts/type-safety-check.sh

@@ -95,7 +95,7 @@ print_status "All type safety checks passed! 🎉"
 print_status "Your code is ready for commit"
 echo ""
 echo "📚 Remember to follow the Type Safety Guidelines:"
-echo "   - docs/typescript-type-safety-guidelines.md"
+echo "   - doc/typescript-type-safety-guidelines.md"
 echo "   - Use proper error handling patterns"
 echo "   - Leverage existing type definitions"
 echo "   - Run 'npm run lint-fix' for automatic fixes"

scripts/validate-critical-files.sh

@@ -93,7 +93,7 @@ echo "=========================="
 
 # Critical files from our assessment
 files=(
-   src/components/MembersList.vue"
+   src/components/MeetingMembersList.vue"
     "src/views/ContactsView.vue"
     src/views/OnboardMeetingSetupView.vue"
   src/db/databaseUtil.ts"

scripts/validate-migration.sh

@@ -321,7 +321,7 @@ suggest_next_steps() {
         echo "3. Update documentation to reflect new patterns"
     else
         echo "1. Start with high-priority files (databaseUtil and logging)"
-        echo "2. Use the migration template: docs/migration-templates/component-migration.md"
+        echo "2. Use the migration template: doc/migration-templates/component-migration.md"
         echo "3. Test each component after migration"
         echo "4. Set up ESLint rules to prevent new legacy usage"
         echo "5. Re-run this script to track progress"

scripts/validate-notification-completeness.sh

@@ -113,7 +113,7 @@ if [[ $total_issues -gt 0 ]]; then
     echo ""
     echo "🚨 ACTION REQUIRED:"
     echo "   $total_issues components need notification migration completion"
-    echo "   Follow: docs/migration-templates/COMPLETE_MIGRATION_CHECKLIST.md"
+    echo "   Follow: doc/migration-templates/COMPLETE_MIGRATION_CHECKLIST.md"
     exit 1
 else
     echo ""

src/App.vue

@@ -360,6 +360,7 @@
 
 <script lang="ts">
 import { Vue, Component } from "vue-facing-decorator";
+import { Capacitor } from "@capacitor/core";
 
 import { NotificationIface } from "./constants/app";
 import { PlatformServiceMixin } from "@/utils/PlatformServiceMixin";
@@ -382,6 +383,24 @@ export default class App extends Vue {
   async turnOffNotifications(
     notification: NotificationIface,
   ): Promise<boolean> {
+    // On native (iOS/Android) we don't use web push; the callback handles cancel + state in the view.
+    // The callback is the one passed for this specific modal (New Activity or Daily Reminder), so we only turn off that one.
+    if (Capacitor.isNativePlatform()) {
+      if (notification.callback) {
+        await notification.callback(true);
+      }
+      this.$notify(
+        {
+          group: "alert",
+          type: "info",
+          title: "Finished",
+          text: "Notifications are off.",
+        },
+        5000,
+      );
+      return true;
+    }
+
     let subscription: PushSubscriptionJSON | null = null;
     let allGoingOff = false;
 

src/components/ContactListHeader.vue

@@ -21,7 +21,7 @@
         </button>
         <font-awesome
           icon="circle-info"
-          class="text-2xl text-blue-500 ml-2"
+          class="text-2xl text-blue-500 ml-4"
           @click="emitShowCopyInfo"
         />
       </div>

src/components/DataExportSection.vue

@@ -105,11 +105,9 @@ import { Component, Prop, Vue } from "vue-facing-decorator";
 import { Router } from "vue-router";
 import * as R from "ramda";
 
-import { AppString, NotificationIface } from "../constants/app";
-import { Contact } from "../db/tables/contacts";
+import { NotificationIface } from "../constants/app";
 
 import { logger } from "../utils/logger";
-import { contactsToExportJson } from "../libs/util";
 import { createNotifyHelpers, TIMEOUTS } from "@/utils/notify";
 import { PlatformServiceMixin } from "@/utils/PlatformServiceMixin";
 import { ACCOUNT_VIEW_CONSTANTS } from "@/constants/accountView";
@@ -222,26 +220,15 @@ export default class DataExportSection extends Vue {
     return "list-disc list-outside ml-4";
   }
 
-  /**
-   * Computed property for the export file name
-   * Includes today's date for easy identification of backup files
-   */
-  private get fileName(): string {
-    const today = new Date();
-    const dateString = today.toISOString().split("T")[0]; // YYYY-MM-DD format
-    return `${AppString.APP_NAME_NO_SPACES}-backup-contacts-${dateString}.json`;
-  }
-
   /**
    * Exports the database to a JSON file
+   * Exports contacts and contact labels tables
    * Uses the platform service to handle platform-specific export logic
    * Shows success/error notifications to user
    *
    * @throws {Error} If export fails
    */
   public async exportDatabase(): Promise<void> {
-    // Note that similar code is in ContactsView.vue exportContactData()
-
     if (this.isExporting) {
       return; // Prevent multiple simultaneous exports
     }
@@ -249,49 +236,11 @@ export default class DataExportSection extends Vue {
     try {
       this.isExporting = true;
 
-      // Fetch contacts from database using mixin's cached method
-      const allContacts = await this.$contacts();
-
-      // Convert contacts to export format
-      const processedContacts: Contact[] = allContacts.map((contact) => {
-        // first remove the contactMethods field, mostly to cast to a clear type (that will end up with JSON objects)
-        const exContact: Contact = R.omit(["contactMethods"], contact);
-        // now add contactMethods as a true array of ContactMethod objects
-        // $contacts() returns normalized contacts where contactMethods is already an array,
-        // but we handle both array and string cases for robustness
-        if (contact.contactMethods) {
-          if (Array.isArray(contact.contactMethods)) {
-            // Already an array, use it directly
-            exContact.contactMethods = contact.contactMethods;
-          } else {
-            // Check if it's a string that needs parsing (shouldn't happen with normalized contacts, but handle for robustness)
-            const contactMethodsValue = contact.contactMethods as unknown;
-            if (
-              typeof contactMethodsValue === "string" &&
-              contactMethodsValue.trim() !== ""
-            ) {
-              // String that needs parsing
-              exContact.contactMethods = JSON.parse(contactMethodsValue);
-            } else {
-              // Invalid data, use empty array
-              exContact.contactMethods = [];
-            }
-          }
-        } else {
-          // No contactMethods, use empty array
-          exContact.contactMethods = [];
-        }
-        return exContact;
-      });
-
-      const exportData = contactsToExportJson(processedContacts);
-      const jsonStr = JSON.stringify(exportData, null, 2);
-
-      // Use platform service to handle export (no platform-specific logic here!)
-      await this.platformService.writeAndShareFile(this.fileName, jsonStr);
+      // Prepare export data using shared utility function
+      await this.$saveContactExport();
 
       this.notify.success(
-        "Contact export completed successfully. Check your downloads or share dialog.",
+        "Contact export completed successfully. Check downloads or the share dialog.",
       );
     } catch (error) {
       logger.error("Export Error:", error);

src/components/EntityGrid.vue

@@ -57,8 +57,8 @@ projects, and special entities with selection. * * @author Matthew Raymer */
         :selectable="youSelectable"
         :conflicted="youConflicted"
         :entity-data="youEntityData"
-        :notify="notify"
         :conflict-context="conflictContext"
+        :notify="notify"
         @entity-selected="handleEntitySelected"
       />
 
@@ -69,8 +69,8 @@ projects, and special entities with selection. * * @author Matthew Raymer */
         :label="unnamedEntityName"
         icon="circle-question"
         :entity-data="unnamedEntityData"
-        :notify="notify"
         :conflict-context="conflictContext"
+        :notify="notify"
         @entity-selected="handleEntitySelected"
       />
     </template>
@@ -97,8 +97,8 @@ projects, and special entities with selection. * * @author Matthew Raymer */
             :person="person"
             :conflicted="isPersonConflicted(person.did)"
             :show-time-icon="true"
-            :notify="notify"
             :conflict-context="conflictContext"
+            :notify="notify"
             @person-selected="handlePersonSelected"
           />
         </template>
@@ -116,8 +116,8 @@ projects, and special entities with selection. * * @author Matthew Raymer */
             :person="person"
             :conflicted="isPersonConflicted(person.did)"
             :show-time-icon="true"
-            :notify="notify"
             :conflict-context="conflictContext"
+            :notify="notify"
             @person-selected="handlePersonSelected"
           />
         </template>
@@ -131,40 +131,40 @@ projects, and special entities with selection. * * @author Matthew Raymer */
           :person="person"
           :conflicted="isPersonConflicted(person.did)"
           :show-time-icon="true"
-          :notify="notify"
           :conflict-context="conflictContext"
+          :notify="notify"
           @person-selected="handlePersonSelected"
         />
       </template>
     </template>
 
     <template v-else-if="entityType === 'projects'">
-      <!-- When showing projects without search: split into recently bookmarked and rest -->
+      <!-- When showing projects without search: split into recently starred and rest -->
       <template v-if="!searchTerm.trim()">
-        <!-- Recently Bookmarked Section -->
-        <template v-if="recentBookmarkedProjects.length > 0">
+        <!-- Recently Starred Section -->
+        <template v-if="recentStarredProjectsToShow.length > 0">
           <li
             class="text-xs font-semibold text-slate-500 uppercase pt-5 pb-1.5 px-2 border-b border-slate-300"
           >
-            Recently Bookmarked
+            Recently Starred
           </li>
           <ProjectCard
-            v-for="project in recentBookmarkedProjects"
+            v-for="project in recentStarredProjectsToShow"
             :key="project.handleId"
             :project="project"
             :active-did="activeDid"
             :all-my-dids="allMyDids"
             :all-contacts="allContacts"
             :conflicted="isProjectConflicted(project.handleId)"
-            :notify="notify"
             :conflict-context="conflictContext"
+            :notify="notify"
             @project-selected="handleProjectSelected"
           />
         </template>
 
         <!-- Rest of Projects Section -->
         <li
-          v-if="recentBookmarkedProjects.length > 0"
+          v-if="remainingProjects.length > 0"
           class="text-xs font-semibold text-slate-500 uppercase pt-5 pb-1.5 px-2 border-b border-slate-300"
         >
           All Projects
@@ -177,8 +177,8 @@ projects, and special entities with selection. * * @author Matthew Raymer */
           :all-my-dids="allMyDids"
           :all-contacts="allContacts"
           :conflicted="isProjectConflicted(project.handleId)"
-          :notify="notify"
           :conflict-context="conflictContext"
+          :notify="notify"
           @project-selected="handleProjectSelected"
         />
       </template>
@@ -193,8 +193,8 @@ projects, and special entities with selection. * * @author Matthew Raymer */
           :all-my-dids="allMyDids"
           :all-contacts="allContacts"
           :conflicted="isProjectConflicted(project.handleId)"
-          :notify="notify"
           :conflict-context="conflictContext"
+          :notify="notify"
           @project-selected="handleProjectSelected"
         />
       </template>
@@ -223,7 +223,7 @@ import { TIMEOUTS } from "@/utils/notify";
 const INITIAL_BATCH_SIZE = 20;
 const INCREMENT_SIZE = 20;
 const RECENT_CONTACTS_COUNT = 3;
-const RECENT_BOOKMARKED_PROJECTS_COUNT = 10;
+const RECENT_STARRED_PROJECTS_COUNT = 10;
 
 /**
  * EntityGrid - Unified grid layout for displaying people or projects
@@ -251,30 +251,6 @@ export default class EntityGrid extends Vue {
   @Prop({ required: true })
   entityType!: "people" | "projects";
 
-  // Search state
-  searchTerm = "";
-  isSearching = false;
-  searchTimeout: NodeJS.Timeout | null = null;
-  filteredEntities: Contact[] | PlanData[] = [];
-  searchBeforeId: string | undefined = undefined;
-  isLoadingSearchMore = false;
-
-  // API server for project searches
-  apiServer = "";
-
-  // Internal project state (when entities prop not provided for projects)
-  allProjects: PlanData[] = [];
-  loadBeforeId: string | undefined = undefined;
-  isLoadingProjects = false;
-
-  // Infinite scroll state
-  displayedCount = INITIAL_BATCH_SIZE;
-  infiniteScrollReset?: () => void;
-  scrollContainer?: HTMLElement;
-
-  // Starred projects state (for showing recently bookmarked projects)
-  starredPlanHandleIds: string[] = [];
-
   /**
    * Array of entities to display
    *
@@ -326,32 +302,30 @@ export default class EntityGrid extends Vue {
   @Prop({ default: "other party" })
   conflictContext!: string;
 
-  /**
-   * Function to determine which entities to display (allows parent control)
-   *
-   * This function prop allows parent components to customize which entities
-   * are displayed in the grid, enabling advanced filtering and sorting.
-   * Note: Infinite scroll is disabled when this prop is provided.
-   *
-   * @param entities - The full array of entities (Contact[] or PlanData[])
-   * @param entityType - The type of entities being displayed ("people" or "projects")
-   * @returns Filtered/sorted array of entities to display
-   *
-   * @example
-   * // Custom filtering: only show contacts with profile images
-   * :display-entities-function="(entities, type) =>
-   *   entities.filter(e => e.profileImageUrl)"
-   *
-   * @example
-   * // Custom sorting: sort projects by name
-   * :display-entities-function="(entities, type) =>
-   *   entities.sort((a, b) => a.name.localeCompare(b.name))"
-   */
-  @Prop({ default: null })
-  displayEntitiesFunction?: (
-    entities: Contact[] | PlanData[],
-    entityType: "people" | "projects",
-  ) => Contact[] | PlanData[];
+  // Search state
+  searchTerm = "";
+  isSearching = false;
+  searchTimeout: NodeJS.Timeout | null = null;
+  filteredEntities: Contact[] | PlanData[] = [];
+  searchBeforeId: string | undefined = undefined;
+  isLoadingSearchMore = false;
+
+  // API server for project searches
+  apiServer = "";
+
+  // Internal project state (when entities prop not provided for projects)
+  allProjects: PlanData[] = [];
+  loadBeforeId: string | undefined = undefined;
+  isLoadingProjects = false;
+
+  // Infinite scroll state
+  displayedCount = INITIAL_BATCH_SIZE;
+  infiniteScrollReset?: () => void;
+  scrollContainer?: HTMLElement;
+
+  // Starred projects state (for showing recently starred projects)
+  starredPlanHandleIds: string[] = [];
+  recentStarredProjects: PlanData[] = [];
 
   /**
    * CSS classes for the empty state message
@@ -397,11 +371,6 @@ export default class EntityGrid extends Vue {
       return this.filteredEntities.slice(0, this.displayedCount);
     }
 
-    // If custom function provided, use it (disables infinite scroll)
-    if (this.displayEntitiesFunction) {
-      return this.displayEntitiesFunction(this.entitiesToUse, this.entityType);
-    }
-
     // Default: projects use infinite scroll
     if (this.entityType === "projects") {
       return (this.entitiesToUse as PlanData[]).slice(0, this.displayedCount);
@@ -457,40 +426,19 @@ export default class EntityGrid extends Vue {
   }
 
   /**
-   * Get the 3 most recently bookmarked projects (when showing projects and not searching)
-   * The starredPlanHandleIds array order represents bookmark order (newest at the end)
+   * Get the 3 most recently starred projects (when showing projects and not searching)
+   * Returns the cached member field
    */
-  get recentBookmarkedProjects(): PlanData[] {
-    if (
-      this.entityType !== "projects" ||
-      this.searchTerm.trim() ||
-      this.starredPlanHandleIds.length === 0
-    ) {
+  get recentStarredProjectsToShow(): PlanData[] {
+    if (this.entityType !== "projects" || this.searchTerm.trim()) {
       return [];
     }
-
-    const projects = this.entitiesToUse as PlanData[];
-    if (projects.length === 0) {
-      return [];
-    }
-
-    // Get the last 3 starred IDs (most recently bookmarked)
-    const recentStarredIds = this.starredPlanHandleIds.slice(
-      -RECENT_BOOKMARKED_PROJECTS_COUNT,
-    );
-
-    // Find projects matching those IDs, sorting with newest first
-    const recentProjects = recentStarredIds
-      .map((id) => projects.find((p) => p.handleId === id))
-      .filter((p): p is PlanData => p !== undefined)
-      .reverse();
-
-    return recentProjects;
+    return this.recentStarredProjects;
   }
 
   /**
    * Get all projects (when showing projects and not searching)
-   * Includes projects shown in "Recently Bookmarked" section as well
+   * Includes projects shown in "Recently Starred" section as well
    * Uses infinite scroll to control how many are displayed
    */
   get remainingProjects(): PlanData[] {
@@ -552,6 +500,115 @@ export default class EntityGrid extends Vue {
     return UNNAMED_ENTITY_NAME;
   }
 
+  /**
+   * Initialize infinite scroll on mount
+   */
+  async mounted(): Promise<void> {
+    if (this.entityType === "projects") {
+      const settings = await this.$accountSettings();
+      this.apiServer = settings.apiServer || "";
+
+      // Load starred project IDs for showing recently starred projects
+      this.starredPlanHandleIds = settings.starredPlanHandleIds || [];
+
+      // Load projects on mount if entities prop not provided
+      this.isLoadingProjects = true;
+      if (!this.entities) {
+        await this.loadProjects();
+      }
+      await this.loadRecentStarredProjects();
+      this.isLoadingProjects = false;
+    }
+
+    // Validate entities prop for people
+    if (this.entityType === "people") {
+      if (!this.entities) {
+        logger.error(
+          "EntityGrid: entities prop or allContacts prop is required when entityType is 'people'",
+        );
+      }
+    }
+
+    this.$nextTick(() => {
+      const container = this.$refs.scrollContainer as HTMLElement;
+
+      if (container) {
+        const { reset } = useInfiniteScroll(
+          container,
+          async () => {
+            // Search mode: handle search pagination
+            if (this.searchTerm.trim()) {
+              if (this.entityType === "projects") {
+                // Projects: load more search results if available
+                if (
+                  this.displayedCount >= this.filteredEntities.length &&
+                  this.searchBeforeId &&
+                  !this.isLoadingSearchMore
+                ) {
+                  this.isLoadingSearchMore = true;
+                  try {
+                    const searchLower = this.searchTerm.toLowerCase().trim();
+                    await this.loadProjects(this.searchBeforeId, searchLower);
+                    // After loading more, reset scroll state to allow further loading
+                    this.infiniteScrollReset?.();
+                  } catch (error) {
+                    logger.error("Error loading more search results:", error);
+                    // Error already handled in loadProjects
+                  } finally {
+                    this.isLoadingSearchMore = false;
+                  }
+                } else {
+                  // Show more from already-loaded search results
+                  this.displayedCount += INCREMENT_SIZE;
+                }
+              } else {
+                // Contacts: show more from already-filtered results
+                this.displayedCount += INCREMENT_SIZE;
+              }
+            } else {
+              // Non-search mode
+              if (this.entityType === "projects") {
+                const projectsToCheck = this.entities || this.allProjects;
+                const beforeId = this.entities ? undefined : this.loadBeforeId;
+
+                // If using internal state and need to load more from server
+                if (
+                  !this.entities &&
+                  this.displayedCount >= projectsToCheck.length &&
+                  beforeId &&
+                  !this.isLoadingProjects
+                ) {
+                  this.isLoadingProjects = true;
+                  try {
+                    await this.loadProjects(beforeId);
+                    // After loading more, reset scroll state to allow further loading
+                    this.infiniteScrollReset?.();
+                  } catch (error) {
+                    logger.error("Error loading more projects:", error);
+                    // Error already handled in loadProjects
+                  } finally {
+                    this.isLoadingProjects = false;
+                  }
+                } else {
+                  // Normal case: increment displayedCount to show more from memory
+                  this.displayedCount += INCREMENT_SIZE;
+                }
+              } else {
+                // People: increment displayedCount to show more from memory
+                this.displayedCount += INCREMENT_SIZE;
+              }
+            }
+          },
+          {
+            distance: 50, // pixels from bottom
+            canLoadMore: () => this.canLoadMore(),
+          },
+        );
+        this.infiniteScrollReset = reset;
+      }
+    });
+  }
+
   /**
    * Check if a person DID is conflicted
    */
@@ -636,7 +693,7 @@ export default class EntityGrid extends Vue {
       if (this.entityType === "projects") {
         // Server-side search for projects (initial load, no beforeId)
         const searchLower = this.searchTerm.toLowerCase().trim();
-        await this.fetchProjects(undefined, searchLower);
+        await this.loadProjects(undefined, searchLower);
       } else {
         // Client-side filtering for contacts (complete list)
         await this.performContactSearch();
@@ -659,10 +716,7 @@ export default class EntityGrid extends Vue {
    * @param beforeId - Optional rowId for pagination (loads projects before this ID)
    * @param claimContents - Optional search term (if provided, performs search; if not, loads all)
    */
-  async fetchProjects(
-    beforeId?: string,
-    claimContents?: string,
-  ): Promise<void> {
+  async loadProjects(beforeId?: string, claimContents?: string): Promise<void> {
     if (!this.apiServer) {
       if (claimContents) {
         this.filteredEntities = [];
@@ -806,6 +860,57 @@ export default class EntityGrid extends Vue {
     }
   }
 
+  /**
+   * Load the most recently starred projects
+   * The starredPlanHandleIds array order represents starred order (newest at the end)
+   */
+  async loadRecentStarredProjects(): Promise<void> {
+    if (
+      this.entityType !== "projects" ||
+      this.searchTerm.trim() ||
+      this.starredPlanHandleIds.length === 0
+    ) {
+      this.recentStarredProjects = [];
+      return;
+    }
+
+    // Get the last 3 starred IDs (most recently starred)
+    const recentStarredIds = this.starredPlanHandleIds.slice(
+      -RECENT_STARRED_PROJECTS_COUNT,
+    );
+
+    // Find projects matching those IDs, sorting with newest first
+    const projects = this.entitiesToUse as PlanData[];
+    const recentProjects = recentStarredIds
+      .map((id) => projects.find((p) => p.handleId === id))
+      .filter((p): p is PlanData => p !== undefined)
+      .reverse();
+
+    // If any projects are not found, fetch them from the API server
+    if (recentProjects.length < recentStarredIds.length) {
+      const missingIds = recentStarredIds.filter(
+        (id) => !recentProjects.some((p) => p.handleId === id),
+      );
+      const missingProjects = await this.fetchProjectsByIds(missingIds);
+      recentProjects.push(...missingProjects);
+    }
+    this.recentStarredProjects = recentProjects;
+  }
+
+  async fetchProjectsByIds(ids: string[]): Promise<PlanData[]> {
+    const idsString = encodeURIComponent(JSON.stringify(ids));
+    const url = `${this.apiServer}/api/v2/report/plans?planHandleIds=${idsString}`;
+    const response = await fetch(url, {
+      method: "GET",
+      headers: await getHeaders(this.activeDid),
+    });
+    if (response.status !== 200) {
+      throw new Error("Failed to fetch projects");
+    }
+    const results = await response.json();
+    return results.data;
+  }
+
   /**
    * Client-side contact search
    * Assumes entities prop contains complete contact list from local database
@@ -860,11 +965,6 @@ export default class EntityGrid extends Vue {
    * Determine if more entities can be loaded
    */
   canLoadMore(): boolean {
-    if (this.displayEntitiesFunction) {
-      // Custom function disables infinite scroll
-      return false;
-    }
-
     if (this.searchTerm.trim()) {
       // Search mode: check if more results available
       if (this.entityType === "projects") {
@@ -911,129 +1011,6 @@ export default class EntityGrid extends Vue {
     return this.displayedCount < this.entities.length;
   }
 
-  /**
-   * Initialize infinite scroll on mount
-   */
-  async mounted(): Promise<void> {
-    // Load apiServer for project searches/loads
-    if (this.entityType === "projects") {
-      const settings = await this.$accountSettings();
-      this.apiServer = settings.apiServer || "";
-
-      // Load starred project IDs for showing recently bookmarked projects
-      this.starredPlanHandleIds = settings.starredPlanHandleIds || [];
-
-      // Load projects on mount if entities prop not provided
-      if (!this.entities && this.apiServer) {
-        this.isLoadingProjects = true;
-        try {
-          await this.fetchProjects();
-        } catch (error) {
-          logger.error("Error loading projects on mount:", error);
-        } finally {
-          this.isLoadingProjects = false;
-        }
-      }
-    }
-
-    // Validate entities prop for people
-    if (this.entityType === "people" && !this.entities) {
-      logger.error(
-        "EntityGrid: entities prop is required when entityType is 'people'",
-      );
-      if (this.notify) {
-        this.notify(
-          {
-            group: "alert",
-            type: "danger",
-            title: "Error",
-            text: "Contacts data is required but not provided.",
-          },
-          TIMEOUTS.SHORT,
-        );
-      }
-    }
-
-    this.$nextTick(() => {
-      const container = this.$refs.scrollContainer as HTMLElement;
-
-      if (container) {
-        const { reset } = useInfiniteScroll(
-          container,
-          async () => {
-            // Search mode: handle search pagination
-            if (this.searchTerm.trim()) {
-              if (this.entityType === "projects") {
-                // Projects: load more search results if available
-                if (
-                  this.displayedCount >= this.filteredEntities.length &&
-                  this.searchBeforeId &&
-                  !this.isLoadingSearchMore
-                ) {
-                  this.isLoadingSearchMore = true;
-                  try {
-                    const searchLower = this.searchTerm.toLowerCase().trim();
-                    await this.fetchProjects(this.searchBeforeId, searchLower);
-                    // After loading more, reset scroll state to allow further loading
-                    this.infiniteScrollReset?.();
-                  } catch (error) {
-                    logger.error("Error loading more search results:", error);
-                    // Error already handled in fetchProjects
-                  } finally {
-                    this.isLoadingSearchMore = false;
-                  }
-                } else {
-                  // Show more from already-loaded search results
-                  this.displayedCount += INCREMENT_SIZE;
-                }
-              } else {
-                // Contacts: show more from already-filtered results
-                this.displayedCount += INCREMENT_SIZE;
-              }
-            } else {
-              // Non-search mode
-              if (this.entityType === "projects") {
-                const projectsToCheck = this.entities || this.allProjects;
-                const beforeId = this.entities ? undefined : this.loadBeforeId;
-
-                // If using internal state and need to load more from server
-                if (
-                  !this.entities &&
-                  this.displayedCount >= projectsToCheck.length &&
-                  beforeId &&
-                  !this.isLoadingProjects
-                ) {
-                  this.isLoadingProjects = true;
-                  try {
-                    await this.fetchProjects(beforeId);
-                    // After loading more, reset scroll state to allow further loading
-                    this.infiniteScrollReset?.();
-                  } catch (error) {
-                    logger.error("Error loading more projects:", error);
-                    // Error already handled in fetchProjects
-                  } finally {
-                    this.isLoadingProjects = false;
-                  }
-                } else {
-                  // Normal case: increment displayedCount to show more from memory
-                  this.displayedCount += INCREMENT_SIZE;
-                }
-              } else {
-                // People: increment displayedCount to show more from memory
-                this.displayedCount += INCREMENT_SIZE;
-              }
-            }
-          },
-          {
-            distance: 50, // pixels from bottom
-            canLoadMore: () => this.canLoadMore(),
-          },
-        );
-        this.infiniteScrollReset = reset;
-      }
-    });
-  }
-
   // Emit methods using @Emit decorator
 
   @Emit("entity-selected")
@@ -1061,26 +1038,15 @@ export default class EntityGrid extends Vue {
 
     // When switching to projects, load them if not provided via entities prop
     if (newType === "projects" && !this.entities) {
-      // Ensure apiServer is loaded
-      if (!this.apiServer) {
-        const settings = await this.$accountSettings();
-        this.apiServer = settings.apiServer || "";
-        this.starredPlanHandleIds = settings.starredPlanHandleIds || [];
-      }
+      const settings = await this.$accountSettings();
+      this.apiServer = settings.apiServer || "";
+      this.starredPlanHandleIds = settings.starredPlanHandleIds || [];
 
-      // Load projects if we have an API server
-      if (this.apiServer && this.allProjects.length === 0) {
+      if (this.allProjects.length === 0) {
         this.isLoadingProjects = true;
-        try {
-          await this.fetchProjects();
-        } catch (error) {
-          logger.error(
-            "Error loading projects when switching to projects:",
-            error,
-          );
-        } finally {
-          this.isLoadingProjects = false;
-        }
+        await this.loadProjects();
+        await this.loadRecentStarredProjects();
+        this.isLoadingProjects = false;
       }
     }
 

src/components/EntitySelectionStep.vue

@@ -24,14 +24,14 @@ properties * * @author Matthew Raymer */
 
     <EntityGrid
       :entity-type="shouldShowProjects ? 'projects' : 'people'"
-      :entities="shouldShowProjects ? projects || undefined : allContacts"
+      :entities="shouldShowProjects ? undefined : allContacts"
       :active-did="activeDid"
       :all-my-dids="allMyDids"
       :all-contacts="allContacts"
       :conflict-checker="conflictChecker"
-      :you-selectable="youSelectable"
-      :notify="notify"
       :conflict-context="conflictContext"
+      :notify="notify"
+      :you-selectable="youSelectable"
       @entity-selected="handleEntitySelected"
     />
 
@@ -45,16 +45,7 @@ import EntityGrid from "./EntityGrid.vue";
 import { Contact } from "../db/tables/contacts";
 import { PlanData } from "../interfaces/records";
 import { NotificationIface } from "../constants/app";
-
-/**
- * Entity data interface for giver/receiver
- */
-interface EntityData {
-  did?: string;
-  handleId?: string;
-  name?: string;
-  image?: string;
-}
+import { GiverReceiverInputInfo } from "@/libs/util";
 
 /**
  * Entity selection event data structure
@@ -87,22 +78,6 @@ export default class EntitySelectionStep extends Vue {
   @Prop({ required: true })
   stepType!: "giver" | "recipient";
 
-  /** Type of giver entity: 'person' or 'project' */
-  @Prop({ required: true })
-  giverEntityType!: "person" | "project";
-
-  /** Type of recipient entity: 'person' or 'project' */
-  @Prop({ required: true })
-  recipientEntityType!: "person" | "project";
-
-  /** Whether to show projects instead of people */
-  @Prop({ default: false })
-  showProjects!: boolean;
-
-  /** Array of available projects (optional - EntityGrid loads internally if not provided) */
-  @Prop({ required: false })
-  projects?: PlanData[];
-
   /** Array of available contacts */
   @Prop({ required: true })
   allContacts!: Contact[];
@@ -119,40 +94,22 @@ export default class EntitySelectionStep extends Vue {
   @Prop({ required: true })
   conflictChecker!: (did: string) => boolean;
 
-  /** Project ID for context (giver) */
-  @Prop({ default: "" })
-  fromProjectId!: string;
-
-  /** Project ID for context (recipient) */
-  @Prop({ default: "" })
-  toProjectId!: string;
-
   /** Current giver entity for context */
   @Prop()
-  giver?: EntityData | null;
+  giver?: GiverReceiverInputInfo | null;
 
   /** Current receiver entity for context */
   @Prop()
-  receiver?: EntityData | null;
-
-  /** Form field values to preserve when navigating to "Show All" */
-  @Prop({ default: "" })
-  description!: string;
-
-  @Prop({ default: "0" })
-  amountInput!: string;
-
-  @Prop({ default: "HUR" })
-  unitCode!: string;
-
-  /** Offer ID for context when fulfilling an offer */
-  @Prop({ default: "" })
-  offerId!: string;
+  receiver?: GiverReceiverInputInfo | null;
 
   /** Notification function from parent component */
   @Prop()
   notify?: (notification: NotificationIface, timeout?: number) => void;
 
+  // initializing based on a Prop doesn't work here; see "mounted()"
+  newGiverEntityType: "person" | "project" = "person";
+  newRecipientEntityType: "person" | "project" = "person";
+
   /**
    * CSS classes for the cancel button
    */
@@ -195,11 +152,10 @@ export default class EntitySelectionStep extends Vue {
    * Whether to show projects in the grid
    */
   get shouldShowProjects(): boolean {
-    // When editing an entity, show the appropriate entity type for that entity
     if (this.stepType === "giver") {
-      return this.giverEntityType === "project";
+      return this.newGiverEntityType === "project";
     } else if (this.stepType === "recipient") {
-      return this.recipientEntityType === "project";
+      return this.newRecipientEntityType === "project";
     }
     return false;
   }
@@ -222,6 +178,13 @@ export default class EntitySelectionStep extends Vue {
     }
   }
 
+  async mounted(): Promise<void> {
+    this.newGiverEntityType = this.giver?.handleId ? "project" : "person";
+    this.newRecipientEntityType = this.receiver?.handleId
+      ? "project"
+      : "person";
+  }
+
   /**
    * Handle entity selection from EntityGrid
    */
@@ -236,7 +199,13 @@ export default class EntitySelectionStep extends Vue {
    * Handle toggle entity type button click
    */
   handleToggleEntityType(): void {
-    this.emitToggleEntityType();
+    if (this.stepType === "giver") {
+      this.newGiverEntityType =
+        this.newGiverEntityType === "person" ? "project" : "person";
+    } else if (this.stepType === "recipient") {
+      this.newRecipientEntityType =
+        this.newRecipientEntityType === "person" ? "project" : "person";
+    }
   }
 
   /**
@@ -259,11 +228,6 @@ export default class EntitySelectionStep extends Vue {
   emitCancel(): void {
     // No return value needed
   }
-
-  @Emit("toggle-entity-type")
-  emitToggleEntityType(): void {
-    // No return value needed
-  }
 }
 </script>
 

src/components/EntitySummaryButton.vue

@@ -50,16 +50,7 @@ import EntityIcon from "./EntityIcon.vue";
 import ProjectIcon from "./ProjectIcon.vue";
 import { Contact } from "../db/tables/contacts";
 import { UNNAMED_ENTITY_NAME } from "@/constants/entities";
-
-/**
- * Entity interface for both person and project entities
- */
-interface EntityData {
-  did?: string;
-  handleId?: string;
-  name?: string;
-  image?: string;
-}
+import { GiverReceiverInputInfo } from "@/libs/util";
 
 /**
  * EntitySummaryButton - Displays selected entity with edit capability
@@ -81,11 +72,7 @@ interface EntityData {
 export default class EntitySummaryButton extends Vue {
   /** Entity data to display */
   @Prop({ required: true })
-  entity!: EntityData | Contact | null;
-
-  /** Type of entity: 'person' or 'project' */
-  @Prop({ required: true })
-  entityType!: "person" | "project";
+  entity!: GiverReceiverInputInfo | Contact | null;
 
   /** Display label for the entity role */
   @Prop({ required: true })
@@ -98,9 +85,13 @@ export default class EntitySummaryButton extends Vue {
   @Prop({ type: Function, default: () => {} })
   onEditRequested!: (data: {
     entityType: string;
-    entity: EntityData | Contact | null;
+    entity: GiverReceiverInputInfo | Contact | null;
   }) => void | Promise<void>;
 
+  get entityType(): string {
+    return this.entity && "handleId" in this.entity ? "project" : "person";
+  }
+
   /**
    * CSS classes for the main container
    */

src/components/GiftDetailsStep.vue

@@ -14,7 +14,6 @@ control over updates and validation * * @author Matthew Raymer */
       <!-- Giver Button -->
       <EntitySummaryButton
         :entity="giver"
-        :entity-type="giverEntityType"
         :label="giverLabel"
         :on-edit-requested="handleEditGiver"
       />
@@ -22,7 +21,6 @@ control over updates and validation * * @author Matthew Raymer */
       <!-- Recipient Button -->
       <EntitySummaryButton
         :entity="receiver"
-        :entity-type="recipientEntityType"
         :label="recipientLabel"
         :on-edit-requested="handleEditRecipient"
       />
@@ -104,17 +102,7 @@ import { Component, Prop, Vue, Watch, Emit } from "vue-facing-decorator";
 import EntitySummaryButton from "./EntitySummaryButton.vue";
 import AmountInput from "./AmountInput.vue";
 import { RouteLocationRaw } from "vue-router";
-import { logger } from "@/utils/logger";
-
-/**
- * Entity data interface for giver/receiver
- */
-interface EntityData {
-  did?: string;
-  handleId?: string;
-  name?: string;
-  image?: string;
-}
+import { GiverReceiverInputInfo } from "@/libs/util";
 
 /**
  * GiftDetailsStep - Complete step 2 gift details form interface
@@ -140,19 +128,11 @@ interface EntityData {
 export default class GiftDetailsStep extends Vue {
   /** Giver entity data */
   @Prop({ required: true })
-  giver!: EntityData | null;
+  giver!: GiverReceiverInputInfo | null;
 
   /** Receiver entity data */
   @Prop({ required: true })
-  receiver!: EntityData | null;
-
-  /** Type of giver entity: 'person' or 'project' */
-  @Prop({ required: true })
-  giverEntityType!: "person" | "project";
-
-  /** Type of recipient entity: 'person' or 'project' */
-  @Prop({ required: true })
-  recipientEntityType!: "person" | "project";
+  receiver!: GiverReceiverInputInfo | null;
 
   /** Gift description */
   @Prop({ default: "" })
@@ -212,6 +192,14 @@ export default class GiftDetailsStep extends Vue {
   private localAmount: number = 0;
   private localUnitCode: string = "HUR";
 
+  get giverEntityType(): string {
+    return this.giver?.handleId ? "project" : "person";
+  }
+
+  get recipientEntityType(): string {
+    return this.receiver?.handleId ? "project" : "person";
+  }
+
   /**
    * CSS classes for the photo & more options link
    */
@@ -290,20 +278,12 @@ export default class GiftDetailsStep extends Vue {
       query: {
         amountInput: this.localAmount.toString(),
         description: this.localDescription,
-        giverDid:
-          this.giverEntityType === "person" ? this.giver?.did : undefined,
+        giverDid: this.giver?.did,
         giverName: this.giver?.name,
         offerId: this.offerId,
-        fulfillsProjectId:
-          this.recipientEntityType === "project" ? this.toProjectId : undefined,
-        providerProjectId:
-          this.giverEntityType === "project"
-            ? this.giver?.handleId
-            : this.fromProjectId,
-        recipientDid:
-          this.recipientEntityType === "person"
-            ? this.receiver?.did
-            : undefined,
+        fulfillsProjectId: this.receiver?.handleId,
+        providerProjectId: this.giver?.handleId,
+        recipientDid: this.receiver?.did,
         recipientName: this.receiver?.name,
         unitCode: this.localUnitCode,
       },
@@ -323,10 +303,6 @@ export default class GiftDetailsStep extends Vue {
    * Calls the onUpdateAmount function prop for parent control
    */
   handleAmountChange(newAmount: number): void {
-    logger.debug("[GiftDetailsStep] handleAmountChange() called", {
-      oldAmount: this.localAmount,
-      newAmount,
-    });
     this.localAmount = newAmount;
     this.onUpdateAmount(newAmount);
   }
@@ -345,7 +321,7 @@ export default class GiftDetailsStep extends Vue {
    */
   handleEditGiver(_data: {
     entityType: string;
-    entity: EntityData | null;
+    entity: GiverReceiverInputInfo | null;
   }): void {
     this.emitEditEntity({
       entityType: "giver",
@@ -359,7 +335,7 @@ export default class GiftDetailsStep extends Vue {
    */
   handleEditRecipient(_data: {
     entityType: string;
-    entity: EntityData | null;
+    entity: GiverReceiverInputInfo | null;
   }): void {
     this.emitEditEntity({
       entityType: "recipient",
@@ -399,8 +375,8 @@ export default class GiftDetailsStep extends Vue {
   @Emit("edit-entity")
   emitEditEntity(data: {
     entityType: string;
-    currentEntity: EntityData | null;
-  }): { entityType: string; currentEntity: EntityData | null } {
+    currentEntity: GiverReceiverInputInfo | null;
+  }): { entityType: string; currentEntity: GiverReceiverInputInfo | null } {
     return data;
   }
 

src/components/GiftedDialog.vue

@@ -3,33 +3,20 @@
     <div
       class="dialog"
       data-testid="gifted-dialog"
-      :data-recipient-entity-type="currentRecipientEntityType"
+      :data-recipient-entity-type="recipientEntityType"
     >
       <!-- Step 1: Entity Selection -->
       <EntitySelectionStep
         v-show="firstStep"
         :step-type="stepType"
-        :giver-entity-type="currentGiverEntityType"
-        :recipient-entity-type="currentRecipientEntityType"
-        :show-projects="
-          currentGiverEntityType === 'project' ||
-          currentRecipientEntityType === 'project'
-        "
         :all-contacts="allContacts"
         :active-did="activeDid"
         :all-my-dids="allMyDids"
         :conflict-checker="wouldCreateConflict"
-        :from-project-id="fromProjectId"
-        :to-project-id="toProjectId"
         :giver="giver"
         :receiver="receiver"
-        :description="description"
-        :amount-input="amountInput"
-        :unit-code="unitCode"
-        :offer-id="offerId"
         :notify="$notify"
         @entity-selected="handleEntitySelected"
-        @toggle-entity-type="handleToggleEntityType"
         @cancel="cancel"
       />
 
@@ -38,8 +25,8 @@
         v-show="!firstStep"
         :giver="giver"
         :receiver="receiver"
-        :giver-entity-type="currentGiverEntityType"
-        :recipient-entity-type="currentRecipientEntityType"
+        :giver-entity-type="giverEntityType"
+        :recipient-entity-type="recipientEntityType"
         :description="description"
         :amount="parseFloat(amountInput) || 0"
         :unit-code="unitCode"
@@ -130,8 +117,6 @@ export default class GiftedDialog extends Vue {
   description = "";
   firstStep = true; // true = Step 1 (giver/recipient selection), false = Step 2 (amount/description)
   giver?: libsUtil.GiverReceiverInputInfo; // undefined means no identified giver agent
-  currentGiverEntityType: "person" | "project" = "person"; // Mutable version (can be toggled)
-  currentRecipientEntityType: "person" | "project" = "person"; // Mutable version (can be toggled)
   offerId = "";
   prompt = "";
   receiver?: libsUtil.GiverReceiverInputInfo;
@@ -143,12 +128,20 @@ export default class GiftedDialog extends Vue {
 
   didInfo = didInfo;
 
+  get giverEntityType(): string {
+    return this.giver && "handleId" in this.giver ? "project" : "person";
+  }
+
+  get recipientEntityType(): string {
+    return this.receiver && "handleId" in this.receiver ? "project" : "person";
+  }
+
   // Computed property to check if current selection would create a conflict
   get hasPersonConflict() {
     // Only check for conflicts when both entities are persons
     if (
-      this.currentGiverEntityType !== "person" ||
-      this.currentRecipientEntityType !== "person"
+      this.giverEntityType !== "person" ||
+      this.recipientEntityType !== "person"
     ) {
       return false;
     }
@@ -169,8 +162,8 @@ export default class GiftedDialog extends Vue {
   get hasProjectConflict() {
     // Only check for conflicts when both entities are projects
     if (
-      this.currentGiverEntityType !== "project" ||
-      this.currentRecipientEntityType !== "project"
+      this.giverEntityType !== "project" ||
+      this.recipientEntityType !== "project"
     ) {
       return false;
     }
@@ -187,39 +180,6 @@ export default class GiftedDialog extends Vue {
     return false;
   }
 
-  // Computed property to check if a contact or project would create a conflict when selected
-  wouldCreateConflict(identifier: string) {
-    // Check for person conflicts when both entities are persons
-    if (
-      this.currentGiverEntityType === "person" &&
-      this.currentRecipientEntityType === "person"
-    ) {
-      if (this.stepType === "giver") {
-        // If selecting as giver, check if it conflicts with current recipient
-        return this.receiver?.did === identifier;
-      } else if (this.stepType === "recipient") {
-        // If selecting as recipient, check if it conflicts with current giver
-        return this.giver?.did === identifier;
-      }
-    }
-
-    // Check for project conflicts when both entities are projects
-    if (
-      this.currentGiverEntityType === "project" &&
-      this.currentRecipientEntityType === "project"
-    ) {
-      if (this.stepType === "giver") {
-        // If selecting as giver, check if it conflicts with current recipient
-        return this.receiver?.handleId === identifier;
-      } else if (this.stepType === "recipient") {
-        // If selecting as recipient, check if it conflicts with current giver
-        return this.giver?.handleId === identifier;
-      }
-    }
-
-    return false;
-  }
-
   async open(
     giver?: libsUtil.GiverReceiverInputInfo,
     receiver?: libsUtil.GiverReceiverInputInfo,
@@ -238,9 +198,6 @@ export default class GiftedDialog extends Vue {
     this.amountInput = amountInput || "0";
     this.unitCode = unitCode || "HUR";
     this.callbackOnSuccess = callbackOnSuccess;
-    // Initialize current entity types from initial prop values
-    this.currentGiverEntityType = this.initialGiverEntityType;
-    this.currentRecipientEntityType = this.initialRecipientEntityType;
 
     try {
       const settings = await this.$accountSettings();
@@ -307,15 +264,47 @@ export default class GiftedDialog extends Vue {
     this.eraseValues();
   }
 
+  // Computed property to check if a contact or project would create a conflict when selected
+  wouldCreateConflict(identifier: string) {
+    // Check for person conflicts when both entities are persons
+    if (
+      this.giverEntityType === "person" &&
+      this.recipientEntityType === "person"
+    ) {
+      if (this.stepType === "giver") {
+        // If selecting as giver, check if it conflicts with current recipient
+        return this.receiver?.did === identifier;
+      } else if (this.stepType === "recipient") {
+        // If selecting as recipient, check if it conflicts with current giver
+        return this.giver?.did === identifier;
+      }
+    }
+
+    // Check for project conflicts when both entities are projects
+    if (
+      this.giverEntityType === "project" &&
+      this.recipientEntityType === "project"
+    ) {
+      if (this.stepType === "giver") {
+        // If selecting as giver, check if it conflicts with current recipient
+        return this.receiver?.handleId === identifier;
+      } else if (this.stepType === "recipient") {
+        // If selecting as recipient, check if it conflicts with current giver
+        return this.giver?.handleId === identifier;
+      }
+    }
+
+    return false;
+  }
+
   eraseValues() {
     this.description = "";
     this.giver = undefined;
+    this.receiver = undefined;
     this.amountInput = "0";
     this.prompt = "";
     this.unitCode = "HUR";
     this.firstStep = true;
-    // Reset to initial prop values
-    this.currentGiverEntityType = this.initialGiverEntityType;
   }
 
   async confirm() {
@@ -403,29 +392,38 @@ export default class GiftedDialog extends Vue {
       let providerPlanHandleId: string | undefined;
 
       if (
-        this.currentGiverEntityType === "project" &&
-        this.currentRecipientEntityType === "person"
+        this.giverEntityType === "project" &&
+        this.recipientEntityType === "person"
       ) {
         // Project-to-person gift
-        fromDid = undefined; // No person giver
-        toDid = recipientDid as string; // Person recipient
-        fulfillsProjectHandleId = undefined; // No project recipient
-        providerPlanHandleId = this.giver?.handleId; // Project giver
+        fromDid = undefined;
+        toDid = recipientDid as string;
+        fulfillsProjectHandleId = undefined;
+        providerPlanHandleId = this.giver?.handleId;
       } else if (
-        this.currentGiverEntityType === "person" &&
-        this.currentRecipientEntityType === "project"
+        this.giverEntityType === "person" &&
+        this.recipientEntityType === "project"
       ) {
         // Person-to-project gift
-        fromDid = giverDid as string; // Person giver
-        toDid = undefined; // No person recipient
-        fulfillsProjectHandleId = this.toProjectId; // Project recipient
-        providerPlanHandleId = undefined; // No project giver
-      } else {
+        fromDid = giverDid as string;
+        toDid = undefined;
+        fulfillsProjectHandleId = this.receiver?.handleId;
+        providerPlanHandleId = undefined;
+      } else if (
+        this.giverEntityType === "person" &&
+        this.recipientEntityType === "person"
+      ) {
         // Person-to-person gift
         fromDid = giverDid as string;
         toDid = recipientDid as string;
         fulfillsProjectHandleId = undefined;
         providerPlanHandleId = undefined;
+      } else {
+        // Project-to-project gift
+        fromDid = undefined;
+        toDid = undefined;
+        fulfillsProjectHandleId = this.receiver?.handleId;
+        providerPlanHandleId = this.giver?.handleId;
       }
 
       const result = await createAndSubmitGive(
@@ -496,7 +494,16 @@ export default class GiftedDialog extends Vue {
     this.safeNotify.info(libsUtil.PRIVACY_MESSAGE, TIMEOUTS.MODAL);
   }
 
-  selectGiver(contact?: Contact) {
+  goBackToStep1(step: string) {
+    this.stepType = step;
+    this.firstStep = true;
+  }
+
+  moveToStep2() {
+    this.firstStep = false;
+  }
+
+  selectGiverPerson(contact?: Contact) {
     if (contact) {
       this.giver = {
         did: contact.did,
@@ -514,33 +521,16 @@ export default class GiftedDialog extends Vue {
     this.firstStep = false;
   }
 
-  goBackToStep1(step: string) {
-    this.stepType = step;
-    this.firstStep = true;
-  }
-
-  moveToStep2() {
-    this.firstStep = false;
-  }
-
-  selectProject(project: PlanData) {
+  selectGiverProject(project: PlanData) {
     this.giver = {
-      did: project.handleId,
       name: project.name,
       image: project.image,
       handleId: project.handleId,
     };
-    // Only set receiver to "You" if no receiver has been selected yet
-    if (!this.receiver || !this.receiver.did) {
-      this.receiver = {
-        did: this.activeDid,
-        name: "You",
-      };
-    }
     this.firstStep = false;
   }
 
-  selectRecipient(contact?: Contact) {
+  selectRecipientPerson(contact?: Contact) {
     if (contact) {
       this.receiver = {
         did: contact.did,
@@ -560,7 +550,6 @@ export default class GiftedDialog extends Vue {
 
   selectRecipientProject(project: PlanData) {
     this.receiver = {
-      did: project.handleId,
       name: project.name,
       image: project.image,
       handleId: project.handleId,
@@ -568,32 +557,6 @@ export default class GiftedDialog extends Vue {
     this.firstStep = false;
   }
 
-  // Computed property for the query parameters
-  get giftedDetailsQuery() {
-    return {
-      amountInput: this.amountInput,
-      description: this.description,
-      giverDid:
-        this.currentGiverEntityType === "person" ? this.giver?.did : undefined,
-      giverName: this.giver?.name,
-      offerId: this.offerId,
-      fulfillsProjectId:
-        this.currentRecipientEntityType === "project"
-          ? this.toProjectId
-          : undefined,
-      providerProjectId:
-        this.currentGiverEntityType === "project"
-          ? this.giver?.handleId
-          : this.fromProjectId,
-      recipientDid:
-        this.currentRecipientEntityType === "person"
-          ? this.receiver?.did
-          : undefined,
-      recipientName: this.receiver?.name,
-      unitCode: this.unitCode,
-    };
-  }
-
   // New event handlers for component integration
 
   /**
@@ -610,14 +573,14 @@ export default class GiftedDialog extends Vue {
       // Apply DID-based logic for person entities
       const processedContact = this.processPersonEntity(contact);
       if (entity.stepType === "giver") {
-        this.selectGiver(processedContact);
+        this.selectGiverPerson(processedContact);
       } else {
-        this.selectRecipient(processedContact);
+        this.selectRecipientPerson(processedContact);
       }
     } else if (entity.type === "project") {
       const project = entity.data as PlanData;
       if (entity.stepType === "giver") {
-        this.selectProject(project);
+        this.selectGiverProject(project);
       } else {
         this.selectRecipientProject(project);
       }
@@ -659,24 +622,6 @@ export default class GiftedDialog extends Vue {
     this.confirm();
   }
 
-  /**
-   * Handle toggle entity type request from EntitySelectionStep
-   */
-  handleToggleEntityType() {
-    // Toggle the appropriate entity type based on current step
-    if (this.stepType === "giver") {
-      this.currentGiverEntityType =
-        this.currentGiverEntityType === "person" ? "project" : "person";
-      // Clear any selected giver when toggling
-      this.giver = undefined;
-    } else if (this.stepType === "recipient") {
-      this.currentRecipientEntityType =
-        this.currentRecipientEntityType === "person" ? "project" : "person";
-      // Clear any selected receiver when toggling
-      this.receiver = undefined;
-    }
-  }
-
   /**
    * Handle amount update from GiftDetailsStep
    */

src/components/MeetingExclusionGroups.vue

@@ -0,0 +1,279 @@
+<template>
+  <div>
+    <div v-for="group in groups" :key="group.id" class="mb-3">
+      <div
+        :class="[
+          'rounded-lg border p-3',
+          colorSet(group.colorIndex).bg,
+          colorSet(group.colorIndex).border,
+        ]"
+      >
+        <div class="flex items-center justify-between mb-2">
+          <div class="flex items-center gap-2 flex-1 min-w-0">
+            <span
+              :class="[
+                'w-3 h-3 rounded-full shrink-0',
+                colorSet(group.colorIndex).dot,
+              ]"
+            ></span>
+            <input
+              :value="group.name"
+              :disabled="disabled"
+              :class="[
+                'text-sm font-medium bg-transparent border-none',
+                'outline-none flex-1 min-w-0 placeholder-gray-400',
+                { 'cursor-default': disabled },
+              ]"
+              placeholder="Group name…"
+              @input="
+                updateGroupName(
+                  group.id,
+                  ($event.target as HTMLInputElement).value,
+                )
+              "
+            />
+          </div>
+          <button
+            :class="[
+              'transition-colors ml-2 shrink-0',
+              disabled
+                ? 'text-slate-300 cursor-not-allowed'
+                : 'text-slate-400 hover:text-red-600',
+            ]"
+            title="Delete group"
+            @click="disabled ? notifyLocked() : removeGroup(group.id)"
+          >
+            <font-awesome icon="trash-can" class="text-sm" />
+          </button>
+        </div>
+
+        <div class="flex flex-wrap gap-1.5 mb-2">
+          <span
+            v-for="did in group.memberDids"
+            :key="did"
+            :class="[
+              'inline-flex items-center gap-1 px-2 py-0.5 rounded-full text-xs',
+              colorSet(group.colorIndex).chip,
+            ]"
+          >
+            {{ getMemberName(did) }}
+            <button
+              :class="
+                disabled ? 'opacity-40 cursor-not-allowed' : 'hover:opacity-70'
+              "
+              @click="
+                disabled ? notifyLocked() : removeMemberFromGroup(group.id, did)
+              "
+            >
+              <font-awesome icon="xmark" class="text-xs" />
+            </button>
+          </span>
+          <span
+            v-if="group.memberDids.length === 0"
+            class="text-xs text-slate-400 italic"
+          >
+            No members yet
+          </span>
+        </div>
+
+        <div v-if="!disabled && addingToGroupId === group.id" class="mt-2">
+          <div
+            class="flex flex-wrap gap-1.5 p-2 bg-white bg-opacity-60 rounded border border-gray-200"
+          >
+            <button
+              v-for="member in availableMembersForGroup(group)"
+              :key="member.did"
+              class="inline-flex items-center gap-1 px-2 py-0.5 rounded-full text-xs bg-white border border-gray-300 hover:bg-gray-100 transition-colors"
+              @click="addMemberToGroup(group.id, member.did)"
+            >
+              <font-awesome icon="plus" class="text-xs text-green-600" />
+              {{ member.name }}
+            </button>
+            <span
+              v-if="availableMembersForGroup(group).length === 0"
+              class="text-xs text-slate-400 italic"
+            >
+              All members already assigned
+            </span>
+          </div>
+          <button
+            class="text-xs text-slate-500 mt-1"
+            @click="addingToGroupId = ''"
+          >
+            Done
+          </button>
+        </div>
+        <button
+          v-else
+          :class="[
+            'text-xs transition-colors',
+            disabled
+              ? 'text-slate-400 cursor-not-allowed'
+              : 'text-blue-600 hover:text-blue-800',
+          ]"
+          @click="disabled ? notifyLocked() : (addingToGroupId = group.id)"
+        >
+          <font-awesome icon="plus" class="text-xs" />
+          Add member
+        </button>
+      </div>
+    </div>
+
+    <button
+      :class="[
+        'text-sm transition-colors',
+        disabled
+          ? 'text-slate-400 cursor-not-allowed'
+          : 'text-blue-600 hover:text-blue-800',
+      ]"
+      @click="disabled ? notifyLocked() : addGroup()"
+    >
+      <font-awesome icon="plus" class="text-sm" />
+      New Group
+    </button>
+  </div>
+</template>
+
+<script lang="ts">
+import { Component, Vue, Prop, Emit } from "vue-facing-decorator";
+import { DoNotPairGroup } from "@/interfaces";
+import { createNotifyHelpers, TIMEOUTS } from "@/utils/notify";
+import { NotificationIface } from "@/constants/app";
+
+interface MemberInfo {
+  did: string;
+  name: string;
+}
+
+const GROUP_COLORS = [
+  {
+    bg: "bg-orange-50",
+    border: "border-orange-200",
+    dot: "bg-orange-400",
+    chip: "bg-orange-200 text-orange-800",
+  },
+  {
+    bg: "bg-purple-50",
+    border: "border-purple-200",
+    dot: "bg-purple-400",
+    chip: "bg-purple-200 text-purple-800",
+  },
+  {
+    bg: "bg-teal-50",
+    border: "border-teal-200",
+    dot: "bg-teal-400",
+    chip: "bg-teal-200 text-teal-800",
+  },
+  {
+    bg: "bg-pink-50",
+    border: "border-pink-200",
+    dot: "bg-pink-400",
+    chip: "bg-pink-200 text-pink-800",
+  },
+  {
+    bg: "bg-indigo-50",
+    border: "border-indigo-200",
+    dot: "bg-indigo-400",
+    chip: "bg-indigo-200 text-indigo-800",
+  },
+  {
+    bg: "bg-yellow-50",
+    border: "border-yellow-200",
+    dot: "bg-yellow-400",
+    chip: "bg-yellow-200 text-yellow-800",
+  },
+];
+
+@Component
+export default class MeetingExclusionGroups extends Vue {
+  $notify!: (notification: NotificationIface, timeout?: number) => void;
+  notify!: ReturnType<typeof createNotifyHelpers>;
+
+  @Prop({ required: true }) groups!: DoNotPairGroup[];
+  @Prop({ required: true }) availableMembers!: MemberInfo[];
+  @Prop({ default: false }) disabled!: boolean;
+
+  addingToGroupId = "";
+
+  created() {
+    this.notify = createNotifyHelpers(this.$notify);
+  }
+
+  notifyLocked(): void {
+    this.notify.warning(
+      "Erase the current matches before changing exclusion groups.",
+      TIMEOUTS.LONG,
+    );
+  }
+
+  colorSet(colorIndex: number): (typeof GROUP_COLORS)[0] {
+    return GROUP_COLORS[colorIndex % GROUP_COLORS.length];
+  }
+
+  getMemberName(did: string): string {
+    const member = this.availableMembers.find((m) => m.did === did);
+    return member?.name || did.substring(0, 16) + "…";
+  }
+
+  availableMembersForGroup(group: DoNotPairGroup): MemberInfo[] {
+    const allAssignedDids = new Set(this.groups.flatMap((g) => g.memberDids));
+    return this.availableMembers
+      .filter(
+        (m) => !allAssignedDids.has(m.did) || group.memberDids.includes(m.did),
+      )
+      .filter((m) => !group.memberDids.includes(m.did));
+  }
+
+  @Emit("update")
+  emitUpdate(): DoNotPairGroup[] {
+    return [...this.groups];
+  }
+
+  addGroup(): void {
+    const newGroup: DoNotPairGroup = {
+      id: Date.now().toString(36) + Math.random().toString(36).substring(2, 6),
+      name: "",
+      colorIndex: this.groups.length % GROUP_COLORS.length,
+      memberDids: [],
+    };
+    this.groups.push(newGroup);
+    this.addingToGroupId = newGroup.id;
+    this.emitUpdate();
+  }
+
+  removeGroup(groupId: string): void {
+    const idx = this.groups.findIndex((g) => g.id === groupId);
+    if (idx !== -1) {
+      this.groups.splice(idx, 1);
+      if (this.addingToGroupId === groupId) {
+        this.addingToGroupId = "";
+      }
+      this.emitUpdate();
+    }
+  }
+
+  updateGroupName(groupId: string, name: string): void {
+    const group = this.groups.find((g) => g.id === groupId);
+    if (group) {
+      group.name = name;
+      this.emitUpdate();
+    }
+  }
+
+  addMemberToGroup(groupId: string, did: string): void {
+    const group = this.groups.find((g) => g.id === groupId);
+    if (group && !group.memberDids.includes(did)) {
+      group.memberDids.push(did);
+      this.emitUpdate();
+    }
+  }
+
+  removeMemberFromGroup(groupId: string, did: string): void {
+    const group = this.groups.find((g) => g.id === groupId);
+    if (group) {
+      group.memberDids = group.memberDids.filter((d) => d !== did);
+      this.emitUpdate();
+    }
+  }
+}
+</script>

src/components/MeetingMemberMatch.vue

@@ -0,0 +1,249 @@
+<template>
+  <div class="group-onboard-match-display">
+    <!-- Loading -->
+    <div
+      v-if="isLoading"
+      class="flex items-center justify-center gap-2 py-6 text-slate-600"
+    >
+      <font-awesome icon="spinner" class="fa-spin-pulse" />
+    </div>
+
+    <!-- Error -->
+    <div
+      v-else-if="errorMessage"
+      class="rounded-lg border border-red-200 bg-red-50 px-4 py-3 text-red-700"
+    >
+      Inform the organizer that there was an error. {{ errorMessage }}
+    </div>
+
+    <!-- Matched person -->
+    <div
+      v-else-if="matchedPerson"
+      class="rounded-lg border border-slate-200 bg-white p-4 shadow-sm"
+    >
+      <h2 class="mb-3 font-bold text-slate-700">Your Current Match</h2>
+      <p v-if="myPair != null" class="mb-3 text-sm text-slate-600">
+        You are in Pair #{{ myPair.pairNumber }} with:
+      </p>
+      <div class="flex items-start gap-3">
+        <EntityIcon
+          :contact="matchedPersonContact"
+          class="!size-14 shrink-0 overflow-hidden rounded-full border border-slate-300 bg-white"
+        />
+        <div class="min-w-0 flex-1">
+          <p class="font-medium text-slate-900">
+            {{ matchedPerson.name || "(No name)" }}
+          </p>
+          <p class="mt-0.5 truncate text-xs text-slate-500">
+            {{ matchedPerson.did }}
+          </p>
+          <p
+            v-if="matchedPerson.description"
+            class="mt-2 line-clamp-3 text-sm text-slate-600"
+          >
+            {{ matchedPerson.description }}
+          </p>
+        </div>
+      </div>
+    </div>
+  </div>
+</template>
+
+<script lang="ts">
+import { Component, Vue, Prop, Watch } from "vue-facing-decorator";
+import {
+  errorStringForLog,
+  getHeaders,
+  serverMessageForUser,
+} from "@/libs/endorserServer";
+import { decryptMessage } from "@/libs/crypto";
+import { PlatformServiceMixin } from "@/utils/PlatformServiceMixin";
+import EntityIcon from "./EntityIcon.vue";
+import { Contact } from "@/db/tables/contacts";
+import { AxiosErrorResponse } from "@/interfaces";
+
+/** Participant from GET /api/partner/groupOnboardMatch pair */
+interface MatchPairParticipant {
+  issuerDid: string;
+  content: string;
+  description?: string;
+  decryptedContentObject?: {
+    name: string;
+    did: string;
+    isRegistered: boolean;
+  } | null;
+}
+
+interface MatchPair {
+  pairNumber: number;
+  similarity: number;
+  participants: MatchPairParticipant[];
+}
+
+/** Normalized matched person for display */
+interface MatchedPersonData {
+  name: string;
+  did: string;
+  isRegistered: boolean;
+  description?: string;
+}
+
+@Component({
+  components: {
+    EntityIcon,
+  },
+  mixins: [PlatformServiceMixin],
+})
+export default class GroupOnboardMatchDisplay extends Vue {
+  @Prop({ required: true })
+  meetingPassword!: string;
+
+  /** When provided, used to determine this person's match instead of calling groupOnboardMatch */
+  @Prop()
+  matchPairs?: MatchPair[] | null;
+
+  activeDid = "";
+  apiServer = "";
+  errorMessage = "";
+  isLoading = true;
+  matchedPerson: MatchedPersonData | null = null;
+  /** Pair that contains the current user (for similarity display if needed) */
+  myPair: MatchPair | null = null;
+
+  /** Contact-like object for EntityIcon from matched person */
+  get matchedPersonContact(): Contact | undefined {
+    if (!this.matchedPerson) return undefined;
+    return {
+      did: this.matchedPerson.did,
+      name: this.matchedPerson.name,
+    };
+  }
+
+  async created() {
+    const settings = await this.$accountSettings();
+    this.apiServer = settings?.apiServer || "";
+    // eslint-disable-next-line @typescript-eslint/no-explicit-any
+    const activeIdentity = await (this as any).$getActiveIdentity();
+    this.activeDid = activeIdentity?.activeDid || "";
+    await this.fetchMatches();
+  }
+
+  @Watch("meetingPassword")
+  async onPasswordChange() {
+    if (
+      this.meetingPassword &&
+      (this.matchPairs != null || (this.apiServer && this.activeDid))
+    ) {
+      await this.fetchMatches();
+    }
+  }
+
+  @Watch("matchPairs")
+  async onMatchPairsChange() {
+    if (this.activeDid && this.meetingPassword) {
+      await this.fetchMatches();
+    }
+  }
+
+  // Note that this is called externally by MeetingMembersList when user triggers a refresh
+  async fetchMatches(): Promise<void> {
+    const usePropPairs =
+      this.matchPairs != null &&
+      Array.isArray(this.matchPairs) &&
+      this.matchPairs.length > 0;
+    const needApi = !usePropPairs;
+
+    if (
+      needApi &&
+      (!this.meetingPassword?.trim() || !this.apiServer || !this.activeDid)
+    ) {
+      this.isLoading = false;
+      this.matchedPerson = null;
+      this.myPair = null;
+      this.errorMessage = "";
+      return;
+    }
+    if (usePropPairs && (!this.meetingPassword?.trim() || !this.activeDid)) {
+      this.isLoading = false;
+      this.matchedPerson = null;
+      this.myPair = null;
+      this.errorMessage = "";
+      return;
+    }
+
+    this.isLoading = true;
+    this.errorMessage = "";
+    this.matchedPerson = null;
+    this.myPair = null;
+
+    try {
+      let pairs: MatchPair[] | null = null;
+      if (usePropPairs) {
+        // Shallow-copy so we can set decryptedContentObject without mutating the prop
+        pairs = (this.matchPairs ?? []).map((p) => ({
+          ...p,
+          participants: p.participants.map((part) => ({ ...part })),
+        }));
+      } else {
+        const headers = await getHeaders(this.activeDid);
+        const response = await this.axios.get(
+          `${this.apiServer}/api/partner/groupOnboardMatch`,
+          { headers },
+        );
+        pairs = response?.data?.data?.pairs ?? null;
+      }
+
+      if (!Array.isArray(pairs) || pairs.length === 0) {
+        this.isLoading = false;
+        return;
+      }
+
+      // Decrypt each participant's content and find the pair containing this user
+      for (const pair of pairs) {
+        if (!pair.participants || pair.participants.length !== 2) continue;
+
+        for (const participant of pair.participants) {
+          try {
+            const decrypted = await decryptMessage(
+              participant.content,
+              this.meetingPassword,
+            );
+            participant.decryptedContentObject = JSON.parse(decrypted);
+          } catch {
+            participant.decryptedContentObject = null;
+          }
+        }
+
+        const myIndex = pair.participants.findIndex(
+          (p) => p.issuerDid === this.activeDid,
+        );
+        if (myIndex === -1) continue;
+
+        this.myPair = pair;
+        const other = pair.participants[1 - myIndex];
+        const obj = other.decryptedContentObject;
+        this.matchedPerson = {
+          name: obj?.name ?? "",
+          did: obj?.did ?? other.issuerDid,
+          isRegistered: !!obj?.isRegistered,
+          description: other.description,
+        };
+        break;
+      }
+
+      this.isLoading = false;
+    } catch (error) {
+      this.$logAndConsole(
+        "Error fetching group onboard match: " + errorStringForLog(error),
+        true,
+      );
+      this.errorMessage =
+        serverMessageForUser(error as unknown as AxiosErrorResponse) ||
+        "Failed to load your match.";
+      this.matchedPerson = null;
+      this.myPair = null;
+      this.isLoading = false;
+    }
+  }
+}
+</script>

src/components/MeetingMembersList.vue

@@ -36,6 +36,15 @@
             <font-awesome icon="circle-minus" class="text-rose-500 text-sm" />
             to add/remove them to/from the meeting.
           </li>
+          <li
+            v-if="
+              membersToShow().length > 0 && showOrganizerTools && isOrganizer
+            "
+          >
+            Click
+            <font-awesome icon="ban" class="text-slate-500 text-sm" />
+            to exclude someone from matching.
+          </li>
           <li
             v-if="
               membersToShow().length > 0 && getNonContactMembers().length > 0
@@ -47,11 +56,18 @@
           </li>
         </ul>
 
-        <div class="flex justify-between">
+        <MeetingMemberMatch
+          ref="memberMatch"
+          :match-pairs="matchPairs"
+          :meeting-password="password || ''"
+          class="mt-4"
+        />
+
+        <div class="flex justify-between mt-4">
           <!-- 
-        always have at least one refresh button even without members in case the organizer 
-         changes the password 
-         -->
+          always have at least one refresh button even without members in case the organizer 
+          changes the password 
+          -->
           <button
             class="text-sm bg-gradient-to-b from-slate-400 to-slate-700 shadow-[inset_0_-1px_0_0_rgba(0,0,0,0.5)] text-white px-3 py-1.5 rounded-md"
             title="Refresh members list now"
@@ -75,6 +91,8 @@
                 'bg-blue-50 border-t border-blue-300 -mt-[1px]':
                   !member.member.admitted &&
                   (isOrganizer || member.did === activeDid),
+                'bg-amber-50 opacity-60':
+                  member.member.admitted && excludedDids.includes(member.did),
               },
               { 'border-slate-300': member.member.admitted },
             ]"
@@ -88,6 +106,9 @@
                       'text-slate-500':
                         !member.member.admitted &&
                         (isOrganizer || member.did === activeDid),
+                      'line-through text-slate-400':
+                        member.member.admitted &&
+                        excludedDids.includes(member.did),
                     },
                   ]"
                 >
@@ -161,8 +182,31 @@
                 v-if="
                   showOrganizerTools && isOrganizer && member.did !== activeDid
                 "
-                class="flex items-center gap-1.5"
+                class="flex items-center gap-6"
               >
+                <button
+                  v-if="member.member.admitted"
+                  :class="[
+                    'btn-exclusion-toggle',
+                    exclusionLocked
+                      ? excludedDids.includes(member.did)
+                        ? 'text-amber-400 opacity-50'
+                        : 'text-slate-300 opacity-50'
+                      : excludedDids.includes(member.did)
+                        ? 'text-amber-600'
+                        : 'text-slate-500',
+                  ]"
+                  :title="
+                    exclusionLocked
+                      ? 'Erase matches to change exclusions'
+                      : excludedDids.includes(member.did)
+                        ? 'Include in matching'
+                        : 'Exclude from matching'
+                  "
+                  @click="handleExclusionClick(member.did)"
+                >
+                  <font-awesome icon="ban" />
+                </button>
                 <button
                   :class="
                     member.member.admitted
@@ -198,9 +242,9 @@
 
         <div v-if="membersToShow().length > 0" class="flex justify-between">
           <!-- 
-        always have at least one refresh button even without members in case the organizer 
-         changes the password 
-         -->
+          always have at least one refresh button even without members in case the organizer 
+          changes the password 
+          -->
           <button
             class="text-sm bg-gradient-to-b from-slate-400 to-slate-700 shadow-[inset_0_-1px_0_0_rgba(0,0,0,0.5)] text-white px-3 py-1.5 rounded-md"
             title="Refresh members list now"
@@ -246,10 +290,13 @@ import {
 } from "@/libs/endorserServer";
 import { decryptMessage } from "@/libs/crypto";
 import { Contact } from "@/db/tables/contacts";
-import { MemberData } from "@/interfaces";
+import { MemberData, MatchPair } from "@/interfaces";
 import { PlatformServiceMixin } from "@/utils/PlatformServiceMixin";
 import { createNotifyHelpers, TIMEOUTS } from "@/utils/notify";
 import BulkMembersDialog from "./BulkMembersDialog.vue";
+import MeetingMemberMatch from "./MeetingMemberMatch.vue";
+
+const AUTO_REFRESH_INTERVAL = 15;
 
 interface Member {
   admitted: boolean;
@@ -257,6 +304,7 @@ interface Member {
   memberId: number;
 }
 
+// there's a similar structure in OnboardMeetingSetupView.vue but without the member
 interface DecryptedMember {
   member: Member;
   name: string;
@@ -267,16 +315,20 @@ interface DecryptedMember {
 @Component({
   components: {
     BulkMembersDialog,
+    MeetingMemberMatch,
   },
   mixins: [PlatformServiceMixin],
 })
-export default class MembersList extends Vue {
+export default class MeetingMembersList extends Vue {
   $notify!: (notification: NotificationIface, timeout?: number) => void;
 
   notify!: ReturnType<typeof createNotifyHelpers>;
 
   @Prop({ required: true }) password!: string;
   @Prop({ default: false }) showOrganizerTools!: boolean;
+  @Prop({ default: null }) matchPairs!: MatchPair[] | null;
+  @Prop({ default: () => [] }) excludedDids!: string[];
+  @Prop({ default: false }) exclusionLocked!: boolean;
 
   // Emit methods using @Emit decorator
   @Emit("error")
@@ -284,6 +336,16 @@ export default class MembersList extends Vue {
     return message;
   }
 
+  @Emit("toggle-exclusion")
+  emitToggleExclusion(did: string) {
+    return did;
+  }
+
+  @Emit("members-loaded")
+  emitMembersLoaded() {
+    return;
+  }
+
   contacts: Array<Contact> = [];
   decryptedMembers: DecryptedMember[] = [];
   firstName = "";
@@ -296,7 +358,7 @@ export default class MembersList extends Vue {
   apiServer = "";
 
   // Auto-refresh functionality
-  countdownTimer = 10;
+  countdownTimer = AUTO_REFRESH_INTERVAL;
   autoRefreshInterval: NodeJS.Timeout | null = null;
   lastRefreshTime = 0;
   previousMemberDidsIgnored: string[] = [];
@@ -345,6 +407,7 @@ export default class MembersList extends Vue {
       this.emitError(serverMessageForUser(error) || "Failed to fetch members.");
     } finally {
       this.isLoading = false;
+      this.emitMembersLoaded();
     }
   }
 
@@ -486,7 +549,7 @@ export default class MembersList extends Vue {
 
   informAboutAdmission() {
     this.notify.info(
-      "This is to register people in Time Safari and to admit them to the meeting. A (+) symbol means they are not yet admitted and you can register and admit them. A (-) symbol means you can remove them, but they will stay registered.",
+      "Click the 'ban' button to exclude from matching. The '+/-' buttons are for admissions: A blue (+) symbol means they are not yet admitted and you can register and admit them. A red (-) symbol means you can remove them, but they will stay registered.",
       TIMEOUTS.VERY_LONG,
     );
   }
@@ -544,8 +607,17 @@ export default class MembersList extends Vue {
    * (admit pending members for organizers, add to contacts for non-organizers)
    */
   async refreshData(bypassPromptIfAllWereIgnored = true) {
-    // Force refresh both contacts and members
+    // Force refresh of many things
+
+    // Matches may have been generated or erased
+    (
+      this.$refs.memberMatch as InstanceType<typeof MeetingMemberMatch>
+    )?.fetchMatches();
+
+    // Someone may have been added to their contacts
     this.contacts = await this.$getAllContacts();
+
+    // The members list may have changed
     await this.fetchMembers();
 
     const pendingMembers = this.isOrganizer
@@ -724,25 +796,42 @@ export default class MembersList extends Vue {
     }
   }
 
+  getAdmittedMembers(): Array<{ did: string; name: string }> {
+    return this.decryptedMembers
+      .filter((m) => m.member.admitted)
+      .map((m) => ({ did: m.did, name: m.name }));
+  }
+
+  handleExclusionClick(did: string): void {
+    if (this.exclusionLocked) {
+      this.notify.warning(
+        "Erase the current matches before changing exclusions.",
+        TIMEOUTS.LONG,
+      );
+      return;
+    }
+    this.emitToggleExclusion(did);
+  }
+
   startAutoRefresh() {
     this.stopAutoRefresh();
     this.lastRefreshTime = Date.now();
-    this.countdownTimer = 10;
+    this.countdownTimer = AUTO_REFRESH_INTERVAL;
 
     this.autoRefreshInterval = setInterval(() => {
       const now = Date.now();
       const timeSinceLastRefresh = (now - this.lastRefreshTime) / 1000;
 
-      if (timeSinceLastRefresh >= 10) {
+      if (timeSinceLastRefresh >= AUTO_REFRESH_INTERVAL) {
         // Time to refresh
         this.refreshData();
         this.lastRefreshTime = now;
-        this.countdownTimer = 10;
+        this.countdownTimer = AUTO_REFRESH_INTERVAL;
       } else {
         // Update countdown
         this.countdownTimer = Math.max(
           0,
-          Math.round(10 - timeSinceLastRefresh),
+          Math.round(AUTO_REFRESH_INTERVAL - timeSinceLastRefresh),
         );
       }
     }, 1000); // Update every second
@@ -789,6 +878,11 @@ export default class MembersList extends Vue {
     transition-colors;
 }
 
+.btn-exclusion-toggle {
+  /* stylelint-disable-next-line at-rule-no-unknown */
+  @apply text-lg transition-colors;
+}
+
 .btn-admission-remove {
   /* stylelint-disable-next-line at-rule-no-unknown */
   @apply text-lg text-rose-500 hover:text-rose-700 

src/components/OnboardingDialog.vue

@@ -24,7 +24,7 @@
   <div v-if="visible" class="dialog-overlay">
     <div v-if="page === OnboardPage.Home" class="dialog">
       <h1 class="text-xl font-bold text-center mb-4 relative">
-        Welcome to Time Safari
+        Welcome to {{ AppString.APP_NAME }}
         <br />
         - Showcase Impact & Magnify Time
         <div :class="closeButtonClasses" @click="onClickClose(true)">
@@ -199,7 +199,7 @@
 import { Component, Vue } from "vue-facing-decorator";
 import { Router } from "vue-router";
 
-import { NotificationIface } from "../constants/app";
+import { AppString, NotificationIface } from "../constants/app";
 import { OnboardPage } from "../libs/util";
 import { PlatformServiceMixin } from "@/utils/PlatformServiceMixin";
 
@@ -226,6 +226,13 @@ export default class OnboardingDialog extends Vue {
     return OnboardPage;
   }
 
+  /**
+   * Returns AppString enum for template access
+   */
+  get AppString() {
+    return AppString;
+  }
+
   /**
    * CSS classes for primary action buttons (blue gradient)
    */

src/components/PushNotificationPermission.vue

@@ -14,75 +14,65 @@
       <div
         class="flex w-11/12 max-w-sm mx-auto mb-3 overflow-hidden bg-white rounded-lg shadow-lg"
       >
-        <div class="w-full px-6 py-6 text-slate-900 text-center">
-          <p v-if="isSystemReady" class="text-lg mb-4">
+        <div class="w-full px-6 py-6 text-slate-900">
+          <h1 v-if="isSystemReady" class="text-center font-bold mb-4">
             <span v-if="isDailyCheck">
               Would you like to be notified of new activity, up to once a day?
             </span>
             <span v-else>
               Would you like to get a reminder message once a day?
             </span>
-          </p>
-          <p v-else class="text-lg mb-4">
+          </h1>
+          <h1 v-else class="text-center font-bold mb-4">
             {{ waitingMessage }}
             <font-awesome icon="spinner" spin />
-          </p>
+          </h1>
 
           <div v-if="canShowNotificationForm">
             <div v-if="isDailyCheck">
-              <span>Yes, send me a message when there is new data for me</span>
+              <span
+                ><b>Yes</b>, send me a message when there is new data for
+                me</span
+              >
             </div>
             <div v-else>
-              <span>Yes, send me this message:</span>
+              <span class="text-slate-500 text-sm font-bold"
+                >Send me this message:</span
+              >
               <!-- eslint-disable -->
               <textarea
                 type="text"
                 id="push-message"
                 v-model="messageInput"
-                class="rounded border border-slate-400 mt-2 px-2 py-2 w-full"
+                class="rounded border border-slate-400 mt-2 p-2 w-full"
                 maxlength="100"
               ></textarea
               >
-              <!-- eslint-enable -->
-              <span class="w-full flex justify-between text-xs text-slate-500">
-                <span></span>
+              <div class="text-xs text-slate-500">
                 <span>(100 characters max)</span>
-              </span>
+              </div>
             </div>
 
-            <div>
-              <span class="flex flex-row justify-center">
-                <span class="mt-2">... at: </span>
-                <input
-                  v-model="hourInput"
-                  type="number"
-                  class="rounded-l border border-r-0 border-slate-400 ml-2 mt-2 px-2 py-2 text-center w-20"
-                  @change="checkHourInput"
-                />
-                <input
-                  v-model="minuteInput"
-                  type="number"
-                  class="border border-slate-400 mt-2 px-2 py-2 text-center w-20"
-                  @change="checkMinuteInput"
-                />
-                <span
-                  class="rounded-r border border-slate-400 bg-slate-200 text-center text-blue-500 mt-2 px-2 py-2 w-20"
-                  @click="toggleHourAm"
-                >
-                  <span>{{ amPmLabel }} <font-awesome :icon="amPmIcon" /></span>
-                </span>
-              </span>
+            <div class="mt-2 mb-4 flex items-center gap-2">
+              <label for="time" class="text-slate-500 text-sm font-bold">At this time:</label>
+              <input
+                v-model="timeValue"
+                type="time"
+                id="time"
+                class="!px-4 !py-4 text-md bg-white border border-slate-400 rounded"
+                required
+              />
             </div>
             <button
               class="block w-full text-center text-md font-bold uppercase bg-blue-600 text-white mt-2 px-2 py-2 rounded-md"
               @click="handleTurnOnNotifications"
             >
-              Turn on Daily Message
+              {{ isDailyCheck ? "Turn on New Activity Notifications" : "Turn on Daily Reminder" }}
             </button>
           </div>
 
           <button
-            class="block w-full text-center text-md font-bold uppercase bg-slate-600 text-white mt-4 px-2 py-2 rounded-md"
+            class="block w-full text-center text-md font-bold uppercase bg-slate-600 text-white mt-2 px-2 py-2 rounded-md"
             @click="close()"
           >
             No, Not Now
@@ -95,6 +85,7 @@
 
 <script lang="ts">
 import { Component, Vue } from "vue-facing-decorator";
+import { Capacitor } from "@capacitor/core";
 
 import { DEFAULT_PUSH_SERVER, NotificationIface } from "../constants/app";
 import {
@@ -104,6 +95,7 @@ import {
   NOTIFY_PUSH_PERMISSION_ERROR,
   NOTIFY_PUSH_SETUP_UNDERWAY,
   NOTIFY_PUSH_SUCCESS,
+  NOTIFY_PUSH_SUCCESS_NEW_ACTIVITY,
   NOTIFY_PUSH_SETUP_ERROR,
   NOTIFY_PUSH_SUBSCRIPTION_ERROR,
   PUSH_NOTIFICATION_TIMEOUT_SHORT,
@@ -116,6 +108,7 @@ import * as libsUtil from "../libs/util";
 import { logger } from "../utils/logger";
 import { PlatformServiceMixin } from "../utils/PlatformServiceMixin";
 import { UNNAMED_ENTITY_NAME } from "@/constants/entities";
+import { NotificationService } from "@/services/notifications";
 
 // Example interface for error
 interface ErrorResponse {
@@ -164,16 +157,54 @@ export default class PushNotificationPermission extends Vue {
   messageInput = "";
   minuteInput = "00";
   pushType = "";
+  /** When true, dialog only returns time/message to parent; parent does cancel+schedule (avoids double schedule on edit). */
+  skipScheduleForOpen = false;
+  /** When set (e.g. 10), passed to plugin for dev/test fast rollover. */
+  rolloverIntervalMinutesForSchedule: number | undefined = undefined;
   serviceWorkerReady = false;
   vapidKey = "";
 
+  /**
+   * Check if running on native platform (iOS/Android)
+   */
+  private get isNativePlatform(): boolean {
+    return Capacitor.isNativePlatform();
+  }
+
   async open(
     pushType: string,
     callback?: (success: boolean, time: string, message?: string) => void,
+    options?: { skipSchedule?: boolean; rolloverIntervalMinutes?: number },
   ) {
     this.callback = callback || this.callback;
     this.isVisible = true;
     this.pushType = pushType;
+    this.skipScheduleForOpen = options?.skipSchedule ?? false;
+    this.rolloverIntervalMinutesForSchedule = options?.rolloverIntervalMinutes;
+
+    // Native platforms: Skip web push initialization
+    if (this.isNativePlatform) {
+      logger.debug(
+        "[PushNotificationPermission] Native platform detected, skipping web push initialization",
+      );
+      // For native, we don't need VAPID or service worker
+      this.serviceWorkerReady = true;
+      this.vapidKey = "native"; // Placeholder for computed properties
+
+      // Set up message input based on push type
+      if (this.pushType === this.DIRECT_PUSH_TITLE) {
+        this.messageInput = this.notificationMessagePlaceholder;
+        // focus on the message input
+        setTimeout(function () {
+          document.getElementById("push-message")?.focus();
+        }, 100);
+      } else {
+        this.messageInput = "";
+      }
+      return;
+    }
+
+    // Web platform: Initialize web push (existing logic)
     try {
       const settings = await this.$accountSettings();
       let pushUrl = DEFAULT_PUSH_SERVER;
@@ -360,36 +391,6 @@ export default class PushNotificationPermission extends Vue {
     );
   }
 
-  private checkHourInput() {
-    const hourNum = parseInt(this.hourInput);
-    if (isNaN(hourNum)) {
-      this.hourInput = "12";
-    } else if (hourNum < 1) {
-      this.hourInput = "12";
-      this.hourAm = !this.hourAm;
-    } else if (hourNum > 12) {
-      this.hourInput = "1";
-      this.hourAm = !this.hourAm;
-    } else {
-      this.hourInput = hourNum.toString();
-    }
-  }
-
-  private checkMinuteInput() {
-    const minuteNum = parseInt(this.minuteInput);
-    if (isNaN(minuteNum)) {
-      this.minuteInput = "00";
-    } else if (minuteNum < 0) {
-      this.minuteInput = "59";
-    } else if (minuteNum < 10) {
-      this.minuteInput = "0" + minuteNum;
-    } else if (minuteNum > 59) {
-      this.minuteInput = "00";
-    } else {
-      this.minuteInput = minuteNum.toString();
-    }
-  }
-
   private async turnOnNotifications() {
     let notifyCloser = () => {};
     return this.askPermission()
@@ -585,16 +586,24 @@ export default class PushNotificationPermission extends Vue {
   /**
    * Computed property: isSystemReady
    * Returns true if serviceWorkerReady and vapidKey are set
+   * For native platforms, always returns true (no VAPID needed)
    */
   get isSystemReady(): boolean {
+    if (this.isNativePlatform) {
+      return true; // Native doesn't need VAPID/service worker
+    }
     return this.serviceWorkerReady && !!this.vapidKey;
   }
 
   /**
    * Computed property: canShowNotificationForm
    * Returns true if serviceWorkerReady and vapidKey are set
+   * For native platforms, always returns true (no VAPID needed)
    */
   get canShowNotificationForm(): boolean {
+    if (this.isNativePlatform) {
+      return true; // Native doesn't need VAPID/service worker
+    }
     return this.serviceWorkerReady && !!this.vapidKey;
   }
 
@@ -614,6 +623,27 @@ export default class PushNotificationPermission extends Vue {
     return `${this.hourInput}:${this.minuteInput} ${this.hourAm ? "AM" : "PM"}`;
   }
 
+  /**
+   * Two-way binding for native time input (HH:mm 24h).
+   * Syncs with hourInput, minuteInput, and hourAm.
+   */
+  get timeValue(): string {
+    return this.convertTo24HourFormat();
+  }
+  set timeValue(value: string) {
+    const [h = "0", m = "0"] = value.split(":");
+    const hour24 = parseInt(h, 10);
+    const minute = parseInt(m, 10);
+    this.minuteInput = minute.toString().padStart(2, "0");
+    if (hour24 >= 12) {
+      this.hourAm = false;
+      this.hourInput = hour24 === 12 ? "12" : (hour24 - 12).toString();
+    } else {
+      this.hourAm = true;
+      this.hourInput = hour24 === 0 ? "12" : hour24.toString();
+    }
+  }
+
   /**
    * Toggles the AM/PM state for the hour input
    */
@@ -639,10 +669,15 @@ export default class PushNotificationPermission extends Vue {
 
   /**
    * Handles the main action button click
+   * Close only after async flow completes so success/error $notify runs while component is mounted (fixes Android).
    */
-  handleTurnOnNotifications() {
+  async handleTurnOnNotifications() {
+    if (this.isNativePlatform) {
+      await this.turnOnNativeNotifications();
+    } else {
+      await this.turnOnNotifications();
+    }
     this.close();
-    this.turnOnNotifications();
   }
 
   /**
@@ -652,6 +687,249 @@ export default class PushNotificationPermission extends Vue {
   get waitingMessage(): string {
     return "Waiting for system initialization, which may take up to 5 seconds...";
   }
+
+  /**
+   * Handle native notification setup using DailyNotificationPlugin
+   */
+  private async turnOnNativeNotifications(): Promise<void> {
+    try {
+      logger.debug(
+        "[PushNotificationPermission] Starting native notification setup",
+      );
+
+      // Edit flow: parent will cancel + schedule; avoid double schedule (second call cancels alarm first set).
+      if (this.skipScheduleForOpen) {
+        this.callback(true, this.notificationTimeText, this.messageInput);
+        return;
+      }
+
+      // Import and check plugin availability before using service
+      const { DailyNotification } = await import(
+        "@/plugins/DailyNotificationPlugin"
+      );
+      if (!DailyNotification) {
+        logger.error(
+          "[PushNotificationPermission] DailyNotification plugin not available",
+        );
+        this.$notify(
+          {
+            group: "alert",
+            type: "danger",
+            title: NOTIFY_PUSH_SETUP_ERROR.title,
+            text: "DailyNotification plugin is not available. Please rebuild the app.",
+          },
+          PUSH_NOTIFICATION_TIMEOUT_SHORT,
+        );
+        this.callback(false, "", this.messageInput);
+        return;
+      }
+
+      logger.debug(
+        "[PushNotificationPermission] Plugin available, getting service instance",
+      );
+      const service = NotificationService.getInstance();
+
+      // Request permissions
+      logger.debug(
+        "[PushNotificationPermission] Requesting native permissions",
+      );
+      const granted = await service.requestPermissions();
+
+      if (!granted) {
+        logger.warn(
+          "[PushNotificationPermission] Native notification permissions denied",
+        );
+        this.$notify(
+          {
+            group: "alert",
+            type: "danger",
+            title: NOTIFY_PUSH_PERMISSION_ERROR.title,
+            text: NOTIFY_PUSH_PERMISSION_ERROR.message,
+          },
+          PUSH_NOTIFICATION_TIMEOUT_PERSISTENT,
+        );
+        this.callback(false, "", this.messageInput);
+        return;
+      }
+
+      // Convert time to 24-hour format (HH:mm)
+      const time24h = this.convertTo24HourFormat();
+      logger.debug(
+        "[PushNotificationPermission] Converted time to 24-hour format:",
+        time24h,
+      );
+
+      // Option A: For New Activity we do not schedule the single daily reminder here.
+      // AccountViewView's callback will call scheduleNewActivityDualNotification(timeText),
+      // which uses the dual schedule (prefetch + notify) only. This keeps the two notification
+      // types separate and avoids a second, uncancellable reminder.
+      if (this.pushType === this.DAILY_CHECK_TITLE) {
+        logger.info(
+          "[PushNotificationPermission] New Activity: skipping single reminder schedule; parent will schedule dual notification",
+        );
+        const timeText = this.notificationTimeText;
+        await this.$saveSettings({ notifyingNewActivityTime: timeText });
+        logger.debug(
+          "[PushNotificationPermission] Settings saved: notifyingNewActivityTime",
+        );
+        this.$notify(
+          {
+            group: "alert",
+            type: "success",
+            title: NOTIFY_PUSH_SUCCESS_NEW_ACTIVITY.title,
+            text: NOTIFY_PUSH_SUCCESS_NEW_ACTIVITY.message,
+          },
+          PUSH_NOTIFICATION_TIMEOUT_LONG,
+        );
+        this.callback(true, timeText, this.messageInput);
+        return;
+      }
+
+      // Daily Reminder: schedule the single daily notification (native only).
+      const title = "Daily Reminder";
+      const body = this.messageInput || this.notificationMessagePlaceholder;
+      logger.info(
+        "[PushNotificationPermission] Scheduling native notification:",
+        {
+          time: time24h,
+          title,
+          pushType: this.pushType,
+        },
+      );
+
+      // Check permissions one more time before scheduling
+      const finalPermissionCheck = await service.checkPermissions();
+      logger.debug(
+        "[PushNotificationPermission] Final permission check before scheduling:",
+        JSON.stringify(finalPermissionCheck, null, 2),
+      );
+
+      if (!finalPermissionCheck.granted) {
+        logger.warn(
+          "[PushNotificationPermission] Permissions not fully granted. " +
+            "Notification may not fire. Details:",
+          finalPermissionCheck.details,
+        );
+      }
+
+      const success = await service.scheduleDailyNotification({
+        time: time24h,
+        title,
+        body,
+        priority: "normal",
+        ...(this.rolloverIntervalMinutesForSchedule != null &&
+        this.rolloverIntervalMinutesForSchedule > 0
+          ? { rolloverIntervalMinutes: this.rolloverIntervalMinutesForSchedule }
+          : {}),
+      });
+
+      if (!success) {
+        logger.error(
+          "[PushNotificationPermission] Failed to schedule native notification",
+        );
+        this.$notify(
+          {
+            group: "alert",
+            type: "danger",
+            title: NOTIFY_PUSH_SETUP_ERROR.title,
+            text: NOTIFY_PUSH_SETUP_ERROR.message,
+          },
+          PUSH_NOTIFICATION_TIMEOUT_SHORT,
+        );
+        this.callback(false, "", this.messageInput);
+        return;
+      }
+
+      // Log final status after scheduling
+      const statusAfterSchedule = await service.getStatus();
+      logger.info(
+        "[PushNotificationPermission] Notification status after scheduling:",
+        JSON.stringify(statusAfterSchedule, null, 2),
+      );
+
+      // Save to settings
+      const timeText = this.notificationTimeText;
+      const settingsToSave: Record<string, string> = {};
+
+      if (this.pushType === this.DAILY_CHECK_TITLE) {
+        settingsToSave.notifyingNewActivityTime = timeText;
+      } else {
+        settingsToSave.notifyingReminderTime = timeText;
+        if (this.messageInput) {
+          settingsToSave.notifyingReminderMessage = this.messageInput;
+        }
+      }
+
+      await this.$saveSettings(settingsToSave);
+      logger.debug(
+        "[PushNotificationPermission] Settings saved:",
+        settingsToSave,
+      );
+
+      this.$notify(
+        {
+          group: "alert",
+          type: "success",
+          title: NOTIFY_PUSH_SUCCESS.title,
+          text: NOTIFY_PUSH_SUCCESS.message,
+        },
+        PUSH_NOTIFICATION_TIMEOUT_LONG,
+      );
+
+      // Call callback with success
+      this.callback(true, timeText, this.messageInput);
+    } catch (error) {
+      logger.error(
+        "[PushNotificationPermission] Error in native notification setup:",
+        error,
+      );
+      // Log additional error details for debugging
+      if (error instanceof Error) {
+        logger.error("[PushNotificationPermission] Error details:", {
+          message: error.message,
+          stack: error.stack,
+          name: error.name,
+        });
+      }
+      this.$notify(
+        {
+          group: "alert",
+          type: "danger",
+          title: NOTIFY_PUSH_SETUP_ERROR.title,
+          text: NOTIFY_PUSH_SETUP_ERROR.message,
+        },
+        PUSH_NOTIFICATION_TIMEOUT_SHORT,
+      );
+      this.callback(false, "", this.messageInput);
+    }
+  }
+
+  /**
+   * Convert AM/PM time input to 24-hour format (HH:mm)
+   * @returns Time string in HH:mm format
+   */
+  private convertTo24HourFormat(): string {
+    const hour = parseInt(this.hourInput);
+    const minute = parseInt(this.minuteInput);
+
+    let hour24 = hour;
+
+    // Convert to 24-hour format
+    if (!this.hourAm && hour !== 12) {
+      // PM: add 12 (except for 12 PM which stays 12)
+      hour24 = hour + 12;
+    } else if (this.hourAm && hour === 12) {
+      // 12 AM: convert to 0
+      hour24 = 0;
+    }
+    // AM (except 12): keep as is
+
+    // Format with leading zeros
+    const hourStr = hour24.toString().padStart(2, "0");
+    const minuteStr = minute.toString().padStart(2, "0");
+
+    return `${hourStr}:${minuteStr}`;
+  }
 }
 </script>