chore: document formatting rules

2025-09-22 07:27:01 +00:00
parent 4b8f936247
commit fcc4e52d5d
12 changed files with 196 additions and 30 deletions
--- a/API.md
+++ b/API.md
@@ -5,9 +5,11 @@
 ### Configuration

 #### `configure(options: ConfigureOptions): Promise<void>`
+
 Configure the plugin with storage, TTL, and optimization settings.

 **Parameters:**
+
 - `options.storage`: `'shared'` | `'tiered'` - Storage mode
 - `options.ttlSeconds`: `number` - TTL in seconds (default: 1800)
 - `options.prefetchLeadMinutes`: `number` - Prefetch lead time (default: 15)
@@ -18,9 +20,11 @@ Configure the plugin with storage, TTL, and optimization settings.
 ### Core Methods

 #### `scheduleDailyNotification(options: NotificationOptions): Promise<void>`
+
 Schedule a daily notification with content fetching.

 **Parameters:**
+
 - `options.url`: `string` - Content endpoint URL
 - `options.time`: `string` - Time in HH:MM format
 - `options.title`: `string` - Notification title
@@ -29,9 +33,11 @@ Schedule a daily notification with content fetching.
 - `options.retryConfig`: `RetryConfiguration` - Custom retry settings (optional)

 #### `getLastNotification(): Promise<NotificationResponse | null>`
+
 Get the last scheduled notification.

 #### `cancelAllNotifications(): Promise<void>`
+
 Cancel all scheduled notifications.

 ### Platform-Specific Methods
@@ -39,70 +45,89 @@ Cancel all scheduled notifications.
 #### Android Only

 ##### `getExactAlarmStatus(): Promise<ExactAlarmStatus>`
+
 Get exact alarm permission and capability status.

 ##### `requestExactAlarmPermission(): Promise<void>`
+
 Request exact alarm permission from user.

 ##### `openExactAlarmSettings(): Promise<void>`
+
 Open exact alarm settings in system preferences.

 ##### `getRebootRecoveryStatus(): Promise<RecoveryStatus>`
+
 Get reboot recovery status and statistics.

 ### Management Methods

 #### `maintainRollingWindow(): Promise<void>`
+
 Manually trigger rolling window maintenance.

 #### `getRollingWindowStats(): Promise<RollingWindowStats>`
+
 Get rolling window statistics and status.

 ### Optimization Methods

 #### `optimizeDatabase(): Promise<void>`
+
 Optimize database performance with indexes and settings.

 #### `optimizeMemory(): Promise<void>`
+
 Optimize memory usage and perform cleanup.

 #### `optimizeBattery(): Promise<void>`
+
 Optimize battery usage and background CPU.

 ### Metrics and Monitoring

 #### `getPerformanceMetrics(): Promise<PerformanceMetrics>`
+
 Get comprehensive performance metrics.

 #### `getErrorMetrics(): Promise<ErrorMetrics>`
+
 Get error handling metrics and statistics.

 #### `getNetworkMetrics(): Promise<NetworkMetrics>`
+
 Get network efficiency metrics (ETag support).

 #### `getMemoryMetrics(): Promise<MemoryMetrics>`
+
 Get memory usage metrics and statistics.

 #### `getObjectPoolMetrics(): Promise<ObjectPoolMetrics>`
+
 Get object pooling efficiency metrics.

 ### Utility Methods

 #### `resetPerformanceMetrics(): Promise<void>`
+
 Reset all performance metrics to zero.

 #### `resetErrorMetrics(): Promise<void>`
+
 Reset error handling metrics.

 #### `clearRetryStates(): Promise<void>`
+
 Clear all retry states and operations.

 #### `cleanExpiredETags(): Promise<void>`
+
 Clean expired ETag cache entries.

 ## Data Types

 ### ConfigureOptions
+
 ```typescript
 interface ConfigureOptions {
  storage?: 'shared' | 'tiered';
@@ -123,6 +148,7 @@ interface ConfigureOptions {
 ```

 ### NotificationOptions
+
 ```typescript
 interface NotificationOptions {
  url: string;
@@ -135,6 +161,7 @@ interface NotificationOptions {
 ```

 ### ExactAlarmStatus (Android)
+
 ```typescript
 interface ExactAlarmStatus {
  supported: boolean;
@@ -145,6 +172,7 @@ interface ExactAlarmStatus {
 ```

 ### PerformanceMetrics
+
 ```typescript
 interface PerformanceMetrics {
  overallScore: number;
@@ -162,6 +190,7 @@ interface PerformanceMetrics {
 ```

 ### ErrorMetrics
+
 ```typescript
 interface ErrorMetrics {
  totalErrors: number;
@@ -181,6 +210,7 @@ interface ErrorMetrics {
 All methods return promises that reject with descriptive error messages. The plugin includes comprehensive error categorization and retry logic.

 ### Common Error Types
+
 - **Network Errors**: Connection timeouts, DNS failures
 - **Storage Errors**: Database corruption, disk full
 - **Permission Errors**: Missing exact alarm permission
@@ -190,18 +220,21 @@ All methods return promises that reject with descriptive error messages. The plu
 ## Platform Differences

 ### Android
+
 - Requires `SCHEDULE_EXACT_ALARM` permission for precise timing
 - Falls back to windowed alarms (±10m) if exact permission denied
 - Supports reboot recovery with broadcast receivers
 - Full performance optimization features

 ### iOS
+
 - Uses `BGTaskScheduler` for background prefetch
 - Limited to 64 pending notifications
 - Automatic background task management
 - Battery optimization built-in

 ### Web
+
 - Placeholder implementations for development
 - No actual notification scheduling
 - All methods return mock data
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -8,6 +8,7 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 ## [1.0.0] - 2024-03-20

 ### Added
+
 - Initial release of the Daily Notification Plugin
 - Basic notification scheduling functionality
 - Support for multiple notification schedules
@@ -20,6 +21,7 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 - TypeScript support with full type definitions

 ### Features
+
 - Schedule daily notifications at specific times
 - Support for multiple notification schedules
 - Timezone-aware scheduling
@@ -30,6 +32,7 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 - Comprehensive settings management

 ### Security
+
 - HTTPS-only network requests
 - Content validation before display
 - Secure storage of sensitive data
@@ -37,6 +40,7 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 - No sensitive data in logs

 ### Documentation
+
 - Comprehensive API documentation
 - Usage examples for basic and advanced scenarios
 - Enterprise-level implementation examples
@@ -44,6 +48,7 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 - Platform-specific implementation details

 ### Testing
+
 - Unit tests for core functionality
 - Integration tests for platform features
 - Advanced scenario tests
@@ -53,17 +58,20 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 ## [0.9.0] - 2024-03-15

 ### Added
+
 - Beta release with core functionality
 - Basic notification scheduling
 - Simple content handling
 - Basic event system

 ### Changed
+
 - Improved error handling
 - Enhanced type definitions
 - Better documentation

 ### Fixed
+
 - Initial bug fixes and improvements
 - TypeScript type issues
 - Documentation clarity
@@ -71,17 +79,20 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 ## [0.8.0] - 2024-03-10

 ### Added
+
 - Alpha release with basic features
 - Initial plugin structure
 - Basic TypeScript interfaces
 - Simple notification scheduling

 ### Changed
+
 - Early development improvements
 - Initial documentation
 - Basic test setup

 ### Fixed
+
 - Early bug fixes
 - Initial type issues
 - Basic documentation
@@ -89,6 +100,7 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 ## [Unreleased]

 ### Added
+
 - Enterprise features
  - Notification queue system
  - A/B testing support
@@ -101,30 +113,35 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 - Enhanced documentation

 ### Changed
+
 - Improved error handling
 - Enhanced type definitions
 - Better documentation structure
 - More comprehensive examples

 ### Fixed
+
 - TypeScript type issues
 - Documentation clarity
 - Test coverage gaps
 - Example code improvements

 ### Security
+
 - Enhanced security measures
 - Additional validation
 - Improved error handling
 - Better logging practices

 ### Documentation
+
 - Added enterprise usage examples
 - Enhanced API documentation
 - Improved security guidelines
 - Better troubleshooting guides

 ### Testing
+
 - Added enterprise scenario tests
 - Enhanced test coverage
 - Improved test organization
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -6,15 +6,20 @@ Thank you for your interest in contributing to the Daily Notification Plugin for

 1. Fork the repository
 2. Clone your fork:
+
   ```bash
   git clone https://github.com/yourusername/capacitor-daily-notification.git
   cd capacitor-daily-notification
   ```
+
 3. Install dependencies:
+
   ```bash
   npm install
   ```
+
 4. Build the project:
+
   ```bash
   npm run build
   ```
@@ -50,23 +55,30 @@ Thank you for your interest in contributing to the Daily Notification Plugin for
 ### Git Workflow

 1. Create a feature branch:
+
   ```bash
   git checkout -b feature/your-feature-name
   ```
+
 2. Make your changes
 3. Commit your changes:
+
   ```bash
   git commit -m "feat: add your feature"
   ```
+
 4. Push to your fork:
+
   ```bash
   git push origin feature/your-feature-name
   ```
+
 5. Create a Pull Request

 ### Commit Messages

 Follow conventional commits format:
+
 - `feat:` for new features
 - `fix:` for bug fixes
 - `docs:` for documentation changes
@@ -76,6 +88,7 @@ Follow conventional commits format:
 - `chore:` for maintenance tasks

 Example:
+
 ```
 feat: add timezone support for notifications
 ```
--- a/CRITICAL_IMPROVEMENTS.md
+++ b/CRITICAL_IMPROVEMENTS.md
@@ -22,6 +22,7 @@ android/app/src/main/java/com/timesafari/dailynotification/MaintenanceReceiver.j
 ```

 **Key Features to Implement**:
+
 - Notification scheduling with AlarmManager
 - Battery optimization handling
 - Background task management
@@ -41,6 +42,7 @@ All test files need to be updated to match current interfaces:
 - `tests/advanced-scenarios.test.ts` - Fix mock implementations

 **Required Changes**:
+
 - Remove references to `checkPermissions` method
 - Update `NotificationOptions` interface usage
 - Fix timestamp types (string vs number)
@@ -309,24 +311,28 @@ Create complete example applications:
 ## Success Criteria

 ### Code Quality
+
 - [ ] 100% test coverage
 - [ ] Zero TypeScript errors
 - [ ] All linting rules passing
 - [ ] Performance benchmarks met

 ### Functionality
+
 - [ ] All platforms working
 - [ ] Feature parity across platforms
 - [ ] Proper error handling
 - [ ] Comprehensive logging

 ### Security
+
 - [ ] Input validation implemented
 - [ ] Secure storage working
 - [ ] No security vulnerabilities
 - [ ] Audit logging in place

 ### Documentation
+
 - [ ] API documentation complete
 - [ ] Examples working
 - [ ] Troubleshooting guides
--- a/IMPROVEMENT_SUMMARY.md
+++ b/IMPROVEMENT_SUMMARY.md
@@ -41,6 +41,7 @@
 - Documentation framework

 ### ❌ Critical Missing Components
+
 - **Android Implementation**: Completely missing (was deleted)
 - **Test Suite**: Most tests still failing due to interface mismatches
 - **Advanced Features**: Retry logic, error handling, performance monitoring
@@ -50,8 +51,10 @@
 ## Immediate Next Steps (Priority Order)

 ### 1. Restore Android Implementation (CRITICAL)
+
 **Estimated Time**: 8-12 hours
 **Files Needed**:
+
 ```
 android/app/src/main/java/com/timesafari/dailynotification/
 ├── DailyNotificationPlugin.java
@@ -65,15 +68,19 @@ android/app/src/main/java/com/timesafari/dailynotification/
 ```

 ### 2. Fix Remaining Test Files (HIGH)
+
 **Estimated Time**: 4-6 hours
 **Files to Update**:
+
 - `tests/enterprise-scenarios.test.ts`
 - `tests/edge-cases.test.ts`
 - `tests/advanced-scenarios.test.ts`

 ### 3. Complete Interface Definitions (HIGH)
+
 **Estimated Time**: 2-3 hours
 **Missing Properties**:
+
 - `retryCount`, `retryInterval`, `cacheDuration`
 - `headers`, `offlineFallback`, `contentHandler`
 - `checkPermissions()`, `requestPermissions()`
@@ -81,6 +88,7 @@ android/app/src/main/java/com/timesafari/dailynotification/
 ## Technical Debt Assessment

 ### Code Quality: 6/10
+
 - ✅ TypeScript compilation working
 - ✅ Interface definitions complete
 - ❌ Missing error handling patterns
@@ -88,12 +96,14 @@ android/app/src/main/java/com/timesafari/dailynotification/
 - ❌ Limited validation utilities

 ### Platform Support: 4/10
+
 - ✅ iOS implementation exists
 - ✅ Web implementation (basic)
 - ❌ Android implementation missing
 - ❌ No platform-specific optimizations

 ### Testing: 3/10
+
 - ✅ Test structure exists
 - ✅ Basic test framework working
 - ❌ Most tests failing
@@ -101,6 +111,7 @@ android/app/src/main/java/com/timesafari/dailynotification/
 - ❌ No performance tests

 ### Documentation: 7/10
+
 - ✅ README and changelog
 - ✅ API documentation structure
 - ❌ Missing detailed API docs
@@ -108,6 +119,7 @@ android/app/src/main/java/com/timesafari/dailynotification/
 - ❌ Examples need updating

 ### Security: 2/10
+
 - ❌ No input validation
 - ❌ No secure storage
 - ❌ Limited permission handling
@@ -116,18 +128,21 @@ android/app/src/main/java/com/timesafari/dailynotification/
 ## Success Metrics Progress

 ### Code Quality
+
 - [x] Zero TypeScript errors
 - [x] Build system working
 - [ ] 100% test coverage
 - [ ] All linting rules passing

 ### Functionality
+
 - [x] Web platform working
 - [x] iOS platform working
 - [ ] Android platform working
 - [ ] Feature parity across platforms

 ### User Experience
+
 - [ ] Reliable notification delivery
 - [ ] Fast response times
 - [ ] Intuitive API design
@@ -136,21 +151,25 @@ android/app/src/main/java/com/timesafari/dailynotification/
 ## Recommended Timeline

 ### Week 1: Foundation
+
 - **Days 1-2**: Restore Android implementation
 - **Days 3-4**: Fix all test files
 - **Days 5-7**: Complete interface definitions

 ### Week 2: Core Features
+
 - **Days 1-3**: Implement error handling and logging
 - **Days 4-5**: Add validation utilities
 - **Days 6-7**: Implement retry mechanisms

 ### Week 3: Advanced Features
+
 - **Days 1-3**: Add performance monitoring
 - **Days 4-5**: Implement security features
 - **Days 6-7**: Add analytics and A/B testing

 ### Week 4: Production Readiness
+
 - **Days 1-3**: Comprehensive testing
 - **Days 4-5**: Documentation completion
 - **Days 6-7**: Performance optimization
@@ -158,16 +177,19 @@ android/app/src/main/java/com/timesafari/dailynotification/
 ## Risk Assessment

 ### High Risk
+
 - **Android Implementation**: Critical for production use
 - **Test Coverage**: Without proper tests, reliability is compromised
 - **Error Handling**: Missing error handling could cause crashes

 ### Medium Risk
+
 - **Performance**: No performance monitoring could lead to issues at scale
 - **Security**: Missing security features could expose vulnerabilities
 - **Documentation**: Poor documentation could hinder adoption

 ### Low Risk
+
 - **Advanced Features**: Nice-to-have but not critical for basic functionality
 - **Analytics**: Useful but not essential for core functionality

@@ -176,12 +198,14 @@ android/app/src/main/java/com/timesafari/dailynotification/
 The Daily Notification Plugin has a solid foundation with modern TypeScript architecture and good build tooling. The critical build issues have been resolved, and the project is now in a state where development can proceed efficiently.

 **Key Achievements**:
+
 - Fixed all TypeScript compilation errors
 - Updated interface definitions to be complete and consistent
 - Resolved build system issues
 - Created comprehensive improvement roadmap

 **Critical Next Steps**:
+
 1. Restore the missing Android implementation
 2. Fix the failing test suite
 3. Implement proper error handling and logging
--- a/PROJECT_ASSESSMENT.md
+++ b/PROJECT_ASSESSMENT.md
@@ -29,11 +29,13 @@ The Daily Notification Plugin project shows good foundational structure but requ

 **Current State**: Good TypeScript structure with proper interfaces
 **Issues**:
+
 - Interface definitions were incomplete
 - Missing proper error handling patterns
 - No structured logging system

 **Recommendations**:
+
 - Implement comprehensive error handling with custom error types
 - Add structured logging with different log levels
 - Create proper validation utilities
@@ -42,16 +44,19 @@ The Daily Notification Plugin project shows good foundational structure but requ
 ### 2. Native Platform Implementations

 **iOS**: ✅ Good implementation with Swift
+
 - Proper notification handling
 - Battery optimization support
 - Background task management

 **Android**: ❌ Missing implementation
+
 - All native Java files were deleted
 - No Android-specific functionality
 - Missing permission handling

 **Web**: ⚠️ Basic placeholder implementation
+
 - Limited to browser notifications
 - No advanced features
 - Missing offline support
@@ -60,11 +65,13 @@ The Daily Notification Plugin project shows good foundational structure but requ

 **Current State**: Comprehensive test structure but failing
 **Issues**:
+
 - Tests reference non-existent methods
 - Mock implementations are incomplete
 - No integration tests for native platforms

 **Recommendations**:
+
 - Fix all test files to match current interfaces
 - Add proper mock implementations
 - Implement platform-specific test suites
@@ -74,11 +81,13 @@ The Daily Notification Plugin project shows good foundational structure but requ

 **Current State**: Good basic documentation
 **Issues**:
+
 - Missing API documentation
 - Examples don't match current implementation
 - No troubleshooting guides

 **Recommendations**:
+
 - Generate comprehensive API documentation
 - Update examples to match current interfaces
 - Add troubleshooting and debugging guides
@@ -143,18 +152,21 @@ The Daily Notification Plugin project shows good foundational structure but requ
 ## Technical Debt

 ### Code Quality Issues
+
 - Missing error boundaries
 - Incomplete type safety
 - No performance monitoring
 - Limited logging capabilities

 ### Architecture Issues
+
 - Tight coupling between layers
 - Missing abstraction layers
 - No plugin system for extensions
 - Limited configuration options

 ### Security Issues
+
 - Missing input validation
 - No secure storage implementation
 - Limited permission handling
@@ -163,24 +175,28 @@ The Daily Notification Plugin project shows good foundational structure but requ
 ## Recommended Action Plan

 ### Phase 1: Foundation (Week 1-2)
+
 1. Restore Android implementation
 2. Fix all test failures
 3. Complete interface definitions
 4. Implement basic error handling

 ### Phase 2: Enhancement (Week 3-4)
+
 1. Improve web implementation
 2. Add comprehensive logging
 3. Implement retry mechanisms
 4. Add performance monitoring

 ### Phase 3: Advanced Features (Week 5-6)
+
 1. Add notification queuing
 2. Implement analytics
 3. Create user preference system
 4. Add A/B testing support

 ### Phase 4: Production Readiness (Week 7-8)
+
 1. Security audit and fixes
 2. Performance optimization
 3. Comprehensive testing
@@ -189,18 +205,21 @@ The Daily Notification Plugin project shows good foundational structure but requ
 ## Success Metrics

 ### Code Quality
+
 - 100% test coverage
 - Zero TypeScript errors
 - All linting rules passing
 - Performance benchmarks met

 ### Functionality
+
 - All platforms working
 - Feature parity across platforms
 - Proper error handling
 - Comprehensive logging

 ### User Experience
+
 - Reliable notification delivery
 - Fast response times
 - Intuitive API design
--- a/README.md
+++ b/README.md
@@ -141,6 +141,7 @@ This plugin follows security best practices:
 ## Changelog

 ### 1.0.0
+
 - Initial release
 - Basic notification scheduling
 - System state handling
--- a/SECURITY.md
+++ b/SECURITY.md
@@ -197,8 +197,8 @@ We take the security of the Daily Notification Plugin seriously. If you discover

 For security-related issues or questions, please contact:

- Security Team: security@timesafari.com
- Emergency Contact: emergency@timesafari.com
+- Security Team: <security@timesafari.com>
+- Emergency Contact: <emergency@timesafari.com>

 ## Acknowledgments

--- a/USAGE.md
+++ b/USAGE.md
@@ -24,14 +24,17 @@ await DailyNotification.scheduleDailyNotification({
 ## Configuration Options

 ### Storage Mode
+
 - **`'shared'`** (Recommended): Uses shared SQLite database with WAL mode
 - **`'tiered'`** (Legacy): Uses SharedPreferences/UserDefaults + in-memory cache

 ### TTL Settings
+
 - **`ttlSeconds`**: Maximum age of content at delivery time (default: 1800 = 30 minutes)
 - **`prefetchLeadMinutes`**: How early to prefetch content (default: 15 minutes)

 ### Performance Optimization
+
 - **`enableETagSupport`**: Use conditional requests for bandwidth savings
 - **`enableErrorHandling`**: Advanced retry logic with exponential backoff
 - **`enablePerformanceOptimization`**: Database indexes, memory management, object pooling
@@ -39,6 +42,7 @@ await DailyNotification.scheduleDailyNotification({
 ## Platform-Specific Features

 ### Android
+
 ```typescript
 // Check exact alarm status
 const alarmStatus = await DailyNotification.getExactAlarmStatus();
@@ -55,6 +59,7 @@ if (recoveryStatus.recoveryNeeded) {
 ```

 ### iOS
+
 ```typescript
 // Background tasks are automatically handled
 // The plugin uses BGTaskScheduler for T–lead prefetch
@@ -64,6 +69,7 @@ if (recoveryStatus.recoveryNeeded) {
 ## Advanced Usage

 ### Error Handling
+
 ```typescript
 // Configure retry behavior
 await DailyNotification.configure({
@@ -80,6 +86,7 @@ console.log(`Cache hit ratio: ${errorMetrics.cacheHitRatio}`);
 ```

 ### Performance Monitoring
+
 ```typescript
 // Get performance metrics
 const metrics = await DailyNotification.getPerformanceMetrics();
@@ -94,6 +101,7 @@ if (metrics.overallScore < 70) {
 ```

 ### Rolling Window Management
+
 ```typescript
 // Manual maintenance
 await DailyNotification.maintainRollingWindow();
--- a/doc/implementation-roadmap.md
+++ b/doc/implementation-roadmap.md
@@ -14,6 +14,7 @@
 This document outlines the implementation roadmap to bring the current Daily Notification Plugin (65% complete) to full compliance with the Native-First Notification System specification. The implementation is organized into three phases, with Phase 1 containing critical infrastructure components required for core functionality.

 ### Current State Assessment
+
 - **Overall Completion:** 65% of specification requirements
 - **Critical Gaps:** SQLite database sharing, TTL-at-fire enforcement, rolling window safety
 - **Current Storage:** SharedPreferences (Android) / UserDefaults (iOS) + in-memory cache
@@ -25,14 +26,18 @@ This document outlines the implementation roadmap to bring the current Daily Not
 ## Current Implementation Status Clarification

 ### Background Fetch Infrastructure
+
 **Current State:** Basic infrastructure exists but lacks T–lead logic
+
 - **Android:** `DailyNotificationFetchWorker.java` (WorkManager) exists
 - **Android:** `DailyNotificationFetcher.java` with scheduling logic exists
 - **Missing:** T–lead calculation, TTL enforcement, ETag support
 - **Status:** Infrastructure ready, T–lead logic needs implementation

 ### iOS Implementation Status
+
 **Current State:** Basic plugin structure with power management
+
 - **Implemented:** Plugin skeleton, power management, UserDefaults storage
 - **Missing:** BGTaskScheduler, background tasks, T–lead prefetch
 - **Status:** Foundation exists, background execution needs implementation
@@ -48,6 +53,7 @@ This document outlines the implementation roadmap to bring the current Daily Not
 **Priority:** CRITICAL

 #### Requirements
+
 - Migrate from SharedPreferences/UserDefaults to shared SQLite database (see Glossary → Shared DB)
 - WAL mode configuration for concurrent access (see Glossary → WAL)
 - Schema version checking and compatibility validation (see Glossary → PRAGMA user_version)
@@ -55,6 +61,7 @@ This document outlines the implementation roadmap to bring the current Daily Not
 - **Migration Strategy:** Gradual migration from current tiered storage (see Glossary → Tiered Storage)

 #### Implementation Tasks
+
 - [ ] **Migration from Current Storage**
  - Create migration utilities from SharedPreferences to SQLite
  - Implement data migration from UserDefaults to SQLite (iOS)
@@ -73,6 +80,7 @@ This document outlines the implementation roadmap to bring the current Daily Not
  - Extend existing `NotificationOptions` with database settings

 - [ ] **Database Schema**
+
  ```sql
  -- notif_contents: keep history, newest-first reads
  CREATE TABLE IF NOT EXISTS notif_contents(
@@ -104,6 +112,7 @@ This document outlines the implementation roadmap to bring the current Daily Not
  ```

 #### Acceptance Criteria
+
 - [ ] App and plugin can open the same SQLite file
 - [ ] WAL mode enables concurrent reads during writes
 - [ ] Schema version checking prevents compatibility issues
@@ -118,6 +127,7 @@ This document outlines the implementation roadmap to bring the current Daily Not
 **Priority:** CRITICAL

 #### Requirements
+
 - Skip arming notifications if `(T - fetchedAt) > ttlSeconds` (see Glossary → TTL)
 - Validate freshness before scheduling
 - Log TTL violations for debugging
@@ -125,6 +135,7 @@ This document outlines the implementation roadmap to bring the current Daily Not
 - **Shared DB (single file):** App owns migrations (`PRAGMA user_version`) (see Glossary → PRAGMA user_version); plugin opens the **same path**; enable `journal_mode=WAL` (see Glossary → WAL), `synchronous=NORMAL`, `busy_timeout=5000`, `foreign_keys=ON`; background writes are **short & serialized**.

 #### Implementation Tasks
+
 - [ ] **TTL Validation Logic**
  - Insert TTL check into the scheduler path **before** any arm/re-arm
  - Add log code `TTL_VIOLATION`
@@ -143,6 +154,7 @@ This document outlines the implementation roadmap to bring the current Daily Not
  - Add TTL validation in option validation

 #### Acceptance Criteria
+
 - [ ] Notifications are skipped if content is stale
 - [ ] TTL violations are logged with timestamps
 - [ ] Default TTL values are applied when not specified
@@ -155,12 +167,14 @@ This document outlines the implementation roadmap to bring the current Daily Not
 **Priority:** CRITICAL

 #### Requirements
+
 - Keep today's remaining notifications armed
 - Keep tomorrow's notifications armed (within iOS caps) (see Glossary → Rolling window)
 - Ensure closed-app delivery reliability
 - **Current State:** Basic scheduling exists, but no rolling window logic

 #### Implementation Tasks
+
 - [ ] **Rolling Window Logic** (see Glossary → Rolling window)
  - Implement `armRollingWindow()` method
  - Calculate today's remaining slots
@@ -178,6 +192,7 @@ This document outlines the implementation roadmap to bring the current Daily Not
  - Add window state persistence

 #### Acceptance Criteria
+
 - [ ] Today's remaining notifications stay armed
 - [ ] Tomorrow's notifications are armed within iOS caps
 - [ ] Closed-app delivery works reliably
@@ -189,12 +204,14 @@ This document outlines the implementation roadmap to bring the current Daily Not
 **Priority:** HIGH

 #### Requirements
+
 - Add `dbPath` configuration option
 - Implement database path resolution
 - Add storage mode configuration
 - **Current State:** No database path configuration exists

 #### Implementation Tasks
+
 - [ ] **Interface Updates**
  - Extend `ConfigureOptions` with `dbPath: string`
  - Add `storage: 'shared'` option
@@ -206,6 +223,7 @@ This document outlines the implementation roadmap to bring the current Daily Not
  - Create path validation logic

 #### Acceptance Criteria
+
 - [ ] `dbPath` can be configured via API
 - [ ] Path resolution works on all platforms
 - [ ] Configuration validation prevents invalid paths
@@ -221,6 +239,7 @@ This document outlines the implementation roadmap to bring the current Daily Not
 **Priority:** HIGH

 #### Requirements
+
 - `BGTaskScheduler` for T-lead prefetch (see Glossary → T–lead)
 - Silent push nudge support
 - Background execution budget management
@@ -230,6 +249,7 @@ This document outlines the implementation roadmap to bring the current Daily Not
 - Single attempt at **T–lead**; **12s** timeout; no delivery-time fetch; (re)arm only if within **TTL-at-fire**. **(Planned)**

 #### Implementation Tasks
+
 - [ ] **BGTaskScheduler Integration**
  - Create `DailyNotificationBackgroundTask.swift`
  - Implement background task registration
@@ -246,6 +266,7 @@ This document outlines the implementation roadmap to bring the current Daily Not
  - Handle budget exhaustion gracefully

 #### Acceptance Criteria
+
 - [ ] Background tasks run at T-lead (see Glossary → T–lead)
 - [ ] Silent push can trigger background execution
 - [ ] Budget management prevents system penalties
@@ -257,12 +278,14 @@ This document outlines the implementation roadmap to bring the current Daily Not
 **Priority:** HIGH

 #### Requirements
+
 - Complete ±10 minute windowed alarm implementation (see Glossary → Windowed alarm)
 - Finish reboot/time change recovery
 - Improve exact alarm fallback handling (see Glossary → Exact alarm)
 - Finalize ±10m windowed alarm; reboot/time-change recovery; deep-link to Exact Alarm permission. **(Planned)**

 #### Implementation Tasks
+
 - [ ] **Windowed Alarm Implementation**
  - Complete `scheduleInexactAlarm()` method
  - Implement ±10 minute window targeting
@@ -279,6 +302,7 @@ This document outlines the implementation roadmap to bring the current Daily Not
  - Implement fallback logging

 #### Acceptance Criteria
+
 - [ ] Windowed alarms target ±10 minute windows
 - [ ] Reboot recovery re-arms next 24h
 - [ ] Time change recovery recomputes schedules
@@ -290,11 +314,13 @@ This document outlines the implementation roadmap to bring the current Daily Not
 **Priority:** MEDIUM

 #### Requirements
+
 - Notifications while app is running
 - Start-on-Login support
 - Best-effort background scheduling

 #### Implementation Tasks
+
 - [ ] **Electron Integration**
  - Create `DailyNotificationElectron.ts`
  - Implement notification API
@@ -306,6 +332,7 @@ This document outlines the implementation roadmap to bring the current Daily Not
  - Add fallback mechanisms

 #### Acceptance Criteria
+
 - [ ] Notifications work while app is running
 - [ ] Start-on-Login enables post-reboot delivery
 - [ ] Limitations are clearly documented
@@ -322,11 +349,13 @@ This document outlines the implementation roadmap to bring the current Daily Not
 **Priority:** MEDIUM

 #### Requirements
+
 - ETag headers in fetch requests
 - 304 response handling
 - Network efficiency optimization

 #### Implementation Tasks
+
 - [ ] **ETag Headers**
  - Add ETag to fetch requests
  - Implement ETag storage in database
@@ -343,6 +372,7 @@ This document outlines the implementation roadmap to bring the current Daily Not
  - Add network efficiency metrics

 #### Acceptance Criteria
+
 - [ ] ETag headers are sent with requests
 - [ ] 304 responses are handled correctly
 - [ ] Network efficiency is improved
@@ -353,11 +383,13 @@ This document outlines the implementation roadmap to bring the current Daily Not
 **Priority:** MEDIUM

 #### Requirements
+
 - Comprehensive error categorization
 - Retry logic with exponential backoff
 - Error reporting and telemetry

 #### Implementation Tasks
+
 - [ ] **Error Categories**
  - Define error types and codes
  - Implement error classification
@@ -374,6 +406,7 @@ This document outlines the implementation roadmap to bring the current Daily Not
  - Create debugging information

 #### Acceptance Criteria
+
 - [ ] Errors are properly categorized
 - [ ] Retry logic works with backoff
 - [ ] Telemetry provides useful insights
@@ -384,11 +417,13 @@ This document outlines the implementation roadmap to bring the current Daily Not
 **Priority:** LOW

 #### Requirements
+
 - Database query optimization
 - Memory usage optimization
 - Battery usage optimization

 #### Implementation Tasks
+
 - [ ] **Database Optimization**
  - Add database indexes
  - Optimize query performance
@@ -405,6 +440,7 @@ This document outlines the implementation roadmap to bring the current Daily Not
  - Add battery usage tracking

 #### Acceptance Criteria
+
 - [ ] Database queries are optimized
 - [ ] Memory usage is minimized
 - [ ] Battery usage is optimized
@@ -415,6 +451,7 @@ This document outlines the implementation roadmap to bring the current Daily Not
 ## Implementation Guidelines

 ### Development Standards
+
 - **Code Quality:** Follow existing code style and documentation standards
 - **Testing:** Write unit tests for all new functionality
 - **Documentation:** Update documentation for all API changes
@@ -422,12 +459,14 @@ This document outlines the implementation roadmap to bring the current Daily Not
 - **Security:** Follow security best practices for database access

 ### Testing Requirements
+
 - **Unit Tests:** All new methods must have unit tests
 - **Integration Tests:** Test database sharing functionality
 - **Platform Tests:** Test on Android, iOS, and Electron
 - **Edge Cases:** Test TTL violations, network failures, and recovery scenarios

 ### Documentation Updates
+
 - **API Documentation:** Update TypeScript definitions
 - **Implementation Guide:** Update implementation documentation
 - **Troubleshooting:** Add troubleshooting guides for common issues
@@ -438,18 +477,21 @@ This document outlines the implementation roadmap to bring the current Daily Not
 ## Success Metrics

 ### Phase 1 Success Criteria
+
 - [ ] SQLite database sharing works reliably
 - [ ] TTL-at-fire enforcement prevents stale notifications
 - [ ] Rolling window ensures closed-app delivery
 - [ ] Configuration API supports all required options

 ### Phase 2 Success Criteria
+
 - [ ] iOS background tasks run at T-lead
 - [ ] Android fallback works seamlessly
 - [ ] Electron notifications work while running
 - [ ] All platforms support the unified API

 ### Phase 3 Success Criteria
+
 - [ ] ETag support improves network efficiency
 - [ ] Error handling is comprehensive and robust
 - [ ] Performance is optimized across all platforms
@@ -460,12 +502,14 @@ This document outlines the implementation roadmap to bring the current Daily Not
 ## Risk Mitigation

 ### Technical Risks
+
 - **Database Compatibility:** Test schema version checking thoroughly
 - **Platform Differences:** Implement platform-specific fallbacks
 - **Background Execution:** Handle iOS background execution limitations
 - **Permission Changes:** Monitor Android permission policy changes

 ### Implementation Risks
+
 - **Scope Creep:** Stick to specification requirements
 - **Testing Coverage:** Ensure comprehensive testing
 - **Documentation:** Keep documentation up-to-date
@@ -480,6 +524,7 @@ This roadmap provides a structured approach to completing the Daily Notification
 The implementation should follow the existing code patterns and maintain the high quality standards established in the current codebase. Regular testing and documentation updates are essential for success.

 **Next Steps:**
+
 1. Review and approve this roadmap
 2. Begin Phase 1 implementation
 3. Set up testing infrastructure
--- a/doc/notification-system.md
+++ b/doc/notification-system.md
@@ -53,11 +53,11 @@ App (Vue/TS) → Orchestrator (policy) → Native Adapters:

 ### SQLite Ownership & Concurrency *(Planned)*

-* **One DB file:** The plugin will open the **same path** the app uses (no second DB).
-* **Migrations owned by app:** The app executes schema migrations and bumps `PRAGMA user_version` (see Glossary → PRAGMA user_version). The plugin **never** migrates; it **asserts** the expected version.
-* **WAL mode:** Open DB with `journal_mode=WAL`, `synchronous=NORMAL`, `busy_timeout=5000`, `foreign_keys=ON`. WAL (see Glossary → WAL) allows foreground reads while a background job commits quickly.
-* **Single-writer discipline:** Background jobs write in **short transactions** (UPSERT per slot), then return.
-* **Encryption (optional):** If using SQLCipher, the **same key** is used by both app and plugin. Do not mix encrypted and unencrypted openings.
+- **One DB file:** The plugin will open the **same path** the app uses (no second DB).
+- **Migrations owned by app:** The app executes schema migrations and bumps `PRAGMA user_version` (see Glossary → PRAGMA user_version). The plugin **never** migrates; it **asserts** the expected version.
+- **WAL mode:** Open DB with `journal_mode=WAL`, `synchronous=NORMAL`, `busy_timeout=5000`, `foreign_keys=ON`. WAL (see Glossary → WAL) allows foreground reads while a background job commits quickly.
+- **Single-writer discipline:** Background jobs write in **short transactions** (UPSERT per slot), then return.
+- **Encryption (optional):** If using SQLCipher, the **same key** is used by both app and plugin. Do not mix encrypted and unencrypted openings.

 *Note: Currently using SharedPreferences (Android) / UserDefaults (iOS) with in-memory cache. See Implementation Roadmap → Phase 1.1 for migration steps.*

@@ -90,18 +90,18 @@ App (Vue/TS) → Orchestrator (policy) → Native Adapters:

 ### DB Path & Adapter Configuration *(Planned)*

-* **Configure option:** `dbPath: string` (absolute path or platform alias) will be passed from JS to the plugin during `configure()`.
-* **Shared tables:**
+- **Configure option:** `dbPath: string` (absolute path or platform alias) will be passed from JS to the plugin during `configure()`.
+- **Shared tables:**

-  * `notif_contents(slot_id, payload_json, fetched_at, etag, …)`
-  * `notif_deliveries(slot_id, fire_at, delivered_at, status, error_code, …)`
-  * `notif_config(k, v)`
-* **Open settings:**
+  - `notif_contents(slot_id, payload_json, fetched_at, etag, …)`
+  - `notif_deliveries(slot_id, fire_at, delivered_at, status, error_code, …)`
+  - `notif_config(k, v)`
+- **Open settings:**

-  * `journal_mode=WAL`
-  * `synchronous=NORMAL`
-  * `busy_timeout=5000`
-  * `foreign_keys=ON`
+  - `journal_mode=WAL`
+  - `synchronous=NORMAL`
+  - `busy_timeout=5000`
+  - `foreign_keys=ON`

 *Note: Currently using SharedPreferences/UserDefaults (see Glossary → Tiered Storage). Database configuration is planned for Phase 1.*

@@ -230,9 +230,9 @@ require(uv >= MIN_EXPECTED_VERSION) { "Schema version too old" }

 ### DB Sharing *(Planned)*

-* **Shared DB visibility:** A background prefetch writes `notif_contents`; the foreground UI **immediately** reads the same row.
-* **WAL overlap:** With the app reading while the plugin commits, no user-visible blocking occurs.
-* **Version safety:** If `user_version` is behind, the plugin emits an error and does not write (protects against partial installs).
+- **Shared DB visibility:** A background prefetch writes `notif_contents`; the foreground UI **immediately** reads the same row.
+- **WAL overlap:** With the app reading while the plugin commits, no user-visible blocking occurs.
+- **Version safety:** If `user_version` is behind, the plugin emits an error and does not write (protects against partial installs).

 *Note: Currently using SharedPreferences/UserDefaults with in-memory cache. SQLite sharing is planned for Phase 1.*

@@ -244,4 +244,4 @@ Web-push functionality has been retired due to unreliability. All web-push relat

 ---

-_This document consolidates the Native-First notification system strategy, implementation details, capabilities, and acceptance criteria into a single comprehensive reference._
+*This document consolidates the Native-First notification system strategy, implementation details, capabilities, and acceptance criteria into a single comprehensive reference.*