move files from 'docs' to existing 'doc' directory

.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
 

BUILDING.md

@@ -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)
 
@@ -1809,13 +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)
+- [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](docs/web-build-scripts.md)
-- [Build Troubleshooting](docs/build-troubleshooting.md)
+- [Web Build Scripts](doc/web-build-scripts.md)
+- [Build Troubleshooting](doc/build-troubleshooting.md)
 
 ---
 

doc/DAILY_NOTIFICATION_BUG_DIAGNOSIS.md

@@ -117,6 +117,6 @@ That only affects flows that **fetch** content (e.g. prefetch or any path that u
 | Plugin in app node_modules has cancelDailyReminder | OK |
 | Schedule path passes skipPendingIntentIdempotence = true | OK |
 
-**See also:** `docs/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.
+**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/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/plugin-feedback-android-exact-alarm-settings.md

@@ -69,6 +69,6 @@ The consumer app does **not** call any plugin API to “request exact alarm” o
 ## 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; `docs/NOTIFICATION_TROUBLESHOOTING.md` mentions exact alarms for user guidance.
+- **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-rollover-after-reboot.md

@@ -82,7 +82,7 @@ If step 3 does **not** actually register an alarm (because boot recovery skips),
 
 ## Evidence that boot recovery can skip rescheduling
 
-Boot recovery repeatedly logs that it is **skipping** reschedule (see also `docs/plugin-feedback-android-post-reboot-fallback-text.md` and the Scenario 1 logcat above):
+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

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

@@ -44,7 +44,7 @@ So the user’s chosen time was **21:56**. The 21:53 alarm was a **separate** sc
 
 ### 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 `docs/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: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.
@@ -61,7 +61,7 @@ So there are **two logical schedules** active: one for 21:53 (stale or from pref
 
 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 `docs/plugin-feedback-android-post-reboot-fallback-text.md`):**
+**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.
@@ -79,9 +79,9 @@ The receiver is trying to read from the DB (e.g. to fill in title/body when extr
 
 ## Relation to existing docs
 
-- **Duplicate reminder** (`docs/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** (`docs/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** (`docs/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.
+- **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.
 
 ---
 

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/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-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 ""