docs: remove independent views, focus on AccountViewView integration only

- Remove ScheduleView, NotificationsView, NotificationHistoryView, NotificationSettingsView
- Remove router routes for independent views
- Remove Pinia store (not needed - state managed locally)
- Remove HomeView diagnostics integration
- Remove native fetcher configuration integration
- Keep only AccountViewView integration with optional supporting components
- Update all phases to focus on AccountViewView only
- Update milestones and testing strategy
- Update dependencies to remove router/pinia references
- Clarify supporting components are optional and only if AccountViewView exceeds length limits

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

@@ -16,9 +16,8 @@ This plan outlines the integration of `@timesafari/daily-notification-plugin` in
 
 - **Platform**: All platforms (Capacitor provides full functionality, Web/Electron return null)
 - **Architecture**: PlatformService interface integration (all platforms implement, unsupported return null)
-- **Components**: Home view (diagnostics/status), Schedule view (time setting), AccountViewView integration (settings UI)
+- **Components**: AccountViewView integration (settings UI) with optional supporting components
-- **Store**: Pinia store for notification state management
+- **Store**: No store needed - state managed locally in AccountViewView
-- **Routes**: New routes for schedule, notifications, history, settings views
 
 ---
 
@@ -27,10 +26,10 @@ This plan outlines the integration of `@timesafari/daily-notification-plugin` in
 ### Technical Complexity: **Medium**
 
 #### Code Changes
-- **Medium**: New Vue components, Pinia store, router routes
+- **Medium**: AccountViewView modification, optional supporting components
 - **Pattern**: Following PlatformService interface pattern (like camera, filesystem methods) - all platforms implement, unsupported return null
 - **Integration**: Plugin API integration with error handling
-- **UI Integration**: AccountViewView modification with new notification section
+- **UI Integration**: AccountViewView modification with new notification section and optional supporting components
 
 #### Platform Impact
 - **Single Platform**: Capacitor-only (Android/iOS)
@@ -50,9 +49,7 @@ This plan outlines the integration of `@timesafari/daily-notification-plugin` in
 
 #### Internal Dependencies
 - **Medium**: 
-  - Router configuration (new routes)
+  - Optional supporting components (only if AccountViewView exceeds length limits)
-  - Store creation (Pinia)
-  - Component dependencies (ActionCard, StatusCard)
   - Logger integration (replace console.* with project logger)
   - AccountViewView modifications
   - Settings schema updates
@@ -82,10 +79,7 @@ This plan outlines the integration of `@timesafari/daily-notification-plugin` in
    - **Mitigation**: Use dynamic imports with platform checks, graceful fallbacks
 
 4. **Store State Management**: Notification state persistence
-   - **Mitigation**: Follow existing Pinia patterns in codebase
+   - **Mitigation**: State managed locally in AccountViewView - no store needed
-
-5. **AccountViewView Integration**: UI changes must not affect existing functionality
-   - **Mitigation**: Use platform capability detection, hide UI on unsupported platforms
 
 ---
 
@@ -130,9 +124,8 @@ if (status === null) {
 - Components handle capability detection via method results, not environment variables
 
 **Component Visibility Requirements**:
-- **ScheduleView**: Must check platform support and hide/render placeholder if unsupported
 - **AccountViewView notification section**: Must use `v-if="notificationsSupported"` to hide section
-- **NotificationSettingsView**: Must check platform support before rendering
+- **Supporting components** (if created): Must check platform support before rendering
 - **Any component providing scheduling UI**: Must verify `getDailyNotificationStatus() !== null` before showing scheduling controls
 
 ### Web/Electron Implementation Strategy
@@ -262,55 +255,18 @@ export interface NativeFetcherConfig {
 #### Views Structure
 ```
 src/views/
-  ├── HomeView.vue (existing - modify to add notification diagnostics)
-  ├── ScheduleView.vue (new - notification scheduling)
-  ├── NotificationsView.vue (new - view scheduled notifications)
-  ├── NotificationHistoryView.vue (new - notification history)
-  ├── NotificationSettingsView.vue (new - notification settings)
   └── AccountViewView.vue (existing - add Daily Notifications section)
 ```
 
-#### Supporting Components
+#### Supporting Components (Optional - Only if AccountViewView needs extraction)
-```
-src/components/cards/
-  ├── ActionCard.vue (new - reusable action card)
-  └── StatusCard.vue (new - reusable status card)
-```
-
-#### Store Structure
 ```
-src/stores/
+src/components/notifications/ (optional)
-  └── app.ts (new - Pinia store for app-wide state)
+  ├── NotificationToggle.vue (optional - extract toggle if AccountViewView too long)
-    - notificationStatus: NotificationStatus | null
+  ├── NotificationTimePicker.vue (optional - extract time picker if needed)
-    - platform: 'web' | 'capacitor' | 'electron'
+  └── NotificationStatusDisplay.vue (optional - extract status display if needed)
-    - setNotificationStatus(status): void
 ```
 
-### Router Integration
+**Note**: Supporting components should only be created if AccountViewView exceeds reasonable length limits (>200 lines). Keep everything in AccountViewView if possible.
-
-```typescript
-// src/router/index.ts - Add new routes
-{
-  path: "/schedule",
-  name: "schedule",
-  component: () => import("../views/ScheduleView.vue"),
-},
-{
-  path: "/notifications",
-  name: "notifications",
-  component: () => import("../views/NotificationsView.vue"),
-},
-{
-  path: "/history",
-  name: "notification-history",
-  component: () => import("../views/NotificationHistoryView.vue"),
-},
-{
-  path: "/settings",
-  name: "settings",
-  component: () => import("../views/NotificationSettingsView.vue"),
-},
-```
 
 ---
 
@@ -580,7 +536,6 @@ async disableNativeNotification() {
 ```typescript
 async editNativeNotificationTime() {
   // Show inline HTML5 time input for quick changes
-  // For complex editing (title, message), navigate to ScheduleView
   this.showTimeEdit = true;
 }
 ```
@@ -637,7 +592,7 @@ interface Settings {
 
 #### Edit Approach ✅
 - **Selected**: Inline HTML5 time input for quick edits in AccountViewView
-- **Note**: For complex editing (title, message changes), users can navigate to dedicated ScheduleView
+- **Note**: All editing happens within AccountViewView - no separate views needed
 
 #### Settings Field Names ✅
 - **Selected**: `nativeNotificationTime`, `nativeNotificationTitle`, `nativeNotificationMessage`
@@ -669,62 +624,33 @@ interface Settings {
    - Implement in `WebPlatformService` with null returns / error throws
    - Implement in `ElectronPlatformService` with null returns / error throws
 
-3. **Pinia Store Setup**
+3. **Settings Schema Extension**
-   - Create `src/stores/app.ts` with notification state
+   - Add notification settings fields to Settings interface
-   - Define `NotificationStatus` interface
+   - Update settings persistence methods if needed
-   - Implement `setNotificationStatus()` action
-   - Add platform detection to store
-
-4. **Native Fetcher Configuration Integration**
-   - Update HomeView `configureNativeFetcher()` to use active DID management
-   - Replace `TEST_USER_ZERO_CONFIG` references with `$getActiveIdentity()`
-   - Replace `generateEndorserJWT` with `createEndorserJwtForDid()` from `src/libs/endorserServer.ts`
-   - Get `apiServer` and `starredPlanHandleIds` from `$accountSettings()`
-
-5. **Router Routes**
-   - Add route definitions for schedule, notifications, history, settings
-   - Test route navigation
 
 #### Acceptance Criteria
 - [ ] PlatformService interface extended with notification methods
 - [ ] CapacitorPlatformService implements notification methods using plugin
 - [ ] WebPlatformService and ElectronPlatformService return null/throw errors appropriately
-- [ ] Pinia store created and tested
+- [ ] Settings schema extended with notification fields
-- [ ] HomeView `configureNativeFetcher()` updated to use active DID (no TEST_USER_ZERO_CONFIG)
-- [ ] Routes added and accessible
 - [ ] No build errors in web/electron builds
 
 ---
 
-### Phase 2: Core Components & AccountViewView Integration
+### Phase 2: AccountViewView Integration
 
 **Complexity**: Medium  
-**Goals**: Create reusable components, main views, and AccountViewView integration
+**Goals**: Integrate notification scheduling into AccountViewView with optional supporting components
 
 #### Tasks
-1. **Reusable Components**
+1. **Supporting Components (Optional)**
-   - Create `ActionCard.vue` component
+   - Create supporting components only if AccountViewView exceeds length limits
-   - Create `StatusCard.vue` component
+   - Consider: `NotificationToggle.vue`, `NotificationTimePicker.vue`, `NotificationStatusDisplay.vue`
    - Follow project styling patterns
    - Add TypeScript interfaces
+   - Keep components focused and reusable within AccountViewView context
 
-2. **Home View Integration**
+2. **AccountViewView Integration** ✅ **ACCEPTED**
-   - Modify existing `HomeView.vue` OR create new notification home view
-   - Integrate plugin diagnostics
-   - Add system status display
-   - Connect to Pinia store
-   - Replace `console.*` with project logger
-
-3. **Schedule View**
-   - Create `ScheduleView.vue` (provided code as reference)
-   - **REQUIRED**: Check platform support on mount - hide component if `getDailyNotificationStatus()` returns `null`
-   - **REQUIRED**: Render placeholder/unsupported message if device doesn't support scheduling
-   - Integrate with PlatformService via PlatformServiceFactory
-   - Add error handling
-   - Replace `console.*` with project logger
-   - Add loading states
-
-4. **AccountViewView Integration** ✅ **ACCEPTED**
    - Add separate "Daily Notifications" section
    - Check platform capabilities before showing UI (`v-if="notificationsSupported"`)
    - Add computed property for platform capability detection
@@ -739,10 +665,7 @@ interface Settings {
    - Add error handling and user feedback
 
 #### Acceptance Criteria
-- [ ] ActionCard and StatusCard components created
+- [ ] Supporting components created only if AccountViewView exceeds length limits
-- [ ] Home view shows notification diagnostics
-- [ ] Schedule view allows notification scheduling
-- [ ] **ScheduleView hides itself on unsupported platforms** (returns null check)
 - [ ] AccountViewView has separate "Daily Notifications" section
 - [ ] **AccountViewView notification section hidden on unsupported platforms** (`v-if="notificationsSupported"`)
 - [ ] Notification section checks PlatformService capabilities before showing
@@ -756,84 +679,40 @@ interface Settings {
 
 ---
 
-### Phase 3: Supporting Views & Configuration
+### Phase 3: Polish & Testing
 
 **Complexity**: Medium  
-**Goals**: Complete all views and native fetcher configuration
+**Goals**: Complete AccountViewView integration, error handling, and testing
 
 #### Tasks
-1. **Supporting Views**
+1. **Permission Management**
-   - Create `NotificationsView.vue` (list scheduled notifications)
+   - Implement permission request flow in AccountViewView
-     - **REQUIRED**: Hide component if `getDailyNotificationStatus()` returns `null`
-   - Create `NotificationHistoryView.vue` (notification history)
-     - **REQUIRED**: Hide component if `getDailyNotificationStatus()` returns `null`
-   - Create `NotificationSettingsView.vue` (settings/preferences)
-     - **REQUIRED**: Hide component if `getDailyNotificationStatus()` returns `null`
-
-2. **Native Fetcher Configuration**
-   - Integrate `configureNativeFetcher()` in HomeView
-   - Use `$getActiveIdentity()` to get active DID (replace TEST_USER_ZERO_CONFIG)
-   - Use `createEndorserJwtForDid()` for JWT generation
-   - Get `apiServer` and `starredPlanHandleIds` from `$accountSettings()`
-   - Add error handling for configuration failures
-
-3. **Permission Management**
-   - Implement permission request flow
    - Handle permission denial gracefully
    - Update status after permission changes
+   - Show appropriate user feedback
+
+2. **Error Handling & User Feedback**
+   - Add comprehensive error handling for all plugin operations
+   - Implement loading states during async operations
+   - Add success/error toast notifications
+   - Handle edge cases (permission denied, plugin unavailable, etc.)
+
+3. **Testing & Validation**
+   - Test AccountViewView integration on Capacitor platforms
+   - Verify component hiding on Web/Electron
+   - Test all user workflows (enable, disable, edit time)
+   - Verify settings persistence
 
 #### Acceptance Criteria
-- [ ] All supporting views created and functional
-- [ ] **All notification views hide themselves on unsupported platforms**
-- [ ] Native fetcher configuration working
 - [ ] Permission requests handled properly
 - [ ] Status updates after permission changes
 - [ ] Error handling for all failure cases
+- [ ] User feedback (toasts, loading states) implemented
+- [ ] AccountViewView tested on all platforms
+- [ ] Component hiding verified on unsupported platforms
 
 ---
 
-### Phase 4: Testing & Validation
-
-**Complexity**: Medium-High  
-**Goals**: Comprehensive testing across platforms and scenarios
-
-#### Tasks
-1. **Capacitor Testing**
-   - Test plugin availability detection
-   - Test notification scheduling on Android
-   - Test notification scheduling on iOS
-   - Test permission requests
-   - Test status updates
-   - Test native fetcher configuration
-   - Test AccountViewView integration on Capacitor
-
-2. **Cross-Platform Validation**
-   - Verify web build doesn't break
-   - Verify Electron build doesn't break
-   - Verify feature is hidden on non-Capacitor platforms
-   - Verify AccountViewView section hidden on web/electron
-   - Test graceful degradation
-
-3. **Integration Testing**
-   - Test full scheduling workflow
-   - Test status checking workflow
-   - Test navigation between views
-   - Test store state persistence
-   - Test AccountViewView enable/disable/edit workflows
-
-4. **Error Scenarios**
-   - Test plugin unavailable scenarios
-   - Test permission denied scenarios
-   - Test network failures (for native fetcher)
-   - Test invalid configuration scenarios
-
-#### Acceptance Criteria
-- [ ] All Capacitor tests passing
-- [ ] Web/Electron builds unaffected
-- [ ] AccountViewView integration verified on all platforms
-- [ ] Integration tests passing
-- [ ] Error scenarios handled gracefully
-- [ ] Documentation updated
 
 ---
 
@@ -842,30 +721,22 @@ interface Settings {
 ### Milestone 1: Foundation Complete
 **Success Criteria**:
 - PlatformService interface extended
-- Store created and tested
+- Settings schema extended
-- Routes accessible
 - No build regressions
 
-### Milestone 2: Core Features Operational
+### Milestone 2: AccountViewView Integration Complete
 **Success Criteria**:
-- Home view shows diagnostics
+- AccountViewView notification section functional
-- Schedule view functional
-- AccountViewView integration complete
 - Plugin integration working
-- Logging standardized
+- Settings persistence working
+- Component hiding verified on unsupported platforms
 
-### Milestone 3: Full Feature Set
+### Milestone 3: Production Ready
-**Success Criteria**:
-- All views created and functional
-- Native fetcher configured
-- Permissions managed properly
-- Status updates working
-
-### Milestone 4: Production Ready
 **Success Criteria**:
 - All tests passing
 - Cross-platform validation complete
 - Error handling robust
+- User feedback implemented
 - Documentation complete
 
 ---
@@ -873,17 +744,16 @@ interface Settings {
 ## Testing Strategy
 
 ### Unit Tests
-- Factory service platform detection
+- PlatformService platform detection
-- Store actions and state management
-- Component rendering and interactions
 - AccountViewView notification section rendering
+- Supporting component rendering (if created)
 
 ### Integration Tests
-- Plugin API calls
+- Plugin API calls from AccountViewView
 - Permission flows
 - Status updates
-- Navigation between views
 - AccountViewView enable/disable/edit workflows
+- Settings persistence
 
 ### Platform Tests
 - **Capacitor Android**: Notification scheduling, permissions, status, AccountViewView UI
@@ -892,11 +762,11 @@ interface Settings {
 - **Electron**: Feature hidden, no errors, AccountViewView section hidden
 
 ### E2E Tests (Playwright)
-- Full notification scheduling workflow
+- AccountViewView notification configuration workflow
 - Permission request flow
-- Status checking workflow
+- Enable/disable notification workflow
+- Edit notification time workflow
 - Error handling scenarios
-- AccountViewView notification configuration workflow
 
 ---
 
@@ -906,22 +776,16 @@ interface Settings {
 - `@timesafari/daily-notification-plugin` (to be added)
 - `@capacitor/core` (already in project)
 - `vue` (already in project)
-- `vue-router` (already in project)
-- `pinia` (already in project)
 
 ### Internal Dependencies
 - Logger service (`@/utils/logger`)
 - Platform detection utilities
-- Router configuration
 - Existing component patterns
 - AccountViewView component
 - Settings schema and persistence
 
 ### Configuration Dependencies
-- **Active DID Management**: Use `$getActiveIdentity()` from `PlatformServiceMixin` (existing)
+- **Settings Access**: Use `$accountSettings()` and `$saveSettings()` for persistence (existing)
-- **JWT Generation**: Use `createEndorserJwtForDid(activeDid, payload)` from `src/libs/endorserServer.ts` (existing)
-- **Settings Access**: Use `$accountSettings()` for `apiServer` and `starredPlanHandleIds` (existing)
-- **No new config files needed**: Replace `TEST_USER_ZERO_CONFIG` references with active DID and settings
 
 ---
 
@@ -973,23 +837,16 @@ async mounted() {
 
 #### Components That Must Implement This Pattern
 
-1. **ScheduleView.vue**: Check support on mount, hide if unsupported
+1. **AccountViewView.vue**: Daily Notifications section uses `v-if="notificationsSupported"`
-2. **AccountViewView.vue**: Daily Notifications section uses `v-if="notificationsSupported"`
+2. **Supporting components** (if created): Must check support before rendering any scheduling UI
-3. **NotificationSettingsView.vue**: Check support, hide if unsupported
+3. **Any component providing scheduling UI**: Must verify `getDailyNotificationStatus() !== null` before showing scheduling controls
-4. **NotificationsView.vue**: Check support, hide if unsupported
-5. **NotificationHistoryView.vue**: Check support, hide if unsupported
-6. **Any other component providing scheduling UI**: Must check and hide if unsupported
 
 #### Verification Checklist
 
-- [ ] ScheduleView checks platform support and hides on unsupported platforms
 - [ ] AccountViewView notification section hidden via `v-if` on unsupported platforms
-- [ ] NotificationSettingsView checks and hides on unsupported platforms
+- [ ] Supporting components (if created) check and hide on unsupported platforms
-- [ ] NotificationsView checks and hides on unsupported platforms
-- [ ] NotificationHistoryView checks and hides on unsupported platforms
 - [ ] All components tested on Web/Electron to verify hiding works
 - [ ] No console errors when components are hidden
-- [ ] Routes remain accessible but components show unsupported message (for ScheduleView)
 
 ### Code Quality Standards
 - **Logging**: Use `logger` from `@/utils/logger`, not `console.*`
@@ -1000,10 +857,8 @@ async mounted() {
 - **Line Length**: Keep methods < 80 columns when possible
 
 ### Architecture Patterns to Follow
-- **Factory Pattern**: Like `QRScannerFactory` for conditional loading
 - **Service Interface**: Abstract interface with platform implementations
-- **Store Pattern**: Pinia store for state management
+- **Component Organization**: Keep AccountViewView concise - extract supporting components if needed to maintain < 200 lines
-- **Composition API vs Class**: Use provided code style (Composition API for HomeView, Class for ScheduleView)
 - **PlatformService Pattern**: Check capabilities via method results, not environment variables
 
 ### PlatformService Integration Strategy
@@ -1061,21 +916,14 @@ await platformService.scheduleDailyNotification({
 - Ensure no static plugin imports
 - Verify AccountViewView section properly hidden
 
-### Risk 4: Configuration Dependencies (RESOLVED)
+### Risk 4: AccountViewView Integration Issues
-**Mitigation**: 
-- **Use existing active DID management**: Use `$getActiveIdentity()` from `PlatformServiceMixin` to get currently selected DID
-- **Use existing JWT generation**: Use `createEndorserJwtForDid(activeDid, payload)` from `src/libs/endorserServer.ts`
-- **Use existing settings**: Get `apiServer` and `starredPlanHandleIds` from `$accountSettings()`
-- **No config files needed**: The HomeView component code references `TEST_USER_ZERO_CONFIG`, but should instead use the currently active DID and settings
-
-### Risk 5: AccountViewView Integration Issues
 **Mitigation**:
 - Use platform capability detection before showing UI
 - Test on all platforms to ensure proper hiding
 - Follow existing UI patterns for consistency
 - Add comprehensive error handling
 
-### Risk 6: Components Visible on Unsupported Platforms
+### Risk 5: Components Visible on Unsupported Platforms
 **Mitigation**:
 - **REQUIRED**: All scheduling components must check `getDailyNotificationStatus()` and hide if `null`
 - Use `v-if="notificationsSupported"` pattern consistently
@@ -1090,11 +938,9 @@ await platformService.scheduleDailyNotification({
 - [ ] Plugin integrated using PlatformService architecture
 - [ ] Feature works on Capacitor (Android/iOS)
 - [ ] Feature hidden/graceful on Web/Electron
-- [ ] All components created and functional
-- [ ] **All scheduling components hide themselves on unsupported platforms**
 - [ ] AccountViewView integration complete and functional
-- [ ] Store manages notification state
+- [ ] **AccountViewView notification section hides itself on unsupported platforms**
-- [ ] Router routes accessible
+- [ ] Settings persist across app restarts
 - [ ] Logging standardized (no console.*)
 - [ ] Error handling robust
 - [ ] Cross-platform testing complete
@@ -1107,11 +953,10 @@ await platformService.scheduleDailyNotification({
 ## Next Steps
 
 1. **Verify Plugin Package**: Confirm `@timesafari/daily-notification-plugin` availability
-2. **Update HomeView Configuration**: Replace `TEST_USER_ZERO_CONFIG` references in HomeView with existing active DID management (`$getActiveIdentity()`, `createEndorserJwtForDid()`, `$accountSettings()`)
+2. **Extend PlatformService**: Add notification methods to PlatformService interface and implement in all platform services
-3. **Extend PlatformService**: Add notification methods to PlatformService interface and implement in all platform services
+3. **Extend Settings Schema**: Add notification fields to Settings interface
-4. **Set Up Store**: Create Pinia store for notification state
+4. **Begin Phase 1 Implementation**: Start with foundation tasks
-5. **Begin Phase 1 Implementation**: Start with foundation tasks
+5. **AccountViewView Integration**: Implement Daily Notifications section in Phase 2
-6. **AccountViewView Integration**: Implement Daily Notifications section in Phase 2
 
 ---