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

@@ -0,0 +1,306 @@
+# .cursor Rules Organization
+
+This directory contains all the rules and guidelines for AI assistants working
+with the TimeSafari project.
+
+## Directory Structure
+
+### **`core/`** - Core Principles and Context
+
+Core rules that apply to all AI interactions and provide fundamental context.
+
+- **`base_context.mdc`** - Human competence first principles and interaction guidelines
+- **`harbor_pilot_universal.mdc`** - Technical guide creation and investigation rules
+- **`less_complex.mdc`** - Minimalist solution principle and complexity guidelines
+
+### **`development/`** - Development Practices and Standards
+
+Rules for software development, coding standards, and development workflows.
+
+- **`software_development.mdc`** - Core development principles and evidence requirements
+- **`type_safety_guide.mdc`** - TypeScript type safety guidelines and best practices
+- **`development_guide.mdc`** - Development environment setup and standards
+- **`logging_standards.mdc`** - Logging implementation standards and rules
+- **`logging_migration.mdc`** - Migration from console.* to structured logging
+- **`time.mdc`** - Time handling principles and UTC standards
+- **`time_examples.mdc`** - Practical time implementation examples
+- **`time_implementation.mdc`** - Detailed time implementation guidelines
+- **`realistic_time_estimation.mdc`** - Time estimation framework and principles
+- **`planning_examples.mdc`** - Planning examples and best practices
+- **`complexity_assessment.mdc`** - Complexity evaluation and assessment
+- **`dependency_management.mdc`** - Dependency management and version control
+- **`asset_configuration.mdc`** - Asset configuration and build integration
+- **`research_diagnostic.mdc`** - Research and investigation workflows
+- **`investigation_report_example.mdc`** - Investigation report templates and examples
+- **`historical_comment_management.mdc`** - Historical comment transformation rules
+- **`historical_comment_patterns.mdc`** - Comment transformation patterns and examples
+
+### **`architecture/`** - Architecture and Design Patterns
+
+Rules for architectural decisions, patterns, and system design.
+
+- **`build_architecture_guard.mdc`** - Build system protection and change levels
+- **`build_validation.mdc`** - Build validation procedures and testing
+- **`build_testing.mdc`** - Build testing requirements and feedback collection
+
+### **`app/`** - Application-Specific Rules
+
+Rules specific to the TimeSafari application and its architecture.
+
+- **`timesafari.mdc`** - Core application context and principles
+- **`timesafari_platforms.mdc`** - Platform-specific implementation guidelines
+- **`timesafari_development.mdc`** - TimeSafari development workflow
+- **`architectural_decision_record.mdc`** - ADR creation and management
+- **`architectural_implementation.mdc`** - Architecture implementation guidelines
+- **`architectural_patterns.mdc`** - Architectural patterns and examples
+- **`architectural_examples.mdc`** - Architecture examples and testing
+
+### **`database/`** - Database and Data Management
+
+Rules for database operations, migrations, and data handling.
+
+- **`absurd-sql.mdc`** - Absurd SQL implementation and worker thread setup
+- **`legacy_dexie.mdc`** - Legacy Dexie migration guidelines
+
+### **`workflow/`** - Process and Workflow Management
+
+Rules for development workflows, version control, and process management.
+
+- **`version_control.mdc`** - Version control principles and commit guidelines
+- **`version_sync.mdc`** - Version synchronization and changelog management
+- **`commit_messages.mdc`** - Commit message format and conventions
+
+### **`features/** - Feature-Specific Implementations
+
+Rules for implementing specific features across platforms.
+
+- **`camera-implementation.mdc`** - Camera feature implementation overview
+- **`camera_technical.mdc`** - Technical camera implementation details
+- **`camera_platforms.mdc`** - Platform-specific camera implementation
+
+### **`docs/`** - Documentation Standards
+
+Rules for creating and maintaining documentation.
+
+- **`markdown_core.mdc`** - Core markdown formatting standards
+- **`markdown_templates.mdc`** - Document templates and examples
+- **`markdown_workflow.mdc`** - Markdown validation and workflow
+- **`documentation.mdc`** - Documentation generation principles
+- **`meta_rule_usage_guide.md`** - How to use meta-rules in practice
+
+### **`templates/`** - Templates and Examples
+
+Template files and examples for various documentation types.
+
+- **`adr_template.mdc`** - Architectural Decision Record template
+
+### **Meta-Rules** - Workflow Bundling
+
+High-level meta-rules that bundle related sub-rules for specific workflows.
+
+- **`meta_core_always_on.mdc`** - Core rules that apply to every single prompt
+- **`meta_documentation.mdc`** - Documentation writing and education workflow
+- **`meta_feature_planning.mdc`** - Feature planning workflow bundling
+- **`meta_bug_diagnosis.mdc`** - Bug investigation workflow bundling
+- **`meta_bug_fixing.mdc`** - Bug fix implementation workflow bundling
+- **`meta_feature_implementation.mdc`** - Feature implementation workflow bundling
+- **`meta_research.mdc`** - Investigation and research workflow bundling
+
+### **Workflow State Management**
+
+The project uses a sophisticated workflow state management system to ensure systematic development processes and maintain code quality across all phases of development.
+
+#### **Workflow State System**
+
+The workflow state is managed through `.cursor/rules/.workflow_state.json` and enforces different modes with specific constraints. The system automatically tracks workflow progression and maintains a complete history of mode transitions.
+
+**Available Modes**:
+- **`diagnosis`** - Investigation and analysis phase (read-only)
+- **`fixing`** - Implementation and bug fixing phase (full access)
+- **`planning`** - Design and architecture phase (design only)
+- **`research`** - Investigation and research phase (investigation only)
+- **`documentation`** - Documentation writing phase (writing only)
+
+**Mode Constraints**:
+```json
+{
+  "diagnosis": {
+    "mode": "read_only",
+    "forbidden": ["modify", "create", "build", "commit"],
+    "allowed": ["read", "search", "analyze", "document"]
+  },
+  "fixing": {
+    "mode": "implementation",
+    "forbidden": [],
+    "allowed": ["modify", "create", "build", "commit", "test"]
+  }
+}
+```
+
+**Workflow History Tracking**:
+
+The system automatically maintains a `workflowHistory` array that records all mode transitions and meta-rule invocations:
+
+```json
+{
+  "workflowHistory": [
+    {
+      "mode": "research",
+      "invoked": "meta_core_always_on.mdc",
+      "timestamp": "2025-08-25T02:14:37Z"
+    },
+    {
+      "mode": "diagnosis",
+      "invoked": "meta_bug_diagnosis.mdc", 
+      "timestamp": "2025-08-25T02:14:37Z"
+    }
+  ]
+}
+```
+
+**History Entry Format**:
+- **`mode`**: The workflow mode that was activated
+- **`invoked`**: The specific meta-rule that triggered the mode change
+- **`timestamp`**: UTC timestamp when the mode transition occurred
+
+**History Purpose**:
+- **Workflow Continuity**: Track progression through development phases
+- **Meta-Rule Usage**: Monitor which rules are invoked and when
+- **Temporal Context**: Maintain chronological order of workflow changes
+- **State Persistence**: Preserve workflow history across development sessions
+- **Debugging Support**: Help diagnose workflow state issues
+- **Process Analysis**: Understand development patterns and meta-rule effectiveness
+
+#### **Commit Override System**
+
+The workflow includes a flexible commit override mechanism that allows commits on demand while maintaining workflow integrity:
+
+```json
+{
+  "overrides": {
+    "commit": {
+      "allowed": true,
+      "requires_override": true,
+      "override_reason": "user_requested"
+    }
+  }
+}
+```
+
+**Override Benefits**:
+- ✅ **Investigation Commits**: Document findings during diagnosis phases
+- ✅ **Work-in-Progress**: Commit partial solutions during complex investigations
+- ✅ **Emergency Fixes**: Commit critical fixes without mode transitions
+- ✅ **Flexible Workflow**: Maintain systematic approach while accommodating real needs
+
+**Override Limitations**:
+- ❌ **Does NOT bypass**: Version control rules, commit message standards, or security requirements
+- ❌ **Does NOT bypass**: Code quality standards, testing requirements, or documentation requirements
+
+#### **Workflow Enforcement**
+
+The system automatically enforces workflow constraints through the core always-on rules:
+
+**Before Every Interaction**:
+1. **Read current workflow state** from `.cursor/rules/.workflow_state.json`
+2. **Identify current mode** and its constraints
+3. **Validate user request** against current mode constraints
+4. **Enforce constraints** before generating response
+5. **Guide model behavior** based on current mode
+
+**Mode-Specific Enforcement**:
+- **Diagnosis Mode**: Blocks modification, creation, building, and commits
+- **Fixing Mode**: Allows full implementation and testing capabilities
+- **Planning Mode**: Focuses on design and architecture, blocks implementation
+- **Research Mode**: Enables investigation and analysis, blocks modification
+- **Documentation Mode**: Allows writing and editing, blocks implementation
+
+#### **Workflow Transitions**
+
+To change workflow modes, invoke the appropriate meta-rule:
+
+```bash
+# Switch to bug fixing mode
+@meta_bug_fixing.mdc
+
+# Switch to feature planning mode  
+@meta_feature_planning.mdc
+
+# Switch to documentation mode
+@meta_documentation.mdc
+```
+
+**Transition Requirements**:
+- **Mode Changes**: Require explicit meta-rule invocation
+- **State Updates**: Automatically update workflow state file
+- **Constraint Enforcement**: Immediately apply new mode constraints
+- **History Tracking**: Automatically maintained in `workflowHistory` array
+- **Timestamp Recording**: Each transition recorded with UTC timestamp
+
+#### **Integration with Development Process**
+
+The workflow system integrates seamlessly with existing development practices:
+
+**Version Control**:
+- All commits must follow TimeSafari commit message standards
+- Security audit checklists are enforced regardless of workflow mode
+- Documentation updates are required for substantial changes
+
+**Quality Assurance**:
+- Code quality standards (PEP8, TypeScript, etc.) are always enforced
+- Testing requirements apply to all implementation work
+- Documentation standards are maintained across all phases
+
+**Build System**:
+- Build Architecture Guard protects critical build files
+- Platform-specific build processes respect workflow constraints
+- Asset generation follows established patterns
+
+**Migration Context**:
+- Database migration work respects investigation vs. implementation phases
+- Component migration progress is tracked through workflow states
+
+## Usage Guidelines
+
+1. **Always-On Rules**: Start with `meta_core_always_on.mdc` for every
+   single prompt
+2. **Core Rules**: Always apply rules from `core/` directory
+3. **Context-Specific**: Use rules from appropriate subdirectories based on
+   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 `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
+   consistent formatting
+
+## Benefits of New Organization
+
+1. **Logical grouping** - Related rules are now co-located
+2. **Easier navigation** - Developers can quickly find relevant rules
+3. **Better maintainability** - Clear separation of concerns
+4. **Scalable structure** - Easy to add new rules in appropriate categories
+5. **Consistent cross-references** - All file links updated and working
+6. **Workflow bundling** - Meta-rules provide high-level workflow guidance
+7. **Feedback integration** - Built-in feedback mechanisms for continuous improvement
+8. **Educational focus** - Documentation emphasizes human competence over technical description
+
+## File Naming Convention
+
+- **Lowercase with underscores**: `file_name.mdc`
+- **Descriptive names**: Names clearly indicate the rule's purpose
+- **Consistent extensions**: All files use `.mdc` extension
+
+## Maintenance
+
+- **Cross-references**: Update when moving files between directories
+- **Markdown validation**: Run `npm run markdown:check` after any changes
+- **Organization**: Keep related rules in appropriate subdirectories
+- **Documentation**: Update this README when adding new rules or directories
+
+---
+
+**Status**: Active organization structure
+**Last Updated**: 2025-08-21
+**Maintainer**: Development team

.cursor/rules/always_on_rules.mdc

@@ -0,0 +1,192 @@
+# Meta-Rule: Core Always-On Rules
+
+**Author**: Matthew Raymer
+**Date**: 2025-08-21
+**Status**: 🎯 **ACTIVE** - Core rules for every prompt
+
+## Purpose
+
+This meta-rule bundles the core rules that should be applied to **every single
+prompt** because they define fundamental behaviors, principles, and context
+that are essential for all AI interactions.
+
+## When to Use
+
+**ALWAYS** - These rules apply to every single prompt, regardless of the task
+or context. They form the foundation for all AI assistant behavior.
+
+## Bundled Rules
+
+### **Core Human Competence Principles**
+
+- **`core/base_context.mdc`** - Human competence first principles, interaction
+  guidelines, and output contract requirements
+- **`core/less_complex.mdc`** - Minimalist solution principle and complexity
+  guidelines
+
+### **Time & Context Standards**
+
+- **`development/time.mdc`** - Time handling principles and UTC standards
+- **`development/time_examples.mdc`** - Practical time implementation examples
+- **`development/time_implementation.mdc`** - Detailed time implementation
+  guidelines
+
+### **Version Control & Process**
+
+- **`workflow/version_control.mdc`** - Version control principles and commit
+  guidelines
+- **`workflow/commit_messages.mdc`** - Commit message format and conventions
+
+### **Application Context**
+
+- **`app/timesafari.mdc`** - Core TimeSafari application context and
+  development principles
+- **`app/timesafari_development.mdc`** - TimeSafari-specific development
+  workflow and quality standards
+
+## Why These Rules Are Always-On
+
+### **Base Context**
+
+- **Human Competence First**: Every interaction must increase human competence
+- **Output Contract**: All responses must follow the required structure
+- **Competence Hooks**: Learning and collaboration must be built into every response
+
+### **Time Standards**
+
+- **UTC Consistency**: All timestamps must use UTC for system operations
+- **Evidence Collection**: Time context is essential for debugging and investigation
+- **Cross-Platform**: Time handling affects all platforms and features
+
+### **Version Control**
+
+- **Commit Standards**: Every code change must follow commit message conventions
+- **Process Consistency**: Version control affects all development work
+- **Team Collaboration**: Commit standards enable effective team communication
+
+### **Application Context**
+
+- **Platform Awareness**: Every task must consider web/mobile/desktop platforms
+- **Architecture Principles**: All work must follow TimeSafari patterns
+- **Development Standards**: Quality and testing requirements apply to all work
+
+## Application Priority
+
+### **Primary (Apply First)**
+
+1. **Base Context** - Human competence and output contract
+2. **Time Standards** - UTC and timestamp requirements
+3. **Application Context** - TimeSafari principles and platforms
+
+### **Secondary (Apply as Needed)**
+
+1. **Version Control** - When making code changes
+2. **Complexity Guidelines** - When evaluating solution approaches
+
+## Integration with Other Meta-Rules
+
+### **Feature Planning**
+
+- Base context ensures human competence focus
+- Time standards inform planning and estimation
+- Application context drives platform considerations
+
+### **Bug Diagnosis**
+
+- Base context ensures systematic investigation
+- Time standards enable proper evidence collection
+- Application context provides system understanding
+
+### **Bug Fixing**
+
+- Base context ensures quality implementation
+- Time standards maintain logging consistency
+- Application context guides testing strategy
+
+### **Feature Implementation**
+
+- Base context ensures proper development approach
+- Time standards maintain system consistency
+- Application context drives architecture decisions
+
+## Success Criteria
+
+- [ ] **Base context applied** to every single prompt
+- [ ] **Time standards followed** for all timestamps and logging
+- [ ] **Version control standards** applied to all code changes
+- [ ] **Application context considered** for all platform work
+- [ ] **Human competence focus** maintained in all interactions
+- [ ] **Output contract structure** followed in all responses
+
+## Common Pitfalls
+
+- **Don't skip base context** - loses human competence focus
+- **Don't ignore time standards** - creates inconsistent timestamps
+- **Don't forget application context** - misses platform considerations
+- **Don't skip version control** - creates inconsistent commit history
+- **Don't lose competence focus** - reduces learning value
+
+## Feedback & Improvement
+
+### **Rule Effectiveness Ratings (1-5 scale)**
+
+- **Base Context**: ___/5 - Comments: _______________
+- **Time Standards**: ___/5 - Comments: _______________
+- **Version Control**: ___/5 - Comments: _______________
+- **Application Context**: ___/5 - Comments: _______________
+
+### **Always-On Effectiveness**
+
+- **Consistency**: Are these rules applied consistently across all prompts?
+- **Value**: Do these rules add value to every interaction?
+- **Overhead**: Are these rules too burdensome for simple tasks?
+
+### **Integration Feedback**
+
+- **With Other Meta-Rules**: How well do these integrate with workflow rules?
+- **Context Switching**: Do these rules help or hinder context switching?
+- **Learning Curve**: Are these rules easy for new users to understand?
+
+### **Overall Experience**
+
+- **Quality Improvement**: Do these rules improve response quality?
+- **Efficiency**: Do these rules make interactions more efficient?
+- **Recommendation**: Would you recommend keeping these always-on?
+
+## Model Implementation Checklist
+
+### Before Every Prompt
+
+- [ ] **Base Context**: Ensure human competence principles are active
+- [ ] **Time Standards**: Verify UTC and timestamp requirements are clear
+- [ ] **Application Context**: Confirm TimeSafari context is loaded
+- [ ] **Version Control**: Prepare commit standards if code changes are needed
+
+### During Response Creation
+
+- [ ] **Output Contract**: Follow required response structure
+- [ ] **Competence Hooks**: Include learning and collaboration elements
+- [ ] **Time Consistency**: Apply UTC standards for all time references
+- [ ] **Platform Awareness**: Consider all target platforms
+
+### After Response Creation
+
+- [ ] **Validation**: Verify all always-on rules were applied
+- [ ] **Quality Check**: Ensure response meets competence standards
+- [ ] **Context Review**: Confirm application context was properly considered
+- [ ] **Feedback Collection**: Note any issues with always-on application
+
+---
+
+**See also**:
+
+- `.cursor/rules/meta_feature_planning.mdc` for workflow-specific rules
+- `.cursor/rules/meta_bug_diagnosis.mdc` for investigation workflows
+- `.cursor/rules/meta_bug_fixing.mdc` for fix implementation
+- `.cursor/rules/meta_feature_implementation.mdc` for feature development
+
+**Status**: Active core always-on meta-rule
+**Priority**: Critical (applies to every prompt)
+**Estimated Effort**: Ongoing reference
+**Dependencies**: All bundled sub-rules
+**Stakeholders**: All AI interactions, Development team

.cursor/rules/app/architectural_decision_record.mdc

@@ -1,7 +1,3 @@
----
-description: when you need to understand the system architecture or make changes that impact the system architecture
-alwaysApply: false
----
 # TimeSafari Cross-Platform Architecture Guide
 
 **Author**: Matthew Raymer
@@ -12,17 +8,20 @@ alwaysApply: false
 
 | Feature | Web (PWA) | Capacitor (Mobile) | Electron (Desktop) |
 |---------|-----------|--------------------|-------------------|
-| QR Code Scanning | WebInlineQRScanner | @capacitor-mlkit/barcode-scanning | Not Implemented |
+| QR Code Scanning | WebInlineQRScanner | @capacitor-mlkit/barcode-scanning |
+  Not Implemented |
 | Deep Linking | URL Parameters | App URL Open Events | Not Implemented |
 | File System | Limited (Browser API) | Capacitor Filesystem | Electron fs |
 | Camera Access | MediaDevices API | Capacitor Camera | Not Implemented |
-| Platform Detection | Web APIs | Capacitor.isNativePlatform() | process.env checks |
+| Platform Detection | Web APIs | Capacitor.isNativePlatform() | process.env
+  checks |
 
 ## 2. Project Structure
 
 ### Core Directories
 
 ```
+
 src/
 ├── components/     # Vue components
 ├── services/       # Platform services and business logic
@@ -37,14 +36,19 @@ src/
 ├── db/             # Database related code
 ├── interfaces/     # TypeScript interfaces
 └── assets/         # Static assets
+
 ```
 
 ### Entry Points
 
 - `main.ts` → Base entry
+
 - `main.common.ts` → Shared init
+
 - `main.capacitor.ts` → Mobile entry
+
 - `main.electron.ts` → Electron entry
+
 - `main.web.ts` → Web entry
 
 ## 3. Service Architecture
@@ -52,16 +56,18 @@ src/
 ### Service Organization
 
 ```tree
+
 services/
-├── QRScanner/           
+├── QRScanner/
 │   ├── WebInlineQRScanner.ts
 │   └── interfaces.ts
-├── platforms/          
+├── platforms/
 │   ├── WebPlatformService.ts
 │   ├── CapacitorPlatformService.ts
 │   └── ElectronPlatformService.ts
-└── factory/           
+└── factory/
     └── PlatformServiceFactory.ts
+
 ```
 
 ### Factory Pattern
@@ -74,279 +80,114 @@ Use a **singleton factory** to select platform services via
 ### QR Code Scanning
 
 - Define `QRScannerService` interface.
+
 - Implement platform-specific classes (`WebInlineQRScanner`, Capacitor,
+
   etc).
+
 - Provide `addListener` and `onStream` hooks for composability.
 
 ### Deep Linking
 
 - URL format: `timesafari://<route>[/<param>][?query=value]`
+
 - Web: `router.beforeEach` → parse query
+
 - Capacitor: `App.addListener("appUrlOpen", …)`
 
 ## 5. Build Process
 
 - `vite.config.common.mts` → shared config
+
 - Platform configs: `vite.config.web.mts`, `.capacitor.mts`,
+
   `.electron.mts`
+
 - Use `process.env.VITE_PLATFORM` for conditional loading.
 
 ```bash
+
 npm run build:web
 npm run build:capacitor
 npm run build:electron
+
 ```
 
 ## 6. Testing Strategy
 
-- **Unit tests** for services.
-- **Playwright** for Web + Capacitor:
-  - `playwright.config-local.ts` includes web + Pixel 5.
-- **Electron tests**: add `spectron` or Playwright-Electron.
-- Mark tests with platform tags:
+- **Unit Tests**: Jest for business logic and utilities
 
-  ```ts
-  test.skip(!process.env.MOBILE_TEST, "Mobile-only test");
-  ```
+- **E2E Tests**: Playwright for critical user journeys
 
-> 🔗 **Human Hook:** Before merging new tests, hold a short sync (≤15
-> min) with QA to align on coverage and flaky test risks.
+- **Platform Tests**: Test platform-specific implementations
 
-## 7. Error Handling
+- **Integration Tests**: Test service interactions
 
-- Global Vue error handler → logs with component name.
-- Platform-specific wrappers log API errors with platform prefix
-  (`[Capacitor API Error]`, etc).
-- Use structured logging (not `console.log`).
+## 7. Key Principles
 
-## 8. Best Practices
+### Platform Independence
 
-- Keep platform code **isolated** in `platforms/`.
-- Always define a **shared interface** first.
-- Use feature detection, not platform detection, when possible.
-- Dependency injection for services → improves testability.
-- Maintain **Competence Hooks** in PRs (2–3 prompts for dev
-  discussion).
+- **Abstract platform differences** behind interfaces
 
-## 9. Dependency Management
+- **Use factory pattern** for service selection
 
-- Key deps: `@capacitor/core`, `electron`, `vue`.
-- Use conditional `import()` for platform-specific libs.
+- **Maintain consistent APIs** across platforms
 
-## 10. Security Considerations
+- **Graceful degradation** when features unavailable
 
-- **Permissions**: Always check + request gracefully.
-- **Storage**: Secure storage for sensitive data; encrypt when possible.
-- **Audits**: Schedule quarterly security reviews.
+### Code Organization
 
-## 11. ADR Process
+- **Single responsibility** for each service
 
-- All major architecture choices → log in `doc/adr/`.
-- Use ADR template with Context, Decision, Consequences, Status.
-- Link related ADRs in PR descriptions.
+- **Interface segregation** for platform services
 
-> 🔗 **Human Hook:** When proposing a new ADR, schedule a 30-min
-> design sync for discussion, not just async review.
+- **Dependency injection** via mixins
 
-## 12. Collaboration Hooks
-
-- **QR features**: Sync with Security before merging → permissions &
-  privacy.
-- **New platform builds**: Demo in team meeting → confirm UX
-  differences.
-- **Critical ADRs**: Present in guild or architecture review.
-
-## Self-Check
-
-- [ ] Does this feature implement a shared interface?
-- [ ] Are fallbacks + errors handled gracefully?
-- [ ] Have relevant ADRs been updated/linked?
-- [ ] Did I add competence hooks or prompts for the team?
-- [ ] Was human interaction (sync/review/demo) scheduled?
+- **Composition over inheritance**
 
 ---
 
+**See also**:
+
+- `.cursor/rules/app/architectural_implementation.mdc` for
+
+  detailed implementation details
+
+- `.cursor/rules/app/architectural_patterns.mdc` for architectural patterns and
+
+  examples
+
 **Status**: Active architecture guidelines
-**Priority**: High
+**Priority**: Critical
 **Estimated Effort**: Ongoing reference
-**Dependencies**: Vue 3, Capacitor, Electron, Vite
+**Dependencies**: timesafari.mdc
 **Stakeholders**: Development team, Architecture team
 
-- [ ] Are fallbacks + errors handled gracefully?  
-- [ ] Have relevant ADRs been updated/linked?  
-- [ ] Did I add competence hooks or prompts for the team?  
-- [ ] Was human interaction (sync/review/demo) scheduled?  
-# TimeSafari Cross-Platform Architecture Guide
-
-**Author**: Matthew Raymer
-**Date**: 2025-08-19
-**Status**: 🎯 **ACTIVE** - Architecture guidelines
-
-## 1. Platform Support Matrix
-
-| Feature | Web (PWA) | Capacitor (Mobile) | Electron (Desktop) |
-|---------|-----------|--------------------|-------------------|
-| QR Code Scanning | WebInlineQRScanner | @capacitor-mlkit/barcode-scanning | Not Implemented |
-| Deep Linking | URL Parameters | App URL Open Events | Not Implemented |
-| File System | Limited (Browser API) | Capacitor Filesystem | Electron fs |
-| Camera Access | MediaDevices API | Capacitor Camera | Not Implemented |
-| Platform Detection | Web APIs | Capacitor.isNativePlatform() | process.env checks |
-
-## 2. Project Structure
-
-### Core Directories
-
-```
-src/
-├── components/     # Vue components
-├── services/       # Platform services and business logic
-├── views/          # Page components
-├── router/         # Vue router configuration
-├── types/          # TypeScript type definitions
-├── utils/          # Utility functions
-├── lib/            # Core libraries
-├── platforms/      # Platform-specific implementations
-├── electron/       # Electron-specific code
-├── constants/      # Application constants
-├── db/             # Database related code
-├── interfaces/     # TypeScript interfaces
-└── assets/         # Static assets
-```
-
-### Entry Points
-
-- `main.ts` → Base entry
-- `main.common.ts` → Shared init
-- `main.capacitor.ts` → Mobile entry
-- `main.electron.ts` → Electron entry
-- `main.web.ts` → Web entry
-
-## 3. Service Architecture
-
-### Service Organization
-
-```tree
-services/
-├── QRScanner/           
-│   ├── WebInlineQRScanner.ts
-│   └── interfaces.ts
-├── platforms/          
-│   ├── WebPlatformService.ts
-│   ├── CapacitorPlatformService.ts
-│   └── ElectronPlatformService.ts
-└── factory/           
-    └── PlatformServiceFactory.ts
-```
-
-### Factory Pattern
-
-Use a **singleton factory** to select platform services via
-`process.env.VITE_PLATFORM`.
-
-## 4. Feature Guidelines
-
-### QR Code Scanning
-
-- Define `QRScannerService` interface.
-- Implement platform-specific classes (`WebInlineQRScanner`, Capacitor,
-  etc).
-- Provide `addListener` and `onStream` hooks for composability.
-
-### Deep Linking
-
-- URL format: `timesafari://<route>[/<param>][?query=value]`
-- Web: `router.beforeEach` → parse query
-- Capacitor: `App.addListener("appUrlOpen", …)`
-
-## 5. Build Process
-
-- `vite.config.common.mts` → shared config
-- Platform configs: `vite.config.web.mts`, `.capacitor.mts`,
-  `.electron.mts`
-- Use `process.env.VITE_PLATFORM` for conditional loading.
-
-```bash
-npm run build:web
-npm run build:capacitor
-npm run build:electron
-```
-
-## 6. Testing Strategy
-
-- **Unit tests** for services.
-- **Playwright** for Web + Capacitor:
-  - `playwright.config-local.ts` includes web + Pixel 5.
-- **Electron tests**: add `spectron` or Playwright-Electron.
-- Mark tests with platform tags:
-
-  ```ts
-  test.skip(!process.env.MOBILE_TEST, "Mobile-only test");
-  ```
-
-> 🔗 **Human Hook:** Before merging new tests, hold a short sync (≤15
-> min) with QA to align on coverage and flaky test risks.
-
-## 7. Error Handling
-
-- Global Vue error handler → logs with component name.
-- Platform-specific wrappers log API errors with platform prefix
-  (`[Capacitor API Error]`, etc).
-- Use structured logging (not `console.log`).
-
-## 8. Best Practices
-
-- Keep platform code **isolated** in `platforms/`.
-- Always define a **shared interface** first.
-- Use feature detection, not platform detection, when possible.
-- Dependency injection for services → improves testability.
-- Maintain **Competence Hooks** in PRs (2–3 prompts for dev
-  discussion).
-
-## 9. Dependency Management
-
-- Key deps: `@capacitor/core`, `electron`, `vue`.
-- Use conditional `import()` for platform-specific libs.
-
-## 10. Security Considerations
-
-- **Permissions**: Always check + request gracefully.
-- **Storage**: Secure storage for sensitive data; encrypt when possible.
-- **Audits**: Schedule quarterly security reviews.
-
-## 11. ADR Process
-
-- All major architecture choices → log in `doc/adr/`.
-- Use ADR template with Context, Decision, Consequences, Status.
-- Link related ADRs in PR descriptions.
-
-> 🔗 **Human Hook:** When proposing a new ADR, schedule a 30-min
-> design sync for discussion, not just async review.
-
-## 12. Collaboration Hooks
-
-- **QR features**: Sync with Security before merging → permissions &
-  privacy.
-- **New platform builds**: Demo in team meeting → confirm UX
-  differences.
-- **Critical ADRs**: Present in guild or architecture review.
-
-## Self-Check
-
-- [ ] Does this feature implement a shared interface?
-- [ ] Are fallbacks + errors handled gracefully?
 - [ ] Have relevant ADRs been updated/linked?
+
 - [ ] Did I add competence hooks or prompts for the team?
+
 - [ ] Was human interaction (sync/review/demo) scheduled?
 
----
+## Model Implementation Checklist
 
-**Status**: Active architecture guidelines
-**Priority**: High
-**Estimated Effort**: Ongoing reference
-**Dependencies**: Vue 3, Capacitor, Electron, Vite
-**Stakeholders**: Development team, Architecture team
+### Before Architectural Decisions
 
-- [ ] Are fallbacks + errors handled gracefully?  
-- [ ] Have relevant ADRs been updated/linked?  
-- [ ] Did I add competence hooks or prompts for the team?  
-- [ ] Was human interaction (sync/review/demo) scheduled?  
+- [ ] **Decision Context**: Understand the architectural challenge to be addressed
+- [ ] **Stakeholder Identification**: Identify all decision makers and affected parties
+- [ ] **Research**: Research alternatives and gather evidence
+- [ ] **Impact Assessment**: Assess impact on existing architecture
+
+### During Architectural Decisions
+
+- [ ] **Context Documentation**: Document the context and forces at play
+- [ ] **Decision Recording**: Record the decision and rationale clearly
+- [ ] **Consequences Analysis**: Analyze positive, negative, and neutral consequences
+- [ ] **Alternatives Documentation**: Document alternatives considered and why rejected
+
+### After Architectural Decisions
+
+- [ ] **ADR Creation**: Create or update Architectural Decision Record
+- [ ] **Team Communication**: Communicate decision to all stakeholders
+- [ ] **Implementation Planning**: Plan implementation of the architectural decision
+- [ ] **Documentation Update**: Update relevant architectural documentation

.cursor/rules/app/architectural_examples.mdc

@@ -0,0 +1,246 @@
+# Time Safari Architecture — Examples and Testing
+
+> **Agent role**: Reference this file for architectural examples and
+  testing patterns when working with TimeSafari architecture.
+
+## Error Handling Patterns
+
+### Global Error Handler
+
+```typescript
+
+// main.ts
+app.config.errorHandler = (err, instance, info) => {
+  const componentName = instance?.$options?.name || 'Unknown';
+  logger.error(`[${componentName}] Vue error`, err, info);
+};
+
+window.addEventListener('unhandledrejection', (event) => {
+  logger.error('[Global] Unhandled promise rejection', event.reason);
+});
+
+```
+
+### Platform-Specific Error Wrapping
+
+```typescript
+
+// services/platforms/CapacitorPlatformService.ts
+export class CapacitorPlatformService {
+  async getFileContents(path: string): Promise<string> {
+    try {
+      const result = await Filesystem.readFile({
+        path: path,
+        encoding: 'utf8'
+      });
+      return result.data;
+    } catch (error) {
+      logger.error('[Capacitor API Error] Failed to read file', error, path);
+      throw new Error(`Failed to read file: ${path}`);
+    }
+  }
+}
+
+```
+
+## Testing Patterns
+
+### Platform-Specific Test Skipping
+
+```typescript
+
+// tests/QRScanner.test.ts
+describe('QRScanner Service', () => {
+  test('should start scanning on web', async () => {
+    test.skip(process.env.VITE_PLATFORM !== 'web', 'Web-only test');
+
+    const scanner = new WebInlineQRScanner();
+    await scanner.startScanning();
+    // Assert scanning started
+  });
+
+  test('should start scanning on mobile', async () => {
+    test.skip(process.env.VITE_PLATFORM !== 'capacitor', 'Mobile-only test');
+
+    const scanner = new CapacitorQRScanner();
+    await scanner.startScanning();
+    // Assert scanning started
+  });
+});
+
+```
+
+### Mock Service Testing
+
+```typescript
+
+// tests/mocks/QRScannerMock.ts
+export class QRScannerMock implements QRScannerService {
+  private isScanning = false;
+  private listeners: Map<string, Function[]> = new Map();
+
+  async startScanning(): Promise<void> {
+    this.isScanning = true;
+    this.emit('scanningStarted');
+  }
+
+  async stopScanning(): Promise<void> {
+    this.isScanning = false;
+    this.emit('scanningStopped');
+  }
+
+  addListener(event: string, callback: Function): void {
+    if (!this.listeners.has(event)) {
+      this.listeners.set(event, []);
+    }
+    this.listeners.get(event)!.push(callback);
+  }
+
+  removeListener(event: string, callback: Function): void {
+    const callbacks = this.listeners.get(event);
+    if (callbacks) {
+      const index = callbacks.indexOf(callback);
+      if (index > -1) {
+        callbacks.splice(index, 1);
+      }
+    }
+  }
+
+  private emit(event: string, ...args: any[]): void {
+    const callbacks = this.listeners.get(event);
+    if (callbacks) {
+      callbacks.forEach(callback => callback(...args));
+    }
+  }
+
+  getScanningState(): boolean {
+    return this.isScanning;
+  }
+}
+
+```
+
+## Integration Examples
+
+### Service Composition
+
+```typescript
+
+// services/QRScannerService.ts
+export class QRScannerService {
+  constructor(
+    private platformService: PlatformService,
+    private notificationService: NotificationService
+  ) {}
+
+  async startScanning(): Promise<void> {
+    try {
+      await this.platformService.startCamera();
+      this.notificationService.show('Camera started');
+    } catch (error) {
+      this.notificationService.showError('Failed to start camera');
+      throw error;
+    }
+  }
+}
+
+```
+
+### Component Integration
+
+```typescript
+
+// components/QRScannerDialog.vue
+export default class QRScannerDialog extends Vue {
+  @Inject() private qrScannerService!: QRScannerService;
+
+  async mounted() {
+    try {
+      await this.qrScannerService.startScanning();
+    } catch (error) {
+      this.$notify.error('Failed to start scanner');
+    }
+  }
+
+  beforeDestroy() {
+    this.qrScannerService.stopScanning();
+  }
+}
+
+```
+
+## Best Practices
+
+### Service Design
+
+- Keep services focused and single-purpose
+
+- Use dependency injection for service composition
+
+- Implement proper error handling and logging
+
+- Provide clear interfaces and contracts
+
+### Testing Strategy
+
+- Test platform-specific behavior separately
+
+- Use mocks for external dependencies
+
+- Test error conditions and edge cases
+
+- Validate service contracts and interfaces
+
+### Error Handling
+
+- Log errors with appropriate context
+
+- Provide user-friendly error messages
+
+- Implement graceful degradation
+
+- Handle platform-specific error scenarios
+
+---
+
+**See also**:
+
+- `.cursor/rules/app/architectural_decision_record.mdc` for
+
+  core architecture principles
+
+- `.cursor/rules/app/architectural_implementation.mdc` for
+
+  implementation details
+
+- `.cursor/rules/app/architectural_patterns.mdc` for core patterns
+
+**Status**: Active examples and testing guide
+**Priority**: Medium
+**Estimated Effort**: Ongoing reference
+**Dependencies**: architectural_patterns.mdc
+**Stakeholders**: Development team, Testing team
+
+## Model Implementation Checklist
+
+### Before Architectural Examples
+
+- [ ] **Pattern Selection**: Choose appropriate architectural pattern for the use
+  case
+- [ ] **Service Design**: Plan service structure and dependencies
+- [ ] **Testing Strategy**: Plan testing approach for the example
+- [ ] **Error Handling**: Plan error handling and logging strategy
+
+### During Architectural Examples
+
+- [ ] **Service Implementation**: Implement focused, single-purpose services
+- [ ] **Dependency Injection**: Use proper dependency injection patterns
+- [ ] **Error Handling**: Implement proper error handling and logging
+- [ ] **Interface Design**: Provide clear interfaces and contracts
+
+### After Architectural Examples
+
+- [ ] **Testing Execution**: Test platform-specific behavior separately
+- [ ] **Service Validation**: Validate service contracts and interfaces
+- [ ] **Error Testing**: Test error conditions and edge cases
+- [ ] **Documentation**: Update architectural examples documentation

.cursor/rules/app/architectural_implementation.mdc

@@ -0,0 +1,139 @@
+# Time Safari Architecture — Implementation Details
+
+> **Agent role**: Reference this file for detailed implementation details when
+  working with TimeSafari architecture implementation.
+
+## Error Handling
+
+- Global Vue error handler → logs with component name.
+
+- Platform-specific wrappers log API errors with platform prefix
+
+  (`[Capacitor API Error]`, etc).
+
+- Use structured logging (not `console.log`).
+
+## Best Practices
+
+- Keep platform code **isolated** in `platforms/`.
+
+- Always define a **shared interface** first.
+
+- Use feature detection, not platform detection, when possible.
+
+- Dependency injection for services → improves testability.
+
+- Maintain **Competence Hooks** in PRs (2–3 prompts for dev
+
+  discussion).
+
+## Dependency Management
+
+- Key deps: `@capacitor/core`, `electron`, `vue`.
+
+- Use conditional `import()` for platform-specific libs.
+
+## Security Considerations
+
+- **Permissions**: Always check + request gracefully.
+
+- **Storage**: Secure storage for sensitive data; encrypt when possible.
+
+- **Audits**: Schedule quarterly security reviews.
+
+## ADR Process
+
+- All major architecture choices → log in `doc/adr/`.
+
+- Use ADR template with Context, Decision, Consequences, Status.
+
+- Link related ADRs in PR descriptions.
+
+> 🔗 **Human Hook:** When proposing a new ADR, schedule a 30-min
+> design sync for discussion, not just async review.
+
+## Collaboration Hooks
+
+- **QR features**: Sync with Security before merging → permissions &
+
+  privacy.
+
+- **New platform builds**: Demo in team meeting → confirm UX
+
+  differences.
+
+- **Critical ADRs**: Present in guild or architecture review.
+
+## Testing Implementation
+
+- **Unit tests** for services.
+
+- **Playwright** for Web + Capacitor:
+
+  - `playwright.config-local.ts` includes web + Pixel 5.
+
+- **Electron tests**: add `spectron` or Playwright-Electron.
+
+- Mark tests with platform tags:
+
+  ```ts
+
+  test.skip(!process.env.MOBILE_TEST, "Mobile-only test");
+
+  ```
+
+> 🔗 **Human Hook:** Before merging new tests, hold a short sync (≤15
+> min) with QA to align on coverage and flaky test risks.
+
+## Self-Check
+
+- [ ] Does this feature implement a shared interface?
+
+- [ ] Are fallbacks + errors handled gracefully?
+
+- [ ] Have relevant ADRs been updated/linked?
+
+- [ ] Did I add competence hooks or prompts for the team?
+
+- [ ] Was human interaction (sync/review/demo) scheduled?
+
+---
+
+**See also**:
+
+- `.cursor/rules/app/architectural_decision_record.mdc` for
+
+  core architecture principles
+
+- `.cursor/rules/app/architectural_patterns.mdc` for architectural patterns and
+
+  examples
+
+**Status**: Active implementation guidelines
+**Priority**: High
+**Estimated Effort**: Ongoing reference
+**Dependencies**: architectural_decision_record.mdc
+**Stakeholders**: Development team, Architecture team
+
+## Model Implementation Checklist
+
+### Before Architectural Implementation
+
+- [ ] **Interface Review**: Verify feature implements shared interface
+- [ ] **ADR Review**: Check if ADR is required for major changes
+- [ ] **Security Assessment**: Assess security implications for QR features
+- [ ] **Platform Planning**: Plan platform-specific implementation details
+
+### During Architectural Implementation
+
+- [ ] **Interface Implementation**: Implement shared interfaces consistently
+- [ ] **Error Handling**: Implement graceful fallbacks and error handling
+- [ ] **Testing Strategy**: Plan unit tests for services and E2E tests
+- [ ] **Human Interaction**: Schedule syncs/reviews/demos as needed
+
+### After Architectural Implementation
+
+- [ ] **Interface Validation**: Verify shared interfaces are properly implemented
+- [ ] **Testing Execution**: Run unit tests and platform-specific tests
+- [ ] **ADR Updates**: Update relevant ADRs and link in PR descriptions
+- [ ] **Team Communication**: Share implementation results with team

.cursor/rules/app/architectural_patterns.mdc

@@ -0,0 +1,214 @@
+# Time Safari Architecture — Patterns and Examples
+
+> **Agent role**: Reference this file for architectural patterns and
+> examples when working with TimeSafari architecture design.
+
+## Architectural Patterns
+
+### Factory Pattern Implementation
+
+```typescript
+// PlatformServiceFactory.ts
+export class PlatformServiceFactory {
+  private static instance: PlatformServiceFactory;
+
+  static getInstance(): PlatformServiceFactory {
+    if (!PlatformServiceFactory.instance) {
+      PlatformServiceFactory.instance = new PlatformServiceFactory();
+    }
+    return PlatformServiceFactory.instance;
+  }
+
+  getQRScannerService(): QRScannerService {
+    const platform = process.env.VITE_PLATFORM;
+
+    switch (platform) {
+      case 'web':
+        return new WebInlineQRScanner();
+      case 'capacitor':
+        return new CapacitorQRScanner();
+      case 'electron':
+        return new ElectronQRScanner();
+      default:
+        throw new Error(`Unsupported platform: ${platform}`);
+    }
+  }
+}
+```
+
+### Service Interface Definition
+
+```typescript
+// interfaces/QRScannerService.ts
+export interface QRScannerService {
+  startScanning(): Promise<void>;
+  stopScanning(): Promise<void>;
+  addListener(event: string, callback: Function): void;
+  removeListener(event: string, callback: Function): void;
+}
+```
+
+### Platform-Specific Implementation
+
+```typescript
+// services/QRScanner/WebInlineQRScanner.ts
+export class WebInlineQRScanner implements QRScannerService {
+  private listeners: Map<string, Function[]> = new Map();
+
+  async startScanning(): Promise<void> {
+    // Web-specific implementation
+    const stream = await navigator.mediaDevices.getUserMedia({ video: true });
+    // Process video stream for QR codes
+  }
+
+  async stopScanning(): Promise<void> {
+    // Stop video stream
+  }
+
+  addListener(event: string, callback: Function): void {
+    if (!this.listeners.has(event)) {
+      this.listeners.set(event, []);
+    }
+    this.listeners.get(event)!.push(callback);
+  }
+
+  removeListener(event: string, callback: Function): void {
+    const callbacks = this.listeners.get(event);
+    if (callbacks) {
+      const index = callbacks.indexOf(callback);
+      if (index > -1) {
+        callbacks.splice(index, 1);
+      }
+    }
+  }
+}
+```
+
+## Deep Linking Implementation
+
+### URL Format
+
+```
+timesafari://<route>[/<param>][?query=value]
+```
+
+### Web Implementation
+
+```typescript
+// router/index.ts
+router.beforeEach((to, from, next) => {
+  // Parse deep link parameters
+  if (to.query.deepLink) {
+    const deepLink = to.query.deepLink as string;
+    // Process deep link
+    handleDeepLink(deepLink);
+  }
+  next();
+});
+
+function handleDeepLink(deepLink: string) {
+  // Parse and route deep link
+  const url = new URL(deepLink);
+  const route = url.pathname;
+  const params = url.searchParams;
+
+  // Navigate to appropriate route
+  router.push({ name: route, query: Object.fromEntries(params) });
+}
+```
+
+### Capacitor Implementation
+
+```typescript
+// main.capacitor.ts
+import { App } from '@capacitor/app';
+
+App.addListener('appUrlOpen', (data) => {
+  const url = data.url;
+  // Parse deep link and navigate
+  handleDeepLink(url);
+});
+```
+
+## Platform Detection
+
+### Feature Detection vs Platform Detection
+
+```typescript
+// ✅ Good: Feature detection
+function hasCameraAccess(): boolean {
+  return 'mediaDevices' in navigator &&
+         'getUserMedia' in navigator.mediaDevices;
+}
+
+// ❌ Bad: Platform detection
+function isWeb(): boolean {
+  return process.env.VITE_PLATFORM === 'web';
+}
+```
+
+### Conditional Imports
+
+```typescript
+// services/platforms/index.ts
+export async function getPlatformService() {
+  const platform = process.env.VITE_PLATFORM;
+
+  switch (platform) {
+    case 'capacitor':
+      const { CapacitorPlatformService } =
+        await import('./CapacitorPlatformService');
+      return new CapacitorPlatformService();
+    case 'electron':
+      const { ElectronPlatformService } =
+        await import('./ElectronPlatformService');
+      return new ElectronPlatformService();
+    default:
+      const { WebPlatformService } =
+        await import('./WebPlatformService');
+      return new WebPlatformService();
+  }
+}
+```
+
+---
+
+**See also**:
+
+- `.cursor/rules/app/architectural_decision_record.mdc` for core
+  architecture principles
+- `.cursor/rules/app/architectural_implementation.mdc` for
+  implementation details
+- `.cursor/rules/app/architectural_examples.mdc` for examples and
+  testing patterns
+
+**Status**: Active patterns and examples
+**Priority**: Medium
+**Estimated Effort**: Ongoing reference
+**Dependencies**: architectural_decision_record.mdc,
+  architectural_implementation.mdc
+**Stakeholders**: Development team, Architecture team
+
+## Model Implementation Checklist
+
+### Before Architectural Patterns
+
+- [ ] **Pattern Selection**: Choose appropriate architectural pattern for the use
+  case
+- [ ] **Platform Analysis**: Identify platform-specific requirements
+- [ ] **Service Planning**: Plan service structure and dependencies
+- [ ] **Testing Strategy**: Plan testing approach for the pattern
+
+### During Architectural Patterns
+
+- [ ] **Pattern Implementation**: Implement chosen architectural pattern
+- [ ] **Platform Abstraction**: Use platform abstraction layers appropriately
+- [ ] **Service Composition**: Compose services using dependency injection
+- [ ] **Interface Design**: Provide clear interfaces and contracts
+
+### After Architectural Patterns
+
+- [ ] **Pattern Validation**: Verify pattern is implemented correctly
+- [ ] **Platform Testing**: Test across all target platforms
+- [ ] **Service Testing**: Test service composition and dependencies
+- [ ] **Documentation**: Update architectural patterns documentation

.cursor/rules/app/timesafari.mdc

@@ -1,3 +1,6 @@
+---
+alwaysApply: false
+---
 # Time Safari Context
 
 **Author**: Matthew Raymer
@@ -15,10 +18,12 @@ that preserve privacy and data sovereignty.
 ## Core Goals
 
 1. **Connect**: Make it easy, rewarding, and non-threatening for people to
+
    connect with others who have similar interests, and to initiate activities
    together.
 
 2. **Reveal**: Widely advertise the great support and rewards that are being
+
    given and accepted freely, especially non-monetary ones, showing the impact
    gifts make in people's lives.
 
@@ -27,29 +32,45 @@ that preserve privacy and data sovereignty.
 ### Architecture
 
 - **Privacy-preserving claims architecture** via endorser.ch
+
 - **Decentralized Identifiers (DIDs)**: User identities based on
+
   public/private key pairs stored on devices
+
 - **Cryptographic Verification**: All claims and confirmations are
+
   cryptographically signed
+
 - **User-Controlled Visibility**: Users explicitly control who can see their
+
   identifiers and data
+
 - **Cross-Platform**: Web (PWA), Mobile (Capacitor), Desktop (Electron)
 
 ### Current Database State
 
 - **Database**: SQLite via Absurd SQL (browser) and native SQLite
+
   (mobile/desktop)
+
 - **Legacy Support**: IndexedDB (Dexie) for backward compatibility
+
 - **Status**: Modern database architecture fully implemented
 
 ### Core Technologies
 
 - **Frontend**: Vue 3 + TypeScript + vue-facing-decorator
+
 - **Styling**: TailwindCSS
+
 - **Build**: Vite with platform-specific configs
+
 - **Testing**: Playwright E2E, Jest unit tests
+
 - **Database**: SQLite (Absurd SQL in browser), IndexedDB (legacy)
+
 - **State**: Pinia stores
+
 - **Platform Services**: Abstracted behind interfaces with factory pattern
 
 ## Development Principles
@@ -57,22 +78,31 @@ that preserve privacy and data sovereignty.
 ### Code Organization
 
 - **Platform Services**: Abstract platform-specific code behind interfaces
+
 - **Service Factory**: Use `PlatformServiceFactory` for platform selection
+
 - **Type Safety**: Strict TypeScript, no `any` types, use type guards
+
 - **Modern Architecture**: Use current platform service patterns
 
 ### Architecture Patterns
 
 - **Dependency Injection**: Services injected via mixins and factory pattern
+
 - **Interface Segregation**: Small, focused interfaces over large ones
+
 - **Composition over Inheritance**: Prefer mixins and composition
+
 - **Single Responsibility**: Each component/service has one clear purpose
 
 ### Testing Strategy
 
 - **E2E**: Playwright for critical user journeys
+
 - **Unit**: Jest with F.I.R.S.T. principles
+
 - **Platform Coverage**: Web + Capacitor (Pixel 5) in CI
+
 - **Quality Assurance**: Comprehensive testing and validation
 
 ## Current Development Focus
@@ -80,102 +110,64 @@ that preserve privacy and data sovereignty.
 ### Active Development
 
 - **Feature Development**: Build new functionality using modern platform
+
   services
+
 - **Performance Optimization**: Improve app performance and user experience
+
 - **Platform Enhancement**: Leverage platform-specific capabilities
+
 - **Code Quality**: Maintain high standards and best practices
 
 ### Development Metrics
 
 - **Code Quality**: High standards maintained across all platforms
+
 - **Performance**: Optimized for all target devices
+
 - **Testing**: Comprehensive coverage maintained
+
 - **User Experience**: Focus on intuitive, accessible interfaces
 
-## Platform-Specific Considerations
-
-### Web (PWA)
-
-- **QR Scanning**: WebInlineQRScanner
-- **Deep Linking**: URL parameters
-- **File System**: Limited browser APIs
-- **Build**: `npm run build:web` (development build)
-
-### Mobile (Capacitor)
-
-- **QR Scanning**: @capacitor-mlkit/barcode-scanning
-- **Deep Linking**: App URL open events
-- **File System**: Capacitor Filesystem
-- **Build**: `npm run build:capacitor`
-
-### Desktop (Electron)
-
-- **File System**: Node.js fs
-- **Build**: `npm run build:electron`
-- **Distribution**: AppImage, DEB, DMG packages
-
-## Development Workflow
-
-### Build Commands
-
-```bash
-# Web (development)
-npm run build:web
-
-# Mobile
-npm run build:capacitor
-npm run build:native
-
-# Desktop
-npm run build:electron
-npm run build:electron:appimage
-npm run build:electron:deb
-npm run build:electron:dmg
-```
-
-### Testing Commands
-
-```bash
-# Web E2E
-npm run test:web
-
-# Mobile
-npm run test:mobile
-npm run test:android
-npm run test:ios
-
-# Type checking
-npm run type-check
-npm run lint-fix
-```
-
-## Key Constraints
-
-1. **Privacy First**: User identifiers remain private except when explicitly
-   shared
-2. **Platform Compatibility**: Features must work across all target platforms
-3. **Performance**: Must remain performant on older/simpler devices
-4. **Modern Architecture**: New features should use current platform services
-5. **Offline Capability**: Key functionality should work offline when feasible
-
-## Use Cases to Support
-
-1. **Community Building**: Tools for finding others with shared interests
-2. **Project Coordination**: Easy proposal and collaboration on projects
-3. **Reputation Building**: Showcasing contributions and reliability
-4. **Governance**: Facilitating decision-making and collective governance
-
-## Resources
-
-- **Testing**: `docs/migration-testing/`
-- **Architecture**: `docs/architecture-decisions.md`
-- **Build Context**: `docs/build-modernization-context.md`
-
 ---
 
-## Status: Active application context
+**See also**:
+
+- `.cursor/rules/app/timesafari_platforms.mdc` for platform-specific details
+
+- `.cursor/rules/app/timesafari_development.mdc` for
+
+  development workflow details
+
+**Status**: Active application context
+**Priority**: Critical
+**Estimated Effort**: Ongoing reference
+**Dependencies**: None
+**Stakeholders**: Development team, Product team
 
-- **Priority**: Critical
-- **Estimated Effort**: Ongoing reference
 - **Dependencies**: Vue 3, TypeScript, SQLite, Capacitor, Electron
+
 - **Stakeholders**: Development team, Product team
+
+## Model Implementation Checklist
+
+### Before TimeSafari Development
+
+- [ ] **Application Context**: Understand TimeSafari's community-building purpose
+- [ ] **Platform Analysis**: Identify target platforms (web, mobile, desktop)
+- [ ] **Architecture Review**: Review current platform service patterns
+- [ ] **Testing Strategy**: Plan testing approach for all platforms
+
+### During TimeSafari Development
+
+- [ ] **Platform Services**: Use abstracted platform services via interfaces
+- [ ] **Type Safety**: Implement strict TypeScript with type guards
+- **Modern Architecture**: Follow current platform service patterns
+- [ ] **Performance Focus**: Ensure performance on all target devices
+
+### After TimeSafari Development
+
+- [ ] **Cross-Platform Testing**: Test functionality across all platforms
+- [ ] **Performance Validation**: Verify performance meets requirements
+- [ ] **Code Quality**: Ensure high standards maintained
+- [ ] **Documentation Update**: Update relevant documentation

.cursor/rules/app/timesafari_development.mdc

@@ -0,0 +1,174 @@
+# Time Safari Development — Workflow and Processes
+
+> **Agent role**: Reference this file for development workflow details when
+  working with TimeSafari development processes.
+
+## Development Workflow
+
+### Build Commands
+
+```bash
+
+# Web (development)
+
+npm run build:web
+
+# Mobile
+
+npm run build:capacitor
+npm run build:native
+
+# Desktop
+
+npm run build:electron
+npm run build:electron:appimage
+npm run build:electron:deb
+npm run build:electron:dmg
+
+```
+
+### Testing Commands
+
+```bash
+
+# Web E2E
+
+npm run test:web
+
+# Mobile
+
+npm run test:mobile
+npm run test:android
+npm run test:ios
+
+# Type checking
+
+npm run type-check
+npm run lint-fix
+
+```
+
+## Development Principles
+
+### Code Organization
+
+- **Platform Services**: Abstract platform-specific code behind interfaces
+
+- **Service Factory**: Use `PlatformServiceFactory` for platform selection
+
+- **Type Safety**: Strict TypeScript, no `any` types, use type guards
+
+- **Modern Architecture**: Use current platform service patterns
+
+### Architecture Patterns
+
+- **Dependency Injection**: Services injected via mixins and factory pattern
+
+- **Interface Segregation**: Small, focused interfaces over large ones
+
+- **Composition over Inheritance**: Prefer mixins and composition
+
+- **Single Responsibility**: Each component/service has one clear purpose
+
+### Testing Strategy
+
+- **E2E**: Playwright for critical user journeys
+
+- **Unit**: Jest with F.I.R.S.T. principles
+
+- **Platform Coverage**: Web + Capacitor (Pixel 5) in CI
+
+- **Quality Assurance**: Comprehensive testing and validation
+
+## Current Development Focus
+
+### Active Development
+
+- **Feature Development**: Build new functionality using modern platform
+
+  services
+
+- **Performance Optimization**: Improve app performance and user experience
+
+- **Platform Enhancement**: Leverage platform-specific capabilities
+
+- **Code Quality**: Maintain high standards and best practices
+
+### Development Metrics
+
+- **Code Quality**: High standards maintained across all platforms
+
+- **Performance**: Optimized for all target devices
+
+- **Testing**: Comprehensive coverage maintained
+
+- **User Experience**: Focus on intuitive, accessible interfaces
+
+## Development Environment
+
+### Required Tools
+
+- **Node.js**: LTS version with npm
+
+- **Git**: Version control with proper branching strategy
+
+- **IDE**: VS Code with recommended extensions
+
+- **Platform Tools**: Android Studio, Xcode (for mobile development)
+
+### Environment Setup
+
+1. **Clone Repository**: `git clone <repository-url>`
+
+2. **Install Dependencies**: `npm install`
+
+3. **Environment Variables**: Copy `.env.example` to `.env.local`
+
+4. **Platform Setup**: Follow platform-specific setup guides
+
+### Quality Assurance
+
+- **Linting**: ESLint with TypeScript rules
+
+- **Formatting**: Prettier for consistent code style
+
+- **Type Checking**: TypeScript strict mode enabled
+
+- **Testing**: Comprehensive test coverage requirements
+
+---
+
+**See also**:
+
+- `.cursor/rules/app/timesafari.mdc` for core application context
+
+- `.cursor/rules/app/timesafari_platforms.mdc` for platform-specific details
+
+**Status**: Active development workflow
+**Priority**: High
+**Estimated Effort**: Ongoing reference
+**Dependencies**: timesafari.mdc, timesafari_platforms.mdc
+**Stakeholders**: Development team, DevOps team
+
+## Model Implementation Checklist
+
+### Before TimeSafari Development
+
+- [ ] **Environment Setup**: Verify development environment is ready
+- [ ] **Platform Tools**: Ensure platform-specific tools are available
+- [ ] **Dependencies**: Check all required dependencies are installed
+- [ ] **Environment Variables**: Configure local environment variables
+
+### During TimeSafari Development
+
+- [ ] **Platform Services**: Use modern platform service patterns
+- [ ] **Code Quality**: Follow ESLint and TypeScript strict rules
+- [ ] **Testing**: Implement comprehensive testing strategy
+- [ ] **Performance**: Optimize for all target platforms
+
+### After TimeSafari Development
+
+- [ ] **Quality Checks**: Run linting, formatting, and type checking
+- [ ] **Testing**: Execute comprehensive tests across platforms
+- [ ] **Performance Validation**: Verify performance meets requirements
+- [ ] **Documentation**: Update development documentation

.cursor/rules/app/timesafari_platforms.mdc

@@ -0,0 +1,167 @@
+# Time Safari Platforms — Platform-Specific Considerations
+
+> **Agent role**: Reference this file for platform-specific details when working
+  with TimeSafari development across different platforms.
+
+## Platform-Specific Considerations
+
+### Web (PWA)
+
+- **QR Scanning**: WebInlineQRScanner
+
+- **Deep Linking**: URL parameters
+
+- **File System**: Limited browser APIs
+
+- **Build**: `npm run build:web` (development build)
+
+### Mobile (Capacitor)
+
+- **QR Scanning**: @capacitor-mlkit/barcode-scanning
+
+- **Deep Linking**: App URL open events
+
+- **File System**: Capacitor Filesystem
+
+- **Build**: `npm run build:capacitor`
+
+### Desktop (Electron)
+
+- **File System**: Node.js fs
+
+- **Build**: `npm run build:electron`
+
+- **Distribution**: AppImage, DEB, DMG packages
+
+## Platform Compatibility Requirements
+
+### Cross-Platform Features
+
+- **Core functionality** must work identically across all platforms
+
+- **Platform-specific enhancements** should be additive, not required
+
+- **Fallback behavior** must be graceful when platform features unavailable
+
+### Platform-Specific Capabilities
+
+- **Web**: Browser APIs, PWA features, responsive design
+
+- **Mobile**: Native device features, offline capability, app store compliance
+
+- **Desktop**: File system access, system integration, native performance
+
+## Build and Distribution
+
+### Build Commands
+
+```bash
+
+# Web (development)
+
+npm run build:web
+
+# Mobile
+
+npm run build:capacitor
+npm run build:native
+
+# Desktop
+
+npm run build:electron
+npm run build:electron:appimage
+npm run build:electron:deb
+npm run build:electron:dmg
+
+```
+
+### Testing Commands
+
+```bash
+
+# Web E2E
+
+npm run test:web
+
+# Mobile
+
+npm run test:mobile
+npm run test:android
+npm run test:ios
+
+# Type checking
+
+npm run type-check
+npm run lint-fix
+
+```
+
+## Key Constraints
+
+1. **Privacy First**: User identifiers remain private except when explicitly
+
+   shared
+
+2. **Platform Compatibility**: Features must work across all target platforms
+
+3. **Performance**: Must remain performant on older/simpler devices
+
+4. **Modern Architecture**: New features should use current platform services
+
+5. **Offline Capability**: Key functionality should work offline when feasible
+
+## Use Cases to Support
+
+1. **Community Building**: Tools for finding others with shared interests
+
+2. **Project Coordination**: Easy proposal and collaboration on projects
+
+3. **Reputation Building**: Showcasing contributions and reliability
+
+4. **Governance**: Facilitating decision-making and collective governance
+
+## Resources
+
+- **Testing**: `doc/migration-testing/`
+
+- **Architecture**: `doc/architecture-decisions.md`
+
+- **Build Context**: `doc/build-modernization-context.md`
+
+---
+
+**See also**:
+
+- `.cursor/rules/app/timesafari.mdc` for core application context
+- `.cursor/rules/app/timesafari_development.mdc` for
+
+  development workflow details
+
+**Status**: Active platform guidelines
+**Priority**: High
+**Estimated Effort**: Ongoing reference
+**Dependencies**: timesafari.mdc
+**Stakeholders**: Development team, Platform teams
+
+## Model Implementation Checklist
+
+### Before Platform Development
+
+- [ ] **Platform Analysis**: Identify all target platforms (web, mobile, desktop)
+- [ ] **Feature Requirements**: Understand feature requirements across platforms
+- [ ] **Platform Constraints**: Review platform-specific limitations and capabilities
+- [ ] **Testing Strategy**: Plan testing approach for all target platforms
+
+### During Platform Development
+
+- [ ] **Cross-Platform Implementation**: Implement features across all platforms
+- [ ] **Platform Services**: Use current platform services for new features
+- [ ] **Performance Optimization**: Ensure performance on older/simpler devices
+- [ ] **Offline Capability**: Implement offline functionality where feasible
+
+### After Platform Development
+
+- [ ] **Cross-Platform Testing**: Test functionality across all target platforms
+- [ ] **Performance Validation**: Verify performance meets requirements
+- [ ] **Documentation Update**: Update platform-specific documentation
+- [ ] **Team Communication**: Share platform implementation results with team

.cursor/rules/architecture/build_architecture_guard.mdc

@@ -1,13 +1,8 @@
----
-description: Guards against unauthorized changes to the TimeSafari building
-  architecture
-alwaysApply: false
----
 
 # Build Architecture Guard Directive
 
 **Author**: Matthew Raymer
-**Date**: 2025-08-20
+**Date**: 2025-08-22
 **Status**: 🎯 **ACTIVE** - Build system protection guidelines
 
 ## Purpose
@@ -17,24 +12,57 @@ could break the multi-platform build pipeline, deployment processes, or
 development workflow. This directive ensures all build system modifications
 follow proper review, testing, and documentation procedures.
 
+**Note**: Recent Android build system enhancements (2025-08-22) include
+  sophisticated asset validation, platform-specific API routing, and automatic
+  resource regeneration. These features require enhanced testing and validation
+  procedures.
+
 ## Protected Architecture Components
 
 ### Core Build Infrastructure
 
 - **Vite Configuration Files**: `vite.config.*.mts` files
+
 - **Build Scripts**: All scripts in `scripts/` directory
+
 - **Package Scripts**: `package.json` build-related scripts
+
 - **Platform Configs**: `capacitor.config.ts`, `electron/`, `android/`,
+
   `ios/`
+
 - **Docker Configuration**: `Dockerfile`, `docker-compose.yml`
+
 - **Environment Files**: `.env.*`, `.nvmrc`, `.node-version`
 
+### Android-Specific Build Validation
+
+- **Asset Validation Scripts**:
+
+  `validate_android_assets()` function and resource checking
+
+- **Resource Generation**: `capacitor-assets` integration and verification
+
+- **Platform-Specific IP Handling**:
+
+  Android emulator vs physical device API routing
+
+- **Build Mode Validation**: Development/test/production mode handling
+
+- **Resource Fallback Logic**:
+
+  Automatic regeneration of missing Android resources
+
 ### Critical Build Dependencies
 
 - **Build Tools**: Vite, Capacitor, Electron, Android SDK, Xcode
+
 - **Asset Management**: `capacitor-assets.config.json`, asset scripts
+
 - **Testing Infrastructure**: Playwright, Jest, mobile test scripts
+
 - **CI/CD Pipeline**: GitHub Actions, build validation scripts
+
 - **Service Worker Assembly**: `sw_scripts/`, `sw_combine.js`, WASM copy steps
 
 ## Change Authorization Requirements
@@ -42,8 +70,11 @@ follow proper review, testing, and documentation procedures.
 ### Level 1: Minor Changes (Requires Review)
 
 - Documentation updates to `BUILDING.md`
+
 - Non-breaking script improvements
+
 - Test additions or improvements
+
 - Asset configuration updates
 
 **Process**: Code review + basic testing
@@ -51,17 +82,33 @@ follow proper review, testing, and documentation procedures.
 ### Level 2: Moderate Changes (Requires Testing)
 
 - New build script additions
+
 - Environment variable changes
+
 - Dependency version updates
+
 - Platform-specific optimizations
 
+- **Build script argument parsing**:
+
+  New flag handling (--api-ip, --auto-run, --deploy)
+
+- **Platform-specific environment overrides**:
+
+  Android API server IP customization
+
+- **Asset regeneration logic**: Automatic fallback for missing Android resources
+
 **Process**: Code review + platform testing + documentation update
 
 ### Level 3: Major Changes (Requires ADR)
 
 - Build system architecture changes
+
 - New platform support
+
 - Breaking changes to build scripts
+
 - Major dependency migrations
 
 **Process**: ADR creation + comprehensive testing + team review
@@ -71,225 +118,69 @@ follow proper review, testing, and documentation procedures.
 ### ❌ Never Allow Without ADR
 
 - **Delete or rename** core build scripts
+
 - **Modify** `package.json` build script names
+
 - **Change** Vite configuration structure
+
 - **Remove** platform-specific build targets
+
 - **Alter** Docker build process
+
 - **Modify** CI/CD pipeline without testing
 
 ### ❌ Never Allow Without Testing
 
 - **Update** build dependencies
+
 - **Change** environment configurations
+
 - **Modify** asset generation scripts
+
 - **Alter** test infrastructure
+
 - **Update** platform SDK versions
 
-## Required Validation Checklist
-
-### Before Any Build System Change
-
-- [ ] **Impact Assessment**: Which platforms are affected?
-- [ ] **Testing Plan**: How will this be tested across platforms?
-- [ ] **Rollback Plan**: How can this be reverted if it breaks?
-- [ ] **Documentation**: Will `BUILDING.md` need updates?
-- [ ] **Dependencies**: Are all required tools available?
-
-### After Build System Change
-
-- [ ] **Web Platform**: Does `npm run build:web:dev` work?
-- [ ] **Mobile Platforms**: Do iOS/Android builds succeed?
-- [ ] **Desktop Platform**: Does Electron build and run?
-- [ ] **Tests Pass**: Do all build-related tests pass?
-- [ ] **Documentation Updated**: Is `BUILDING.md` current?
-
-## Specific Test Commands (Minimum Required)
-
-### Web Platform
-
-- **Development**: `npm run build:web:dev` - serve and load app
-- **Production**: `npm run build:web:prod` - verify SW and WASM present
-
-### Mobile Platforms
-
-- **Android**: `npm run build:android:test` or `:prod` - confirm assets copied
-- **iOS**: `npm run build:ios:test` or `:prod` - verify build succeeds
-
-### Desktop Platform
-
-- **Electron**: `npm run build:electron:dev` and packaging for target OS
-- **Verify**: Single-instance behavior and app boot
-
-### Auto-run (if affected)
-
-- **Test Mode**: `npm run auto-run:test` and platform variants
-- **Production Mode**: `npm run auto-run:prod` and platform variants
-
-### Clean and Rebuild
-
-- Run relevant `clean:*` scripts and ensure re-build works
-
-## Emergency Procedures
-
-### Build System Broken
-
-1. **Immediate**: Revert to last known working commit
-2. **Investigation**: Create issue with full error details
-3. **Testing**: Verify all platforms work after revert
-4. **Documentation**: Update `BUILDING.md` with failure notes
-
-### Platform-Specific Failure
-
-1. **Isolate**: Identify which platform is affected
-2. **Test Others**: Verify other platforms still work
-3. **Rollback**: Revert platform-specific changes
-4. **Investigation**: Debug in isolated environment
-
-## Integration Points
-
-### With Version Control
-
-- **Branch Protection**: Require reviews for build script changes
-- **Commit Messages**: Must reference ADR for major changes
-- **Testing**: All build changes must pass CI/CD pipeline
-
-### With Documentation
-
-- **BUILDING.md**: Must be updated for any script changes
-- **README.md**: Must reflect new build requirements
-- **CHANGELOG.md**: Must document breaking build changes
-
-### With Testing
-
-- **Pre-commit**: Run basic build validation
-- **CI/CD**: Full platform build testing
-- **Manual Testing**: Human verification of critical paths
-
-## Risk Matrix & Required Validation
-
-### Environment Handling
-
-- **Trigger**: Change to `.env.*` loading / variable names
-- **Validation**: Prove `dev/test/prod` builds; show environment echo in logs
-
-### Script Flow
-
-- **Trigger**: Reorder steps (prebuild → build → package), new flags
-- **Validation**: Dry-run + normal run, show exit codes & timing
-
-### Platform Packaging
-
-- **Trigger**: Electron NSIS/DMG/AppImage, Android/iOS bundle
-- **Validation**: Produce installer/artifact and open it; verify single-instance,
-  icons, signing
-
-### Service Worker / WASM
-
-- **Trigger**: `sw_combine.js`, WASM copy path
-- **Validation**: Verify combined SW exists and is injected; page loads offline;
-  WASM present
-
-### Docker
-
-- **Trigger**: New base image, build args
-- **Validation**: Build image locally; run container; list produced `/dist`
-
-### Signing/Notarization
-
-- **Trigger**: Cert path/profiles
-- **Validation**: Show signing logs + verify on target OS
-
-## PR Template (Paste into Description)
-
-- [ ] **Level**: L1 / L2 / L3 + justification
-- [ ] **Files & platforms touched**:
-- [ ] **Risk triggers & mitigations**:
-- [ ] **Commands run (paste logs)**:
-- [ ] **Artifacts (names + sha256)**:
-- [ ] **Docs updated (sections/links)**:
-- [ ] **Rollback steps verified**:
-- [ ] **CI**: Jobs passing and artifacts uploaded
-
-## Rollback Playbook
-
-### Immediate Rollback
-
-1. `git revert` or `git reset --hard <prev>`; restore prior `scripts/` or config
-   files
-2. Rebuild affected targets; verify old behavior returns
-3. Post-mortem notes → update this guard and `BUILDING.md` if gaps found
-
-### Rollback Verification
-
-- **Web**: `npm run build:web:dev` and `npm run build:web:prod`
-- **Mobile**: `npm run build:android:test` and `npm run build:ios:test`
-- **Desktop**: `npm run build:electron:dev` and packaging commands
-- **Clean**: Run relevant `clean:*` scripts and verify re-build works
-
-## ADR Trigger List
-
-Raise an ADR when you propose any of:
-
-- **New build stage** or reorder of canonical stages
-- **Replacement of packager** / packaging format
-- **New environment model** or secure secret handling scheme
-- **New service worker assembly** strategy or cache policy
-- **New Docker base** or multi-stage pipeline
-- **Relocation of build outputs** or directory conventions
-
-**ADR must include**: motivation, alternatives, risks, validation plan, rollback,
-  doc diffs.
-
-## Competence Hooks
-
-### Why This Works
-
-- **Prevents Build Failures**: Catches issues before they reach production
-- **Maintains Consistency**: Ensures all platforms build identically
-- **Reduces Debugging Time**: Prevents build system regressions
-
-### Common Pitfalls
-
-- **Silent Failures**: Changes that work on one platform but break others
-- **Dependency Conflicts**: Updates that create version incompatibilities
-- **Documentation Drift**: Build scripts that don't match documentation
-
-### Next Skill Unlock
-
-- Learn to test build changes across all platforms simultaneously
-
-### Teach-back
-
-- "What three platforms must I test before committing a build script change?"
-
-## Collaboration Hooks
-
-### Team Review Requirements
-
-- **Platform Owners**: iOS, Android, Electron, Web specialists
-- **DevOps**: CI/CD pipeline maintainers
-- **QA**: Testing infrastructure owners
-
-### Discussion Prompts
-
-- "Which platforms will be affected by this build change?"
-- "How can we test this change without breaking existing builds?"
-- "What's our rollback plan if this change fails?"
-
-## Self-Check (Before Allowing Changes)
-
-- [ ] **Authorization Level**: Is this change appropriate for the level?
-- [ ] **Testing Plan**: Is there a comprehensive testing strategy?
-- [ ] **Documentation**: Will BUILDING.md be updated?
-- [ ] **Rollback**: Is there a safe rollback mechanism?
-- [ ] **Team Review**: Have appropriate stakeholders been consulted?
-- [ ] **CI/CD**: Will this pass the build pipeline?
-
 ---
 
-**Status**: Active build system protection
+**See also**:
+
+- `.cursor/rules/architecture/build_validation.mdc` for
+
+  detailed validation procedures
+
+- `.cursor/rules/architecture/build_testing.mdc` for testing requirements
+
+**Status**: Active build protection guidelines
 **Priority**: Critical
+**Estimated Effort**: Ongoing reference
+**Dependencies**: None
+**Stakeholders**: Development team, DevOps team, Build team
+
 **Estimated Effort**: Ongoing vigilance
 **Dependencies**: All build system components
 **Stakeholders**: Development team, DevOps, Platform owners
-**Next Review**: 2025-09-20
+**Next Review**: 2025-09-22
+
+## Model Implementation Checklist
+
+### Before Build Changes
+
+- [ ] **Change Level**: Determine if change is L1, L2, or L3
+- [ ] **Impact Assessment**: Assess impact on build system architecture
+- [ ] **ADR Requirement**: Check if ADR is required for major changes
+- [ ] **Testing Planning**: Plan appropriate testing for change level
+
+### During Build Changes
+
+- [ ] **Guard Compliance**: Ensure changes comply with build architecture guard
+- [ ] **Documentation**: Document changes according to level requirements
+- [ ] **Testing**: Execute appropriate testing for change level
+- [ ] **Review Process**: Follow required review process for change level
+
+### After Build Changes
+
+- [ ] **Validation**: Verify build system still functions correctly
+- [ ] **Documentation Update**: Update relevant documentation
+- [ ] **Team Communication**: Communicate changes to affected teams
+- [ ] **Monitoring**: Monitor for any build system issues

.cursor/rules/architecture/build_testing.mdc

@@ -0,0 +1,248 @@
+# Build Testing — Requirements and Emergency Procedures
+
+> **Agent role**: Reference this file for testing requirements and
+  emergency procedures when working with build architecture changes.
+
+## Emergency Procedures
+
+### Build System Broken
+
+1. **Immediate**: Revert to last known working commit
+
+2. **Investigation**: Create issue with full error details
+
+3. **Testing**: Verify all platforms work after revert
+
+4. **Documentation**: Update `BUILDING.md` with failure notes
+
+### Platform-Specific Failure
+
+1. **Isolate**: Identify which platform is affected
+
+2. **Test Others**: Verify other platforms still work
+
+3. **Rollback**: Revert platform-specific changes
+
+4. **Investigation**: Debug in isolated environment
+
+## Rollback Playbook
+
+### Immediate Rollback
+
+1. `git revert` or `git reset --hard <prev>`; restore prior `scripts/` or config
+
+   files
+
+2. Rebuild affected targets; verify old behavior returns
+
+3. Post-mortem notes → update this guard and `BUILDING.md` if gaps found
+
+### Rollback Verification
+
+- **Web**: `npm run build:web:dev` and `npm run build:web:prod`
+
+- **Mobile**: `npm run build:android:test` and `npm run build:ios:test`
+
+- **Desktop**: `npm run build:electron:dev` and packaging commands
+
+- **Clean**: Run relevant `clean:*` scripts and verify re-build works
+
+### Android-Specific Rollback Verification
+
+- **Asset Generation**: `npm run build:android --assets` -
+
+  verify resources regenerate
+
+- **API Routing**: Test both `--dev` and `--dev --api-ip <custom>` modes
+
+- **Resource Validation**:
+
+  Check `android/app/src/main/res/` for all required assets
+
+- **Build Modes**: Verify development, test, and production modes all work
+
+- **Resource Fallback**:
+
+  Confirm missing resources trigger automatic regeneration
+
+## Integration Points
+
+### With Version Control
+
+- **Branch Protection**: Require reviews for build script changes
+
+- **Commit Messages**: Must reference ADR for major changes
+
+- **Testing**: All build changes must pass CI/CD pipeline
+
+### With Documentation
+
+- **BUILDING.md**: Must be updated for any script changes
+
+- **README.md**: Must reflect new build requirements
+
+- **CHANGELOG.md**: Must document breaking build changes
+
+### With Testing
+
+- **Pre-commit**: Run basic build validation
+
+- **CI/CD**: Full platform build testing
+
+- **Manual Testing**: Human verification of critical paths
+
+## Competence Hooks
+
+### Why This Works
+
+- **Prevents Build Failures**: Catches issues before they reach production
+
+- **Maintains Consistency**: Ensures all platforms build identically
+
+- **Reduces Debugging Time**: Prevents build system regressions
+
+### Common Pitfalls
+
+- **Silent Failures**: Changes that work on one platform but break others
+
+- **Dependency Conflicts**: Updates that create version incompatibilities
+
+- **Documentation Drift**: Build scripts that don't match documentation
+
+### Next Skill Unlock
+
+- Learn to test build changes across all platforms simultaneously
+
+### Teach-back
+
+- "What three platforms must I test before committing a build script change?"
+
+## Collaboration Hooks
+
+### Team Review Requirements
+
+- **Platform Owners**: iOS, Android, Electron, Web specialists
+
+- **DevOps**: CI/CD pipeline maintainers
+
+- **QA**: Testing infrastructure owners
+
+### Discussion Prompts
+
+- "Which platforms will be affected by this build change?"
+
+- "How can we test this change without breaking existing builds?"
+
+- "What's our rollback plan if this change fails?"
+
+## Self-Check (Before Allowing Changes)
+
+- [ ] **Authorization Level**: Is this change appropriate for the level?
+
+- [ ] **Testing Plan**: Is there a comprehensive testing strategy?
+
+- [ ] **Documentation**: Will BUILDING.md be updated?
+
+- [ ] **Rollback**: Is there a safe rollback mechanism?
+
+- [ ] **Team Review**: Have appropriate stakeholders been consulted?
+
+- [ ] **CI/CD**: Will this pass the build pipeline?
+
+## Continuous Improvement & Feedback
+
+### Feedback Collection
+
+The Build Architecture Guard system includes feedback mechanisms to continuously
+  improve its effectiveness:
+
+- **User Feedback**: Script includes feedback prompts for guard improvements
+
+- **Pattern Analysis**:
+
+  Monitor which file patterns trigger false positives/negatives
+
+- **Documentation Gaps**: Track which changes lack proper documentation
+
+- **Testing Effectiveness**: Measure how often guard catches actual issues
+
+### Feedback Integration Process
+
+1. **Collect Feedback**: Monitor guard execution logs and user reports
+
+2. **Analyze Patterns**: Identify common false positives or missed patterns
+
+3. **Update Rules**: Modify `build_architecture_guard.mdc` based on feedback
+
+4. **Enhance Script**: Update `build-arch-guard.sh` with new validations
+
+5. **Test Changes**: Verify guard improvements don't introduce new issues
+
+6. **Document Updates**: Update guard documentation with new patterns
+
+### Feedback Categories
+
+- **False Positives**: Files flagged as sensitive that shouldn't be
+
+- **False Negatives**: Sensitive files that weren't caught
+
+- **Missing Patterns**: New file types that should be protected
+
+- **Overly Strict**: Patterns that are too restrictive
+
+- **Documentation Gaps**: Missing guidance for specific change types
+
+- **Testing Improvements**: Better validation procedures
+
+### Feedback Reporting
+
+When reporting guard issues, include:
+
+- **File patterns** that triggered false positives/negatives
+
+- **Build system changes** that weren't properly caught
+
+- **Documentation gaps** in current guard rules
+
+- **Testing procedures** that could be improved
+
+- **User experience** issues with guard enforcement
+
+---
+
+**See also**:
+
+- `.cursor/rules/architecture/build_architecture_guard.mdc` for
+
+  core protection guidelines
+
+- `.cursor/rules/architecture/build_validation.mdc` for validation procedures
+
+**Status**: Active testing requirements
+**Priority**: High
+**Estimated Effort**: Ongoing reference
+**Dependencies**: build_architecture_guard.mdc, build_validation.mdc
+**Stakeholders**: Development team, DevOps team, Build team
+
+## Model Implementation Checklist
+
+### Before Build Testing
+
+- [ ] **Test Planning**: Plan comprehensive testing strategy for build changes
+- [ ] **Platform Coverage**: Identify all platforms that need testing
+- [ ] **Risk Assessment**: Assess testing risks and mitigation strategies
+- [ ] **Resource Planning**: Plan testing resources and time requirements
+
+### During Build Testing
+
+- [ ] **Test Execution**: Execute planned tests across all platforms
+- [ ] **Issue Tracking**: Track and document any issues found
+- [ ] **Feedback Collection**: Collect feedback on testing effectiveness
+- [ ] **Documentation**: Document testing procedures and results
+
+### After Build Testing
+
+- [ ] **Result Analysis**: Analyze testing results and identify patterns
+- [ ] **Feedback Integration**: Integrate feedback into testing procedures
+- [ ] **Process Improvement**: Update testing procedures based on feedback
+- [ ] **Team Communication**: Share testing results and improvements with team

.cursor/rules/architecture/build_validation.mdc

@@ -0,0 +1,224 @@
+# Build Validation — Procedures and Requirements
+
+> **Agent role**: Reference this file for
+  detailed validation procedures when working with build architecture changes.
+
+## Required Validation Checklist
+
+### Before Any Build System Change
+
+- [ ] **Impact Assessment**: Which platforms are affected?
+
+- [ ] **Testing Plan**: How will this be tested across platforms?
+
+- [ ] **Rollback Plan**: How can this be reverted if it breaks?
+
+- [ ] **Documentation**: Will `BUILDING.md` need updates?
+
+- [ ] **Dependencies**: Are all required tools available?
+
+### After Build System Change
+
+- [ ] **Web Platform**: Does `npm run build:web:dev` work?
+
+- [ ] **Mobile Platforms**: Do iOS/Android builds succeed?
+
+- [ ] **Desktop Platform**: Does Electron build and run?
+
+- [ ] **Tests Pass**: Do all build-related tests pass?
+
+- [ ] **Documentation Updated**: Is `BUILDING.md` current?
+
+## Specific Test Commands (Minimum Required)
+
+### Web Platform
+
+- **Development**: `npm run build:web:dev` - serve and load app
+
+- **Production**: `npm run build:web:prod` - verify SW and WASM present
+
+### Mobile Platforms
+
+- **Android**: `npm run build:android:test` or `:prod` - confirm assets copied
+
+- **iOS**: `npm run build:ios:test` or `:prod` - verify build succeeds
+
+### Android Platform (Enhanced)
+
+- **Development Mode**: `npm run build:android --dev` -
+
+  verify 10.0.2.2 API routing
+
+- **Custom IP Mode**: `npm run build:android --dev --api-ip 192.168.1.100` -
+
+  verify custom IP
+
+- **Asset Validation**: `npm run build:android --assets` -
+
+  verify resource generation
+
+- **Deploy Mode**: `npm run build:android --deploy` - verify device deployment
+
+### Desktop Platform
+
+- **Electron**: `npm run build:electron:dev` and packaging for target OS
+
+- **Verify**: Single-instance behavior and app boot
+
+### Auto-run (if affected)
+
+- **Test Mode**: `npm run auto-run:test` and platform variants
+
+- **Production Mode**: `npm run auto-run:prod` and platform variants
+
+### Clean and Rebuild
+
+- Run relevant `clean:*` scripts and ensure re-build works
+
+## Risk Matrix & Required Validation
+
+### Environment Handling
+
+- **Trigger**: Change to `.env.*` loading / variable names
+
+- **Validation**: Prove `dev/test/prod` builds; show environment echo in logs
+
+### Script Flow
+
+- **Trigger**: Reorder steps (prebuild → build → package), new flags
+
+- **Validation**: Dry-run + normal run, show exit codes & timing
+
+### Platform Packaging
+
+- **Trigger**: Electron NSIS/DMG/AppImage, Android/iOS bundle
+
+- **Validation**: Produce installer/artifact and open it;
+
+  verify single-instance,
+  icons, signing
+
+### Service Worker / WASM
+
+- **Trigger**: `sw_combine.js`, WASM copy path
+
+- **Validation**: Verify combined SW exists and is injected; page loads offline;
+
+  WASM present
+
+### Docker
+
+- **Trigger**: New base image, build args
+
+- **Validation**: Build image locally; run container; list produced `/dist`
+
+### Android Asset Management
+
+- **Trigger**: Changes to `validate_android_assets()` function or resource paths
+
+- **Validation**:
+
+  Run `npm run build:android --assets` and verify all mipmap/drawable resources
+
+- **Risk**: Missing splash screens or app icons causing build failures
+
+### Android API Routing
+
+- **Trigger**: Changes to Android-specific API server IP logic
+
+- **Validation**: Test both emulator (10.0.2.2) and custom IP modes
+
+- **Risk**: API connectivity failures on different device types
+
+### Signing/Notarization
+
+- **Trigger**: Cert path/profiles
+
+- **Validation**: Show signing logs + verify on target OS
+
+## PR Template (Paste into Description)
+
+- [ ] **Level**: L1 / L2 / L3 + justification
+
+- [ ] **Files & platforms touched**:
+
+- [ ] **Risk triggers & mitigations**:
+
+- [ ] **Commands run (paste logs)**:
+
+- [ ] **Artifacts (names + sha256)**:
+
+- [ ] **Docs updated (sections/links)**:
+
+- [ ] **Rollback steps verified**:
+
+- [ ] **CI**: Jobs passing and artifacts uploaded
+
+## ADR Trigger List
+
+Raise an ADR when you propose any of:
+
+- **New build stage** or reorder of canonical stages
+
+- **Replacement of packager** / packaging format
+
+- **New environment model** or secure secret handling scheme
+
+- **New service worker assembly** strategy or cache policy
+
+- **New Docker base** or multi-stage pipeline
+
+- **Relocation of build outputs** or directory conventions
+
+- **New Android build modes** or argument parsing logic
+
+- **Changes to asset validation** or resource generation strategy
+
+- **Modifications to platform-specific API routing** (
+
+  Android emulator vs physical)
+
+- **New Android deployment strategies** or device management
+
+**ADR must include**:
+  motivation, alternatives, risks, validation plan, rollback,
+  doc diffs.
+
+---
+
+**See also**:
+
+- `.cursor/rules/architecture/build_architecture_guard.mdc` for
+
+  core protection guidelines
+
+- `.cursor/rules/architecture/build_testing.mdc` for testing requirements
+
+**Status**: Active validation procedures
+**Priority**: High
+**Estimated Effort**: Ongoing reference
+**Dependencies**: build_architecture_guard.mdc
+**Stakeholders**: Development team, DevOps team, Build team
+
+## Model Implementation Checklist
+
+### Before Build Changes
+
+- [ ] **Level Assessment**: Determine build validation level (L1/L2/L3)
+- [ ] **Platform Analysis**: Identify all platforms affected by changes
+- [ ] **Risk Assessment**: Identify risk triggers and mitigation strategies
+- [ ] **Rollback Planning**: Plan rollback steps for build failures
+
+### During Build Implementation
+
+- [ ] **Validation Commands**: Run appropriate validation commands for level
+- [ ] **Platform Testing**: Test changes across all affected platforms
+- [ ] **Risk Mitigation**: Implement identified risk mitigation strategies
+- [ ] **Documentation**: Document all commands run and their outputs
+
+### After Build Implementation
+
+- [ ] **Artifact Validation**: Verify build artifacts are correct and accessible
+- [ ] **CI Verification**: Ensure CI jobs pass and artifacts are uploaded
+- [ ] **Documentation Update**: Update relevant documentation sections
+- [ ] **Team Communication**: Share build validation results with team

.cursor/rules/core/base_context.mdc

@@ -1,7 +1,8 @@
 ---
-alwaysApply: true
+alwaysApply: false
 ---
 ```json
+
 {
   "coaching_level": "standard",
   "socratic_max_questions": 7,
@@ -9,6 +10,7 @@ alwaysApply: true
   "timebox_minutes": null,
   "format_enforcement": "strict"
 }
+
 ```
 
 # Base Context — Human Competence First
@@ -30,13 +32,21 @@ machine-driven steps.
 ## Principles
 
 1. Competence over convenience: finish the task *and* leave the human more
+
    capable next time.
+
 2. Mentorship, not lectures: be concise, concrete, and immediately applicable.
+
 3. Transparency: show assumptions, limits, and uncertainty; cite when
+
    non-obvious.
+
 4. Optional scaffolding: include small, skimmable learning hooks that do not
+
    bloat output.
+
 5. Time respect: default to **lean output**; offer opt-in depth via toggles.
+
 6. Psychological safety: encourage, never condescend; no medical/clinical
    advice. No censorship!
 7. Reusability: structure outputs so they can be saved, searched, reused, and
@@ -72,12 +82,19 @@ essential parts of the task within that constraint.
 Behavior when set:
 
 1. **Prioritize Core Output** — Deliver the minimum viable solution or
+
    result first.
+
 2. **Limit Commentary** — Competence Hooks and Collaboration Hooks must be
+
    shorter than normal.
+
 3. **Signal Skipped Depth** — Omitted details should be listed under
+
    *Deferred for depth*.
+
 4. **Order by Value** — Start with blocking or high-value items, then
+
    proceed to nice-to-haves if budget allows.
 
 If `null`, there is no timebox — the model can produce full-depth
@@ -91,11 +108,17 @@ acceptable).
 ## Modes (select or combine)
 
 - **Doer**: produce the artifact fast, minimal commentary.
+
 - **Mentor**: add short "why/how" notes + next-step pointers.
+
 - **Socratic**: ask up to N targeted questions when requirements are
+
   ambiguous.
+
 - **Pair-Programmer/Pair-Writer**: explain tradeoffs as you implement.
+
 - **Facilitator**: structure output to be reviewable, commentable, and
+
   ready for group discussion.
 
 Default: Doer + short Mentor notes.
@@ -103,42 +126,85 @@ Default: Doer + short Mentor notes.
 ## Competence & Collaboration Levers (keep lightweight)
 
 - "Why this works" (≤3 bullets)
+
 - "Common pitfalls" (≤3 bullets)
+
 - "Next skill unlock" (1 tiny action or reading)
+
 - "Teach-back" (1 sentence prompt the human can answer to self-check)
+
 - "Discussion prompts" (≤2 short questions for peers/stakeholders)
 
 ## Output Contract (apply to every deliverable)
 
 - Clear **Objective** (1 line)
+
 - **Result** (artifact/code/answer)
+
 - **Use/Run** (how to apply/test)
+
 - **Competence Hooks** (the 4 learning levers above, kept terse)
+
 - **Collaboration Hooks** (discussion prompts or group review steps)
+
 - **Assumptions & Limits**
+
 - **References** (if used; links or titles)
 
 ## Do-Not
 
 - No filler, hedging, or moralizing.
+
 - No medical/mental-health advice; keep "healthy habits" to general work
+
   practices.
+
 - No invented facts; mark uncertainty plainly.
+
 - No censorship.
+
 - Avoid outputs that bypass human review when such review is valuable.
 
 ## Related Rulesets
 
 - **software_development.mdc**: For software-specific development practices
+
 - **research_diagnostic.mdc**: For investigation and research workflows
 
+## Model Implementation Checklist
+
+### Before Responding
+
+- [ ] **Toggle Review**: Check coaching_level, socratic_max_questions, verbosity,
+  timebox_minutes
+- [ ] **Mode Selection**: Choose appropriate mode(s) for the task
+- [ ] **Scope Understanding**: Clarify requirements and constraints
+- [ ] **Context Analysis**: Review relevant rulesets and dependencies
+
+### During Response Creation
+
+- [ ] **Output Contract**: Include all required sections (Objective, Result,
+  Use/Run, etc.)
+- [ ] **Competence Hooks**: Add at least one learning lever (≤120 words total)
+- [ ] **Collaboration Hooks**: Include discussion prompts or review steps
+- [ ] **Toggle Compliance**: Respect verbosity, timebox, and format settings
+
+### After Response Creation
+
+- [ ] **Self-Check**: Verify all checklist items are completed
+- [ ] **Format Validation**: Ensure output follows required structure
+- [ ] **Content Review**: Confirm no disallowed content included
+- [ ] **Quality Assessment**: Verify response meets human competence goals
+
 ## Self-Check (model, before responding)
 
 - [ ] Task done *and* at least one competence lever included (≤120 words
-  total).
-- [ ] At least one collaboration/discussion hook present.
-- [ ] Output follows the **Output Contract** sections.
-- [ ] Toggles respected; verbosity remains concise.
+  total)
+- [ ] At least one collaboration/discussion hook present
+- [ ] Output follows the **Output Contract** sections
+- [ ] Toggles respected; verbosity remains concise
+- [ ] Uncertainties/assumptions surfaced
+- [ ] No disallowed content
 - [ ] Uncertainties/assumptions surfaced.
 - [ ] No disallowed content.
 
@@ -149,6 +215,3 @@ Default: Doer + short Mentor notes.
 **Estimated Effort**: Ongoing reference
 **Dependencies**: None (base ruleset)
 **Stakeholders**: All AI interactions
-
-- [ ] Uncertainties/assumptions surfaced.
-- [ ] No disallowed content.

.cursor/rules/core/harbor_pilot_universal.mdc

@@ -0,0 +1,202 @@
+```json
+
+{
+  "coaching_level": "standard",
+  "socratic_max_questions": 2,
+  "verbosity": "concise",
+  "timebox_minutes": 10,
+  "format_enforcement": "strict"
+}
+
+```
+
+# Harbor Pilot Universal — Technical Guide Standards
+
+> **Agent role**: When creating technical guides, reference documents, or
+> implementation plans, apply these universal directives to ensure consistent
+> quality and structure.
+
+## Purpose
+
+- **Purpose fit**: Prioritizes human competence and collaboration while
+  delivering reproducible artifacts.
+
+- **Output Contract**: This directive **adds universal constraints** for any
+  technical topic while **inheriting** the Base Context contract sections.
+
+- **Toggles honored**: Uses the same toggle semantics; defaults above can be
+  overridden by the caller.
+
+## Core Directive
+
+Produce a **developer-grade, reproducible guide** for any technical topic
+that onboards a competent practitioner **without meta narration** and **with
+evidence-backed steps**.
+
+## Required Elements
+
+### 1. Time & Date Standards
+
+- Use **absolute dates** in **UTC** (e.g., `2025-08-21T14:22Z`) — avoid
+  "today/yesterday".
+
+- Include at least **one diagram** (Mermaid preferred). Choose the most
+  fitting type:
+
+  - `sequenceDiagram` (protocols/flows), `flowchart`, `stateDiagram`,
+    `gantt` (timelines), or `classDiagram` (schemas).
+
+### 2. Evidence Requirements
+
+- **Reproducible Steps**: Every claim must have copy-paste commands
+
+- **Verifiable Outputs**: Include expected results, status codes, or
+  error messages
+
+- **Cite evidence** for *Works/Doesn't* items (timestamps, filenames,
+  line numbers, IDs/status codes, or logs).
+
+## Required Sections
+
+Follow this exact order **after** the Base Contract's **Objective → Result
+→ Use/Run** headers:
+
+1. **Artifacts & Links** - Repos/PRs, design docs, datasets/HARs/pcaps,
+   scripts/tools, dashboards.
+
+2. **Environment & Preconditions** - OS/runtime, versions/build IDs,
+   services/endpoints/URLs, credentials/auth mode.
+
+3. **Architecture / Process Overview** - Short prose + **one diagram**
+   selected from the list above.
+
+4. **Interfaces & Contracts** - Choose one: API-based (endpoint table),
+   Data/Files (I/O contract), or Systems/Hardware (interfaces).
+
+5. **Repro: End-to-End Procedure** - Minimal copy-paste steps with
+   code/commands and **expected outputs**.
+6. **What Works (with Evidence)** - Each item: **Time (UTC)** •
+   **Artifact/Req IDs** • **Status/Result** • **Where to verify**.
+7. **What Doesn't (Evidence & Hypotheses)** - Each failure: locus,
+   evidence snippet; short hypothesis and **next probe**.
+8. **Risks, Limits, Assumptions** - SLOs/limits, rate/size caps,
+   security boundaries, retries/backoff/idempotency patterns.
+9. **Next Steps (Owner • Exit Criteria • Target Date)** - Actionable,
+   assigned, and time-bound.
+
+## Quality Standards
+
+### Do
+
+- **Do** quantify progress only against a defined scope with acceptance
+  criteria.
+
+- **Do** include minimal sample payloads/headers or I/O schemas; redact
+  sensitive values.
+
+- **Do** keep commentary lean; if timeboxed, move depth to **Deferred
+  for depth**.
+
+- **Do** use specific, actionable language that guides implementation.
+
+### Don't
+
+- **Don't** use marketing language or meta narration ("Perfect!",
+  "tool called", "new chat").
+
+- **Don't** include IDE-specific chatter or internal rules unrelated to
+  the task.
+
+- **Don't** assume reader knowledge; provide context for all technical
+  decisions.
+
+## Model Implementation Checklist
+
+### Before Creating Technical Guides
+
+- [ ] **Scope Definition**: Clearly define problem, audience, and scope
+- [ ] **Evidence Collection**: Gather specific timestamps, file references, and logs
+- [ ] **Diagram Planning**: Plan appropriate diagram type for the technical process
+- [ ] **Template Selection**: Choose relevant sections from required sections list
+
+### During Guide Creation
+
+- [ ] **Evidence Integration**: Include UTC timestamps and verifiable evidence
+- [ ] **Diagram Creation**: Create Mermaid diagram that illustrates the process
+- [ ] **Repro Steps**: Write copy-paste ready commands with expected outputs
+- [ ] **Section Completion**: Fill in all required sections completely
+
+### After Guide Creation
+
+- [ ] **Validation**: Run through the validation checklist below
+- [ ] **Evidence Review**: Verify all claims have supporting evidence
+- [ ] **Repro Testing**: Test reproduction steps to ensure they work
+- [ ] **Peer Review**: Share with technical leads for feedback
+
+## Validation Checklist
+
+Before publishing, verify:
+
+- [ ] **Diagram included** and properly formatted (Mermaid syntax valid)
+- [ ] If API-based, **Auth** and **Key Headers/Params** are listed for
+  each endpoint
+- [ ] **Environment section** includes all required dependencies and
+  versions
+- [ ] Every Works/Doesn't item has **UTC timestamp**, **status/result**,
+  and **verifiable evidence**
+- [ ] **Repro steps** are copy-paste ready with expected outputs
+- [ ] Base **Output Contract** sections satisfied
+  (Objective/Result/Use/Run/Competence/Collaboration/Assumptions/References)
+
+## Integration Points
+
+### Base Context Integration
+
+- Apply historical comment management rules (see
+
+  `.cursor/rules/development/historical_comment_management.mdc`)
+
+- Apply realistic time estimation rules (see
+
+  `.cursor/rules/development/realistic_time_estimation.mdc`)
+
+### Competence Hooks
+
+- **Why this works**: Structured approach ensures completeness and
+  reproducibility
+
+- **Common pitfalls**: Skipping evidence requirements, vague language
+
+- **Next skill unlock**: Practice creating Mermaid diagrams for different
+  use cases
+
+- **Teach-back**: Explain how you would validate this guide's
+  reproducibility
+
+### Collaboration Hooks
+
+- **Reviewers**: Technical leads, subject matter experts
+
+- **Stakeholders**: Development teams, DevOps, QA teams
+
+---
+
+**Status**: 🚢 ACTIVE — General ruleset extending *Base Context — Human
+Competence First*
+
+**Priority**: Critical
+**Estimated Effort**: Ongoing reference
+**Dependencies**: base_context.mdc
+**Stakeholders**: All AI interactions, Development teams
+
+## Example Diagram Template
+
+```mermaid
+
+<one suitable diagram: sequenceDiagram | flowchart | stateDiagram | gantt |
+classDiagram>
+
+```
+
+**Note**: Replace the placeholder with an actual diagram that illustrates
+the technical process, architecture, or workflow being documented.

.cursor/rules/core/less_complex.mdc

@@ -0,0 +1,100 @@
+
+alwaysApply: false
+
+---
+
+# Minimalist Solution Principle (Cursor MDC)
+
+role: Engineering assistant optimizing for least-complex changes
+focus: Deliver the smallest viable diff that fully resolves the current
+bug/feature. Defer generalization unless justified with evidence.
+language: Match repository languages and conventions
+
+## Rules
+
+0. **Principle:** just the facts m'am.
+1. **Default to the least complex solution.** Fix the problem directly
+   where it occurs; avoid new layers, indirection, or patterns unless
+   strictly necessary.
+2. **Keep scope tight.** Implement only what is needed to satisfy the
+   acceptance criteria and tests for *this* issue.
+3. **Avoid speculative abstractions.** Use the **Rule of Three**:
+   don't extract helpers/patterns until the third concrete usage proves
+   the shape.
+4. **No drive-by refactors.** Do not rename, reorder, or reformat
+   unrelated code in the same change set.
+5. **Minimize surface area.** Prefer local changes over cross-cutting
+   rewires; avoid new public APIs unless essential.
+6. **Be dependency-frugal.** Do not add packages or services for
+   single, simple needs unless there's a compelling, documented reason.
+7. **Targeted tests only.** Add the smallest set of tests that prove
+   the fix and guard against regression; don't rewrite suites.
+8. **Document the "why enough."** Include a one-paragraph note
+   explaining why this minimal solution is sufficient *now*.
+
+## Future-Proofing Requires Evidence + Discussion
+
+Any added complexity "for the future" **must** include:
+
+- A referenced discussion/ADR (or issue link) summarizing the decision.
+- **Substantial evidence**, e.g.:
+  - Recurring incidents or tickets that this prevents (list IDs).
+  - Benchmarks or profiling showing a real bottleneck.
+  - Concrete upcoming requirements with dates/owners, not hypotheticals.
+  - Risk assessment comparing maintenance cost vs. expected benefit.
+- A clear trade-off table showing why minimal won't suffice.
+
+If this evidence is not available, **ship the minimal fix** and open a
+follow-up discussion item.
+
+## PR / Change Checklist (enforced by reviewer + model)
+
+- [ ] Smallest diff that fully fixes the issue (attach `git diff --stat`
+  if useful).
+- [ ] No unrelated refactors or formatting.
+- [ ] No new dependencies, or justification + ADR link provided.
+- [ ] Abstractions only if ≥3 call sites or strong evidence says
+  otherwise (cite).
+- [ ] Targeted tests proving the fix/regression guard.
+- [ ] Short "Why this is enough now" note in the PR description.
+- [ ] Optional: "Future Work (non-blocking)" section listing deferred
+  ideas.
+
+## Assistant Output Contract
+
+When proposing a change, provide:
+
+1. **Minimal Plan**: 3–6 bullet steps scoped to the immediate fix.
+2. **Patch Sketch**: Focused diffs/snippets touching only necessary
+   files.
+3. **Risk & Rollback**: One paragraph each on risk, quick rollback,
+   and test points.
+4. **(If proposing complexity)**: Link/inline ADR summary + evidence +
+   trade-offs; otherwise default to minimal.
+
+  One paragraph each on risk, quick rollback, and test points.
+5. **(If proposing complexity)**: Link/inline ADR summary + evidence +
+   trade-offs; otherwise default to minimal.
+
+## Model Implementation Checklist
+
+### Before Proposing Changes
+
+- [ ] **Problem Analysis**: Clearly understand the specific issue scope
+- [ ] **Evidence Review**: Gather evidence that justifies the change
+- [ ] **Complexity Assessment**: Evaluate if change requires added complexity
+- [ ] **Alternative Research**: Consider simpler solutions first
+
+### During Change Design
+
+- [ ] **Minimal Scope**: Design solution that addresses only the current issue
+- [ ] **Evidence Integration**: Include specific evidence for any complexity
+- [ ] **Dependency Review**: Minimize new dependencies and packages
+- [ ] **Testing Strategy**: Plan minimal tests that prove the fix
+
+### After Change Design
+
+- [ ] **Self-Review**: Verify solution follows minimalist principles
+- [ ] **Evidence Validation**: Confirm all claims have supporting evidence
+- [ ] **Complexity Justification**: Document why minimal approach suffices
+- [ ] **Future Work Planning**: Identify deferred improvements for later

.cursor/rules/database/absurd-sql.mdc

@@ -1,8 +1,10 @@
 ---
-globs: **/db/databaseUtil.ts, **/interfaces/absurd-sql.d.ts, **/src/registerSQLWorker.js, **/
+globs: **/db/databaseUtil.ts, **/interfaces/absurd-sql.d.ts,
+  **/src/registerSQLWorker.js, **/
 services/AbsurdSqlDatabaseService.ts
 alwaysApply: false
 ---
+
 # Absurd SQL - Cursor Development Guide
 
 **Author**: Matthew Raymer
@@ -19,12 +21,14 @@ in Cursor.
 ## Project Structure
 
 ```
+
 absurd-sql/
 ├── src/               # Source code
 ├── dist/             # Built files
 ├── package.json      # Dependencies and scripts
 ├── rollup.config.js  # Build configuration
 └── jest.config.js    # Test configuration
+
 ```
 
 ## Development Rules
@@ -32,13 +36,17 @@ absurd-sql/
 ### 1. Worker Thread Requirements
 
 - All SQL operations MUST be performed in a worker thread
+
 - Main thread should only handle worker initialization and communication
+
 - Never block the main thread with database operations
 
 ### 2. Code Organization
 
 - Keep worker code in separate files (e.g., `*.worker.js`)
+
 - Use ES modules for imports/exports
+
 - Follow the project's existing module structure
 
 ### 3. Required Headers
@@ -46,14 +54,18 @@ absurd-sql/
 When developing locally or deploying, ensure these headers are set:
 
 ```
+
 Cross-Origin-Opener-Policy: same-origin
 Cross-Origin-Embedder-Policy: require-corp
+
 ```
 
 ### 4. Browser Compatibility
 
 - Primary target: Modern browsers with SharedArrayBuffer support
+
 - Fallback mode: Safari (with limitations)
+
 - Always test in both modes
 
 ### 5. Database Configuration
@@ -61,8 +73,10 @@ Cross-Origin-Embedder-Policy: require-corp
 Recommended database settings:
 
 ```sql
+
 PRAGMA journal_mode=MEMORY;
 PRAGMA page_size=8192;  -- Optional, but recommended
+
 ```
 
 ### 6. Development Workflow
@@ -70,54 +84,77 @@ PRAGMA page_size=8192;  -- Optional, but recommended
 1. Install dependencies:
 
    ```bash
+
    yarn add @jlongster/sql.js absurd-sql
+
    ```
 
 2. Development commands:
+
    - `yarn build` - Build the project
+
    - `yarn jest` - Run tests
+
    - `yarn serve` - Start development server
 
 ### 7. Testing Guidelines
 
 - Write tests for both SharedArrayBuffer and fallback modes
+
 - Use Jest for testing
+
 - Include performance benchmarks for critical operations
 
 ### 8. Performance Considerations
 
 - Use bulk operations when possible
+
 - Monitor read/write performance
+
 - Consider using transactions for multiple operations
+
 - Avoid unnecessary database connections
 
 ### 9. Error Handling
 
 - Implement proper error handling for:
+
   - Worker initialization failures
+
   - Database connection issues
+
   - Concurrent access conflicts (in fallback mode)
+
   - Storage quota exceeded scenarios
 
 ### 10. Security Best Practices
 
 - Never expose database operations directly to the client
+
 - Validate all SQL queries
+
 - Implement proper access controls
+
 - Handle sensitive data appropriately
 
 ### 11. Code Style
 
 - Follow ESLint configuration
+
 - Use async/await for asynchronous operations
+
 - Document complex database operations
+
 - Include comments for non-obvious optimizations
 
 ### 12. Debugging
 
 - Use `jest-debug` for debugging tests
+
 - Monitor IndexedDB usage in browser dev tools
+
 - Check worker communication in console
+
 - Use performance monitoring tools
 
 ## Common Patterns
@@ -125,6 +162,7 @@ PRAGMA page_size=8192;  -- Optional, but recommended
 ### Worker Initialization
 
 ```javascript
+
 // Main thread
 import { initBackend } from 'absurd-sql/dist/indexeddb-main-thread';
 
@@ -132,11 +170,13 @@ function init() {
   let worker = new Worker(new URL('./index.worker.js', import.meta.url));
   initBackend(worker);
 }
+
 ```
 
 ### Database Setup
 
 ```javascript
+
 // Worker thread
 import initSqlJs from '@jlongster/sql.js';
 import { SQLiteFS } from 'absurd-sql';
@@ -146,12 +186,13 @@ async function setupDatabase() {
   let SQL = await initSqlJs({ locateFile: file => file });
   let sqlFS = new SQLiteFS(SQL.FS, new IndexedDBBackend());
   SQL.register_for_idb(sqlFS);
-  
+
   SQL.FS.mkdir('/sql');
   SQL.FS.mount(sqlFS, {}, '/sql');
-  
+
   return new SQL.Database('/sql/db.sqlite', { filename: true });
 }
+
 ```
 
 ## Troubleshooting
@@ -159,25 +200,37 @@ async function setupDatabase() {
 ### Common Issues
 
 1. SharedArrayBuffer not available
+
    - Check COOP/COEP headers
+
    - Verify browser support
+
    - Test fallback mode
 
 2. Worker initialization failures
+
    - Check file paths
+
    - Verify module imports
+
    - Check browser console for errors
 
 3. Performance issues
+
    - Monitor IndexedDB usage
+
    - Check for unnecessary operations
+
    - Verify transaction usage
 
 ## Resources
 
 - [Project Demo](https://priceless-keller-d097e5.netlify.app/)
+
 - [Example Project](https://github.com/jlongster/absurd-example-project)
+
 - [Blog Post](https://jlongster.com/future-sql-web)
+
 - [SQL.js Documentation](https://github.com/sql-js/sql.js/)
 
 ---
@@ -186,8 +239,35 @@ async function setupDatabase() {
 **Priority**: High
 **Estimated Effort**: Ongoing reference
 **Dependencies**: Absurd SQL, SQL.js, IndexedDB
-**Stakeholders**: Development team, Database team 
+**Stakeholders**: Development team, Database team
+
 - [Project Demo](https://priceless-keller-d097e5.netlify.app/)
+
 - [Example Project](https://github.com/jlongster/absurd-example-project)
+
 - [Blog Post](https://jlongster.com/future-sql-web)
+
 - [SQL.js Documentation](https://github.com/sql-js/sql.js/)
+
+## Model Implementation Checklist
+
+### Before Absurd SQL Implementation
+
+- [ ] **Browser Support**: Verify SharedArrayBuffer and COOP/COEP support
+- [ ] **Worker Setup**: Plan worker thread initialization and communication
+- [ ] **Database Planning**: Plan database schema and initialization
+- [ ] **Performance Planning**: Plan performance monitoring and optimization
+
+### During Absurd SQL Implementation
+
+- [ ] **Worker Initialization**: Set up worker threads with proper communication
+- [ ] **Database Setup**: Initialize SQLite database with IndexedDB backend
+- [ ] **File System**: Configure SQLiteFS with proper mounting
+- [ ] **Error Handling**: Implement proper error handling for worker failures
+
+### After Absurd SQL Implementation
+
+- [ ] **Cross-Browser Testing**: Test across different browsers and devices
+- [ ] **Performance Validation**: Monitor IndexedDB usage and performance
+- [ ] **Worker Validation**: Verify worker communication and database operations
+- [ ] **Documentation**: Update Absurd SQL implementation documentation

.cursor/rules/database/legacy_dexie.mdc

@@ -1,8 +1,62 @@
----
-globs: **/databaseUtil.ts,**/AccountViewView.vue,**/ContactsView.vue,**/DatabaseMigration.vue,**/NewIdentifierView.vue
-alwaysApply: false
----
-# What to do with Dexie
+# Legacy Dexie Database — Migration Guidelines
 
-All references in the codebase to Dexie apply only to migration from IndexedDb to
-Sqlite and will be deprecated in future versions.
+> **Agent role**: Reference this file when working with legacy Dexie
+> database code or migration patterns.
+
+## Overview
+
+All references in the codebase to Dexie apply only to migration from
+IndexedDb to Absurd SQL. Dexie is no longer used for new development.
+
+## Migration Status
+
+- **Legacy Code**: Existing Dexie implementations being migrated
+- **Target**: Absurd SQL with IndexedDB backend
+- **Timeline**: Gradual migration as features are updated
+
+## Key Principles
+
+- **No New Dexie**: All new database operations use Absurd SQL
+- **Migration Path**: Legacy code should be migrated when updated
+- **Backward Compatibility**: Maintain existing functionality during
+  migration
+
+## Integration Points
+
+- Apply these rules when updating database-related code
+- Use during feature development and refactoring
+- Include in database architecture decisions
+
+---
+
+**Status**: Legacy migration guidelines
+**Priority**: Low
+**Estimated Effort**: Ongoing reference
+**Dependencies**: absurd-sql.mdc
+**Stakeholders**: Database team, Development team
+
+All references in the codebase to Dexie apply only to migration from IndexedDb
+to Sqlite and will be deprecated in future versions.
+
+## Model Implementation Checklist
+
+### Before Legacy Dexie Work
+
+- [ ] **Migration Analysis**: Identify legacy Dexie code that needs migration
+- [ ] **Target Planning**: Plan migration to Absurd SQL with IndexedDB backend
+- [ ] **Backward Compatibility**: Plan to maintain existing functionality
+- [ ] **Testing Strategy**: Plan testing approach for migration
+
+### During Legacy Dexie Migration
+
+- [ ] **No New Dexie**: Ensure no new Dexie code is introduced
+- [ ] **Migration Implementation**: Implement migration to Absurd SQL
+- [ ] **Functionality Preservation**: Maintain existing functionality during migration
+- [ ] **Error Handling**: Implement proper error handling for migration
+
+### After Legacy Dexie Migration
+
+- [ ] **Functionality Testing**: Verify all functionality still works correctly
+- [ ] **Performance Validation**: Ensure performance meets or exceeds legacy
+- [ ] **Documentation Update**: Update database documentation
+- [ ] **Legacy Cleanup**: Remove deprecated Dexie code

.cursor/rules/development/asset_configuration.mdc

@@ -2,6 +2,7 @@
 description: when doing anything with capacitor assets
 alwaysApply: false
 ---
+
 # Asset Configuration Directive
 
 **Author**: Matthew Raymer
@@ -14,28 +15,43 @@ orchestration*
 ## Intent
 
 - Version **asset configuration files** (optionally dev-time generated).
+
 - **Do not** version platform asset outputs (Android/iOS/Electron); generate
+
   them **at build-time** with standard tools.
+
 - Keep existing per-platform build scripts unchanged.
 
 ## Source of Truth
 
 - **Preferred (Capacitor default):** `resources/` as the single master source.
+
 - **Alternative:** `assets/` is acceptable **only** if `capacitor-assets` is
+
   explicitly configured to read from it.
+
 - **Never** maintain both `resources/` and `assets/` as parallel sources.
+
   Migrate and delete the redundant folder.
 
 ## Config Files
 
 - Live under: `config/assets/` (committed).
+
 - Examples:
+
   - `config/assets/capacitor-assets.config.json` (or the path the tool
+
     expects)
+
   - `config/assets/android.assets.json`
+
   - `config/assets/ios.assets.json`
+
   - `config/assets/common.assets.yaml` (optional shared layer)
+
 - **Dev-time generation allowed** for these configs; **build-time
+
   generation is forbidden**.
 
 ## Build-Time Behavior
@@ -43,10 +59,13 @@ orchestration*
 - Build generates platform assets (not configs) using the standard chain:
 
 ```bash
+
 npm run build:capacitor        # web build via Vite (.mts)
 npx cap sync
 npx capacitor-assets generate  # produces platform assets; not committed
+
 # then platform-specific build steps
+
 ```
 
 ---
@@ -58,4 +77,29 @@ npx capacitor-assets generate  # produces platform assets; not committed
 **Stakeholders**: Development team, Build team
 
   npx capacitor-assets generate  # produces platform assets; not committed
-  # then platform-specific build steps
+
+# then platform-specific build steps
+
+## Model Implementation Checklist
+
+### Before Asset Configuration
+
+- [ ] **Source Review**: Identify current asset source location (`resources/` or
+  `assets/`)
+- [ ] **Tool Assessment**: Verify capacitor-assets toolchain is available
+- [ ] **Config Planning**: Plan configuration file structure and location
+- [ ] **Platform Analysis**: Understand asset requirements for all target platforms
+
+### During Asset Configuration
+
+- [ ] **Source Consolidation**: Ensure single source of truth (prefer `resources/`)
+- [ ] **Config Creation**: Create platform-specific asset configuration files
+- [ ] **Tool Integration**: Configure capacitor-assets to read from correct source
+- [ ] **Build Integration**: Integrate asset generation into build pipeline
+
+### After Asset Configuration
+
+- [ ] **Build Testing**: Verify assets generate correctly at build time
+- [ ] **Platform Validation**: Test asset generation across all platforms
+- [ ] **Documentation**: Update build documentation with asset generation steps
+- [ ] **Team Communication**: Communicate asset workflow changes to team

.cursor/rules/development/complexity_assessment.mdc

@@ -0,0 +1,177 @@
+# Complexity Assessment — Evaluation Frameworks
+
+> **Agent role**: Reference this file for
+  complexity evaluation frameworks when assessing project complexity.
+
+## 📊 Complexity Assessment Framework
+
+### **Technical Complexity Factors**
+
+#### **Code Changes**
+
+- **Simple**: Text, styling, configuration updates
+
+- **Medium**: New components, refactoring existing code
+
+- **Complex**: Architecture changes, new patterns, integrations
+
+- **Unknown**: New technologies, APIs, or approaches
+
+#### **Platform Impact**
+
+- **Single platform**: Web-only or mobile-only changes
+
+- **Two platforms**: Web + mobile or web + desktop
+
+- **Three platforms**: Web + mobile + desktop
+
+- **Cross-platform consistency**: Ensuring behavior matches across all platforms
+
+#### **Testing Requirements**
+
+- **Basic**: Unit tests for new functionality
+
+- **Comprehensive**: Integration tests, cross-platform testing
+
+- **User acceptance**: User testing, feedback integration
+
+- **Performance**: Load testing, optimization validation
+
+### **Dependency Complexity**
+
+#### **Internal Dependencies**
+
+- **Low**: Self-contained changes, no other components affected
+
+- **Medium**: Changes affect related components or services
+
+- **High**: Changes affect core architecture or multiple systems
+
+- **Critical**: Changes affect data models or core business logic
+
+#### **External Dependencies**
+
+- **None**: No external services or APIs involved
+
+- **Low**: Simple API calls or service integrations
+
+- **Medium**: Complex integrations with external systems
+
+- **High**: Third-party platform dependencies or complex APIs
+
+#### **Infrastructure Dependencies**
+
+- **None**: No infrastructure changes required
+
+- **Low**: Configuration updates or environment changes
+
+- **Medium**: New services or infrastructure components
+
+- **High**: Platform migrations or major infrastructure changes
+
+## 🔍 Complexity Evaluation Process
+
+### **Step 1: Technical Assessment**
+
+1. **Identify scope of changes** - what files/components are affected
+
+2. **Assess platform impact** - which platforms need updates
+
+3. **Evaluate testing needs** - what testing is required
+
+4. **Consider performance impact** - will this affect performance
+
+### **Step 2: Dependency Mapping**
+
+1. **Map internal dependencies** - what other components are affected
+
+2. **Identify external dependencies** - what external services are involved
+
+3. **Assess infrastructure needs** - what infrastructure changes are required
+
+4. **Evaluate risk factors** - what could go wrong
+
+### **Step 3: Complexity Classification**
+
+1. **Assign complexity levels** to each factor
+
+2. **Identify highest complexity** areas that need attention
+
+3. **Plan mitigation strategies** for high-complexity areas
+
+4. **Set realistic expectations** based on complexity assessment
+
+## 📋 Complexity Assessment Checklist
+
+- [ ] Technical scope identified and mapped
+
+- [ ] Platform impact assessed across all targets
+
+- [ ] Testing requirements defined and planned
+
+- [ ] Internal dependencies mapped and evaluated
+
+- [ ] External dependencies identified and assessed
+
+- [ ] Infrastructure requirements evaluated
+
+- [ ] Risk factors identified and mitigation planned
+
+- [ ] Complexity levels assigned to all factors
+
+- [ ] Realistic expectations set based on assessment
+
+## 🎯 Complexity Reduction Strategies
+
+### **Scope Reduction**
+
+- Break large features into smaller, manageable pieces
+
+- Focus on core functionality first, add polish later
+
+- Consider phased rollout to reduce initial complexity
+
+### **Dependency Management**
+
+- Minimize external dependencies when possible
+
+- Use abstraction layers to isolate complex integrations
+
+- Plan for dependency failures and fallbacks
+
+### **Testing Strategy**
+
+- Start with basic testing and expand coverage
+
+- Use automated testing to reduce manual testing complexity
+
+- Plan for iterative testing and feedback cycles
+
+## **See also**
+
+- `.cursor/rules/development/realistic_time_estimation.mdc` for the core principles
+
+- `.cursor/rules/development/planning_examples.mdc` for planning examples
+
+## Model Implementation Checklist
+
+### Before Complexity Assessment
+
+- [ ] **Problem Scope**: Clearly define the problem to be assessed
+- [ ] **Stakeholder Identification**: Identify all parties affected by complexity
+- [ ] **Context Analysis**: Understand technical and business context
+- [ ] **Assessment Criteria**: Define what factors determine complexity
+
+### During Complexity Assessment
+
+- [ ] **Technical Mapping**: Map technical scope and platform impact
+- [ ] **Dependency Analysis**: Identify internal and external dependencies
+- [ ] **Risk Evaluation**: Assess infrastructure needs and risk factors
+- [ ] **Complexity Classification**: Assign complexity levels to all factors
+
+### After Complexity Assessment
+
+- [ ] **Mitigation Planning**: Plan strategies for high-complexity areas
+- [ ] **Expectation Setting**: Set realistic expectations based on assessment
+- [ ] **Documentation**: Document assessment process and findings
+- [ ] **Stakeholder Communication**: Share results and recommendations

.cursor/rules/development/dependency_management.mdc

@@ -0,0 +1,177 @@
+# Dependency Management — Best Practices
+
+> **Agent role**: Reference this file for dependency management strategies and
+  best practices when working with software projects.
+
+## Dependency Management Best Practices
+
+### Pre-build Validation
+
+- **Check Critical Dependencies**:
+
+  Validate essential tools before executing build
+  scripts
+
+- **Use npx for Local Dependencies**: Prefer `npx tsx` over direct `tsx` to
+
+  avoid PATH issues
+
+- **Environment Consistency**: Ensure all team members have identical dependency
+
+  versions
+
+### Common Pitfalls
+
+- **Missing npm install**: Team members cloning without running `npm install`
+
+- **PATH Issues**: Direct command execution vs. npm script execution differences
+
+- **Version Mismatches**: Different Node.js/npm versions across team members
+
+### Validation Strategies
+
+- **Dependency Check Scripts**: Implement pre-build validation for critical
+
+  dependencies
+
+- **Environment Requirements**:
+
+  Document and enforce minimum Node.js/npm versions
+
+- **Onboarding Checklist**: Standardize team member setup procedures
+
+### Error Messages and Guidance
+
+- **Specific Error Context**:
+
+  Provide clear guidance when dependency issues occur
+
+- **Actionable Solutions**: Direct users to specific commands (`npm install`,
+
+  `npm run check:dependencies`)
+
+- **Environment Diagnostics**: Implement comprehensive environment validation
+
+  tools
+
+### Build Script Enhancements
+
+- **Early Validation**: Check dependencies before starting build processes
+
+- **Graceful Degradation**: Continue builds when possible but warn about issues
+
+- **Helpful Tips**: Remind users about dependency management best practices
+
+## Environment Setup Guidelines
+
+### Required Tools
+
+- **Node.js**: Minimum version requirements and LTS recommendations
+
+- **npm**: Version compatibility and global package management
+
+- **Platform-specific tools**: Android SDK, Xcode, etc.
+
+### Environment Variables
+
+- **NODE_ENV**: Development, testing, production environments
+
+- **PATH**: Ensure tools are accessible from command line
+
+- **Platform-specific**: Android SDK paths, Xcode command line tools
+
+### Validation Commands
+
+```bash
+
+# Check Node.js version
+
+node --version
+
+# Check npm version
+
+npm --version
+
+# Check global packages
+
+npm list -g --depth=0
+
+# Validate platform tools
+
+npx capacitor doctor
+
+```
+
+## Dependency Troubleshooting
+
+### Common Issues
+
+1. **Permission Errors**: Use `sudo` sparingly, prefer `npm config set prefix`
+
+2. **Version Conflicts**: Use `npm ls` to identify dependency conflicts
+
+3. **Cache Issues**: Clear npm cache with `npm cache clean --force`
+
+4. **Lock File Issues**: Delete `package-lock.json` and `node_modules`,
+
+  then reinstall
+
+### Resolution Strategies
+
+- **Dependency Audit**: Run `npm audit` to identify security issues
+
+- **Version Pinning**: Use exact versions for critical dependencies
+
+- **Peer Dependency Management**: Ensure compatible versions across packages
+
+- **Platform-specific Dependencies**: Handle different requirements per platform
+
+## Best Practices for Teams
+
+### Onboarding
+
+- **Environment Setup Script**: Automated setup for new team members
+
+- **Version Locking**: Use `package-lock.json` and `yarn.lock` consistently
+
+- **Documentation**: Clear setup instructions with troubleshooting steps
+
+### Maintenance
+
+- **Regular Updates**: Schedule dependency updates and security patches
+
+- **Testing**: Validate changes don't break existing functionality
+
+- **Rollback Plan**: Maintain ability to revert to previous working versions
+
+**See also**:
+  `.cursor/rules/development/software_development.mdc` for core development principles.
+
+**Status**: Active dependency management guidelines
+**Priority**: Medium
+**Estimated Effort**: Ongoing reference
+**Dependencies**: software_development.mdc
+**Stakeholders**: Development team, DevOps team
+
+## Model Implementation Checklist
+
+### Before Dependency Changes
+
+- [ ] **Current State Review**: Check current dependency versions and status
+- [ ] **Impact Analysis**: Assess impact of dependency changes on codebase
+- [ ] **Compatibility Check**: Verify compatibility with existing code
+- [ ] **Security Review**: Review security implications of dependency changes
+
+### During Dependency Management
+
+- [ ] **Version Selection**: Choose appropriate dependency versions
+- [ ] **Testing**: Test with new dependency versions
+- [ ] **Documentation**: Update dependency documentation
+- [ ] **Team Communication**: Communicate changes to team members
+
+### After Dependency Changes
+
+- [ ] **Comprehensive Testing**: Test all functionality with new dependencies
+- [ ] **Documentation Update**: Update all relevant documentation
+- [ ] **Deployment Planning**: Plan and execute deployment strategy
+- [ ] **Monitoring**: Monitor for issues after deployment

.cursor/rules/development/development_guide.mdc

@@ -2,8 +2,29 @@
 globs: **/src/**/*
 alwaysApply: false
 ---
-✅ use system date command to timestamp all interactions with accurate date and time
-✅ python script files must always have a blank line at their end
+✅ use system date command to timestamp all documentation with accurate date and
+  time
 ✅ remove whitespace at the end of lines
 ✅ use npm run lint-fix to check for warnings
 ✅ do not use npm run dev let me handle running and supplying feedback
+
+## Model Implementation Checklist
+
+### Before Development Work
+
+- [ ] **System Date Check**: Use system date command for accurate timestamps
+- [ ] **Environment Setup**: Verify development environment is ready
+- [ ] **Linting Setup**: Ensure npm run lint-fix is available
+- [ ] **Code Standards**: Review project coding standards and requirements
+
+### During Development
+
+- [ ] **Timestamp Usage**: Include accurate timestamps in all interactions
+- [ ] **Code Quality**: Use npm run lint-fix to check for warnings
+- [ ] **Whitespace**: Remove trailing whitespace from all lines
+
+### After Development
+
+- [ ] **Linting Check**: Run npm run lint-fix to verify code quality
+- [ ] **Whitespace Review**: Verify no trailing whitespace remains
+- [ ] **Documentation**: Update relevant documentation with changes

.cursor/rules/development/historical_comment_management.mdc

@@ -0,0 +1,119 @@
+# Historical Comment Management — Code Clarity Guidelines
+
+> **Agent role**: When encountering historical comments about removed
+> methods, deprecated patterns, or architectural changes, apply these
+> guidelines to maintain code clarity and developer guidance.
+
+## Overview
+
+Historical comments should either be **removed entirely** or **transformed
+into actionable guidance** for future developers. Avoid keeping comments
+that merely state what was removed without explaining why or what to do
+instead.
+
+## Decision Framework
+
+### When to Remove Comments
+
+- **Obsolete Information**: Comment describes functionality that no
+  longer exists
+- **Outdated Context**: Comment refers to old patterns that are no
+  longer relevant
+- **No Actionable Value**: Comment doesn't help future developers
+  make decisions
+
+### When to Transform Comments
+
+- **Migration Guidance**: Future developers might need to understand
+  the evolution
+- **Alternative Approaches**: The comment can guide future
+  implementation choices
+- **Historical Context**: Understanding the change helps with
+  current decisions
+
+## Transformation Patterns
+
+### 1. **Removed Method** → **Alternative Approach**
+
+```typescript
+// Before: Historical comment
+// turnOffNotifyingFlags method removed - notification state is now
+// managed by NotificationSection component
+
+// After: Actionable guidance
+// Note: Notification state management has been migrated to
+// NotificationSection component
+```
+
+### 2. **Deprecated Pattern** → **Current Best Practice**
+
+```typescript
+// Before: Historical comment
+// Database access has been migrated from direct IndexedDB calls to
+// PlatformServiceMixin
+
+// After: Actionable guidance
+// This provides better platform abstraction and consistent error
+// handling across web/mobile/desktop
+
+// When adding new database operations, use this.$getContact(),
+// this.$saveSettings(), etc.
+```
+
+## Best Practices
+
+### 1. **Use Actionable Language**: Guide future decisions, not just
+
+document history
+
+### 2. **Provide Alternatives**: Always suggest what to use instead
+
+### 3. **Update Related Docs**: If removing from code, consider
+
+adding to documentation
+
+### 4. **Keep Context**: Include enough information to understand
+
+why the change was made
+
+## Integration Points
+
+- Apply these rules when reviewing code changes
+- Use during code cleanup and refactoring
+- Include in code review checklists
+
+---
+
+**See also**:
+
+- `.cursor/rules/development/historical_comment_patterns.mdc` for detailed
+  transformation examples and patterns
+
+**Status**: Active comment management guidelines
+**Priority**: Medium
+**Estimated Effort**: Ongoing reference
+**Dependencies**: None
+**Stakeholders**: Development team, Code reviewers
+
+## Model Implementation Checklist
+
+### Before Comment Review
+
+- [ ] **Code Analysis**: Review code for historical or outdated comments
+- [ ] **Context Understanding**: Understand the current state of the codebase
+- [ ] **Pattern Identification**: Identify comments that need transformation or removal
+- [ ] **Documentation Planning**: Plan where to move important historical context
+
+### During Comment Management
+
+- [ ] **Transformation**: Convert historical comments to actionable guidance
+- [ ] **Alternative Provision**: Suggest current best practices and alternatives
+- [ ] **Context Preservation**: Maintain enough information to understand changes
+- [ ] **Documentation Update**: Move important context to appropriate documentation
+
+### After Comment Management
+
+- [ ] **Code Review**: Ensure transformed comments provide actionable value
+- [ ] **Documentation Sync**: Verify related documentation is updated
+- [ ] **Team Communication**: Share comment transformation patterns with team
+- [ ] **Process Integration**: Include comment management in code review checklists

.cursor/rules/development/historical_comment_patterns.mdc

@@ -0,0 +1,139 @@
+# Historical Comment Patterns — Transformation Examples
+
+> **Agent role**: Reference this file for specific patterns and
+  examples when transforming historical comments into actionable guidance.
+
+## 🔄 Transformation Patterns
+
+### 1. From Removal Notice to Migration Note
+
+```typescript
+
+// ❌ REMOVE THIS
+// turnOffNotifyingFlags method removed - 
+  notification state is now managed by NotificationSection component
+
+// ✅ TRANSFORM TO THIS
+// Note: Notification state management has been migrated to NotificationSection
+  component
+// which handles its own lifecycle and persistence via PlatformServiceMixin
+
+```
+
+### 2. From Deprecation Notice to Implementation Guide
+
+```typescript
+
+// ❌ REMOVE THIS
+// This will be handled by the NewComponent now
+// No need to call oldMethod() as it's no longer needed
+
+// ✅ TRANSFORM TO THIS
+// Note: This functionality has been migrated to NewComponent
+// which provides better separation of concerns and testability
+
+```
+
+### 3. From Historical Note to Architectural Context
+
+```typescript
+
+// ❌ REMOVE THIS
+// Old approach: used direct database calls
+// New approach: uses service layer
+
+// ✅ TRANSFORM TO THIS
+// Note: Database access has been abstracted through service layer
+// for better testability and platform independence
+
+```
+
+## 🚫 Anti-Patterns to Remove
+
+- Comments that only state what was removed
+
+- Comments that don't explain the current approach
+
+- Comments that reference non-existent methods
+
+- Comments that are self-evident from the code
+
+- Comments that don't help future decision-making
+
+## 📚 Examples
+
+### Good Historical Comment (Keep & Transform)
+
+```typescript
+
+// Note: Database access has been migrated from direct IndexedDB calls to
+  PlatformServiceMixin
+// This provides better platform abstraction and 
+  consistent error handling across web/mobile/desktop
+// When adding new database operations, use this.$getContact(),
+  this.$saveSettings(), etc.
+
+```
+
+### Bad Historical Comment (Remove)
+
+```typescript
+
+// Old method getContactFromDB() removed - now handled by PlatformServiceMixin
+// No need to call the old method anymore
+
+```
+
+## 🎯 When to Use Each Pattern
+
+### Migration Notes
+
+- Use when functionality has moved to a different component/service
+
+- Explain the new location and why it's better
+
+- Provide guidance on how to use the new approach
+
+### Implementation Guides
+
+- Use when patterns have changed significantly
+
+- Explain the architectural benefits
+
+- Show how to implement the new pattern
+
+### Architectural Context
+
+- Use when the change represents a system-wide improvement
+
+- Explain the reasoning behind the change
+
+- Help future developers understand the evolution
+
+---
+
+**See also**: `.cursor/rules/development/historical_comment_management.mdc` for
+  the core decision framework and best practices.
+
+## Model Implementation Checklist
+
+### Before Comment Review
+
+- [ ] **Code Analysis**: Review code for historical or outdated comments
+- [ ] **Pattern Identification**: Identify comments that need transformation or removal
+- [ ] **Context Understanding**: Understand the current state of the codebase
+- [ ] **Transformation Planning**: Plan how to transform or remove comments
+
+### During Comment Transformation
+
+- [ ] **Pattern Selection**: Choose appropriate transformation pattern
+- [ ] **Content Creation**: Create actionable guidance for future developers
+- [ ] **Alternative Provision**: Suggest current best practices and approaches
+- [ ] **Context Preservation**: Maintain enough information to understand changes
+
+### After Comment Transformation
+
+- [ ] **Code Review**: Ensure transformed comments provide actionable value
+- [ ] **Pattern Documentation**: Document transformation patterns for team use
+- [ ] **Team Communication**: Share comment transformation patterns with team
+- [ ] **Process Integration**: Include comment patterns in code review checklists

.cursor/rules/development/investigation_report_example.mdc

@@ -14,70 +14,100 @@ import scenarios.
 ## System Map
 
 - User action → ContactInputForm → ContactsView.addContact() →
+
   handleRegistrationPrompt()
+
 - setTimeout(1000ms) → Modal dialog → User response → Registration API call
+
 - Test execution → Wait for dialog → Assert dialog content → Click response
+
   button
 
 ## Findings (Evidence)
 
 - **1-second timeout causes flakiness** — evidence:
+
   `src/views/ContactsView.vue:971-1000`; setTimeout(..., 1000) in
   handleRegistrationPrompt()
+
 - **Import flow bypasses dialogs** — evidence:
+
   `src/views/ContactImportView.vue:500-520`; importContacts() calls
   $insertContact() directly, no handleRegistrationPrompt()
+
 - **Dialog only appears in direct add flow** — evidence:
+
   `src/views/ContactsView.vue:774-800`; addContact() calls
   handleRegistrationPrompt() after database insert
 
 ## Hypotheses & Failure Modes
 
 - H1: 1-second timeout makes dialog appearance unpredictable; would fail when
+
   tests run faster than 1000ms
+
 - H2: Test environment timing differs from development; watch for CI vs local
+
   test differences
 
 ## Corrections
 
 - Updated: "Multiple dialogs interfere with imports" → "Import flow never
+
   triggers dialogs - they only appear in direct contact addition"
+
 - Updated: "Complex batch registration needed" → "Simple timeout removal and
+
   test mode flag sufficient"
 
 ## Diagnostics (Next Checks)
 
 - [ ] Repro on CI environment vs local
+
 - [ ] Measure actual dialog appearance timing
+
 - [ ] Test with setTimeout removed
+
 - [ ] Verify import flow doesn't call handleRegistrationPrompt
 
 ## Risks & Scope
 
 - Impacted: Contact addition tests, registration workflow tests; Data: None;
+
   Users: Test suite reliability
 
 ## Decision / Next Steps
 
 - Owner: Development Team; By: 2025-01-28
+
 - Action: Remove 1-second timeout + add test mode flag; Exit criteria: Tests
+
   pass consistently
 
 ## References
 
 - `src/views/ContactsView.vue:971-1000`
+
 - `src/views/ContactImportView.vue:500-520`
+
 - `src/views/ContactsView.vue:774-800`
 
 ## Competence Hooks
 
 - Why this works: Code path tracing revealed separate execution flows,
+
   evidence disproved initial assumptions
+
 - Common pitfalls: Assuming related functionality without tracing execution
+
   paths, over-engineering solutions to imaginary problems
+
 - Next skill: Learn to trace code execution before proposing architectural
+
   changes
+
 - Teach-back: "What evidence shows that contact imports bypass registration
+
   dialogs?"
 
 ## Key Learning Points
@@ -87,8 +117,11 @@ import scenarios.
 This investigation demonstrates the importance of:
 
 1. **Tracing actual code execution** rather than making assumptions
+
 2. **Citing specific evidence** with file:line references
+
 3. **Validating problem scope** before proposing solutions
+
 4. **Considering simpler alternatives** before complex architectural changes
 
 ### Code Path Tracing Value
@@ -96,7 +129,9 @@ This investigation demonstrates the importance of:
 By tracing the execution paths, we discovered:
 
 - Import flow and direct add flow are completely separate
+
 - The "multiple dialog interference" problem didn't exist
+
 - A simple timeout removal would solve the actual issue
 
 ### Prevention of Over-Engineering
@@ -104,8 +139,11 @@ By tracing the execution paths, we discovered:
 The investigation prevented:
 
 - Unnecessary database schema changes
+
 - Complex batch registration systems
+
 - Migration scripts for non-existent problems
+
 - Architectural changes based on assumptions
 
 ---
@@ -115,3 +153,26 @@ The investigation prevented:
 **Estimated Effort**: Ongoing reference
 **Dependencies**: software_development.mdc
 **Stakeholders**: Development team, QA team
+
+## Model Implementation Checklist
+
+### Before Investigation
+
+- [ ] **Problem Definition**: Clearly define the problem to investigate
+- [ ] **Scope Definition**: Determine investigation scope and boundaries
+- [ ] **Methodology Planning**: Plan investigation approach and methods
+- [ ] **Resource Assessment**: Identify required resources and tools
+
+### During Investigation
+
+- [ ] **Evidence Collection**: Gather relevant evidence and data systematically
+- [ ] **Code Path Tracing**: Map execution flow for software investigations
+- [ ] **Analysis**: Analyze evidence using appropriate methods
+- [ ] **Documentation**: Document investigation process and findings
+
+### After Investigation
+
+- [ ] **Synthesis**: Synthesize findings into actionable insights
+- [ ] **Report Creation**: Create comprehensive investigation report
+- [ ] **Recommendations**: Provide clear, actionable recommendations
+- [ ] **Team Communication**: Share findings and next steps with team

.cursor/rules/development/logging_migration.mdc

@@ -0,0 +1,358 @@
+---
+alwaysApply: false
+---
+
+# Logging Migration — Patterns and Examples
+
+> **Agent role**: Reference this file for specific migration patterns and
+  examples when converting console.* calls to logger usage.
+
+## Migration — Auto‑Rewrites (Apply Every Time)
+
+### Exact Transforms
+
+- `console.debug(...)` → `logger.debug(...)`
+
+- `console.log(...)` → `logger.log(...)` (or `logger.info(...)` when
+
+  clearly stateful)
+
+- `console.info(...)` → `logger.info(...)`
+
+- `console.warn(...)` → `logger.warn(...)`
+
+- `console.error(...)` → `logger.error(...)`
+
+### Multi-arg Handling
+
+- First arg becomes `message` (stringify safely if non-string).
+
+- Remaining args map 1:1 to `...args`:
+
+  `console.info(msg, a, b)` → `logger.info(String(msg), a, b)`
+
+### Sole `Error`
+
+- `console.error(err)` → `logger.error(err.message, err)`
+
+### Object-wrapping Cleanup
+
+Replace `{{ userId, meta }}` wrappers with separate args:
+`logger.info('User signed in', userId, meta)`
+
+## Level Guidelines with Examples
+
+### DEBUG Examples
+
+```typescript
+
+logger.debug('[HomeView] reloadFeedOnChange() called');
+logger.debug('[HomeView] Current filter settings',
+  settings.filterFeedByVisible,
+  settings.filterFeedByNearby,
+  settings.searchBoxes?.length ?? 0);
+logger.debug('[FeedFilters] Toggling nearby filter',
+  this.isNearby, this.settingChanged, this.activeDid);
+
+```
+
+**Avoid**: Vague messages (`'Processing data'`).
+
+### INFO Examples
+
+```typescript
+
+logger.info('[StartView] Component mounted', process.env.VITE_PLATFORM);
+logger.info('[StartView] User selected new seed generation');
+logger.info('[SearchAreaView] Search box stored',
+  searchBox.name, searchBox.bbox);
+logger.info('[ContactQRScanShowView] Contact registration OK',
+  contact.did);
+
+```
+
+**Avoid**: Diagnostic details that belong in `debug`.
+
+### WARN Examples
+
+```typescript
+
+logger.warn('[ContactQRScanShowView] Invalid scan result – no value',
+  resultType);
+logger.warn('[ContactQRScanShowView] Invalid QR format – no JWT in URL');
+logger.warn('[ContactQRScanShowView] JWT missing "own" field');
+
+```
+
+**Avoid**: Hard failures (those are `error`).
+
+### ERROR Examples
+
+```typescript
+
+logger.error('[HomeView Settings] initializeIdentity() failed', err);
+logger.error('[StartView] Failed to load initialization data', error);
+logger.error('[ContactQRScanShowView] Error processing contact QR',
+  error, rawValue);
+
+```
+
+**Avoid**: Expected user cancels (use `info`/`debug`).
+
+## Context Hygiene Examples
+
+### Component Context
+
+```typescript
+
+const log = logger.withContext('UserService');
+log.info('User created', userId);
+log.error('Failed to create user', error);
+
+```
+
+If not using `withContext`, prefix message with `[ComponentName]`.
+
+### Emoji Guidelines
+
+Recommended set for visual scanning:
+
+- Start/finish: 🚀 / ✅
+
+- Retry/loop: 🔄
+
+- External call: 📡
+
+- Data/metrics: 📊
+
+- Inspection: 🔍
+
+## Quick Before/After
+
+### **Before**
+
+```typescript
+
+console.log('User signed in', user.id, meta);
+console.error('Failed to update profile', err);
+console.info('Filter toggled', this.hasVisibleDid);
+
+```
+
+### **After**
+
+```typescript
+
+import { logger } from '@/utils/logger';
+
+logger.info('User signed in', user.id, meta);
+logger.error('Failed to update profile', err);
+logger.debug('[FeedFilters] Filter toggled', this.hasVisibleDid);
+
+```
+
+## Checklist (for every PR)
+
+- [ ] No `console.*` (or properly pragma'd in the allowed locations)
+
+- [ ] Correct import path for `logger`
+
+- [ ] Rest-parameter call shape (`message, ...args`)
+
+- [ ] Right level chosen (debug/info/warn/error)
+
+- [ ] No secrets / oversized payloads / throwaway context objects
+
+- [ ] Component context provided (scoped logger or `[Component]` prefix)
+
+**See also**:
+  `.cursor/rules/development/logging_standards.mdc` for the core standards and rules.
+
+# Logging Migration — Patterns and Examples
+
+> **Agent role**: Reference this file for specific migration patterns and
+  examples when converting console.* calls to logger usage.
+
+## Migration — Auto‑Rewrites (Apply Every Time)
+
+### Exact Transforms
+
+- `console.debug(...)` → `logger.debug(...)`
+
+- `console.log(...)` → `logger.log(...)` (or `logger.info(...)` when
+
+  clearly stateful)
+
+- `console.info(...)` → `logger.info(...)`
+
+- `console.warn(...)` → `logger.warn(...)`
+
+- `console.error(...)` → `logger.error(...)`
+
+### Multi-arg Handling
+
+- First arg becomes `message` (stringify safely if non-string).
+
+- Remaining args map 1:1 to `...args`:
+
+  `console.info(msg, a, b)` → `logger.info(String(msg), a, b)`
+
+### Sole `Error`
+
+- `console.error(err)` → `logger.error(err.message, err)`
+
+### Object-wrapping Cleanup
+
+Replace `{{ userId, meta }}` wrappers with separate args:
+`logger.info('User signed in', userId, meta)`
+
+## Level Guidelines with Examples
+
+### DEBUG Examples
+
+```typescript
+
+logger.debug('[HomeView] reloadFeedOnChange() called');
+logger.debug('[HomeView] Current filter settings',
+  settings.filterFeedByVisible,
+  settings.filterFeedByNearby,
+  settings.searchBoxes?.length ?? 0);
+logger.debug('[FeedFilters] Toggling nearby filter',
+  this.isNearby, this.settingChanged, this.activeDid);
+
+```
+
+**Avoid**: Vague messages (`'Processing data'`).
+
+### INFO Examples
+
+```typescript
+
+logger.info('[StartView] Component mounted', process.env.VITE_PLATFORM);
+logger.info('[StartView] User selected new seed generation');
+logger.info('[SearchAreaView] Search box stored',
+  searchBox.name, searchBox.bbox);
+logger.info('[ContactQRScanShowView] Contact registration OK',
+  contact.did);
+
+```
+
+**Avoid**: Diagnostic details that belong in `debug`.
+
+### WARN Examples
+
+```typescript
+
+logger.warn('[ContactQRScanShowView] Invalid scan result – no value',
+  resultType);
+logger.warn('[ContactQRScanShowView] Invalid QR format – no JWT in URL');
+logger.warn('[ContactQRScanShowView] JWT missing "own" field');
+
+```
+
+**Avoid**: Hard failures (those are `error`).
+
+### ERROR Examples
+
+```typescript
+
+logger.error('[HomeView Settings] initializeIdentity() failed', err);
+logger.error('[StartView] Failed to load initialization data', error);
+logger.error('[ContactQRScanShowView] Error processing contact QR',
+  error, rawValue);
+
+```
+
+**Avoid**: Expected user cancels (use `info`/`debug`).
+
+## Context Hygiene Examples
+
+### Component Context
+
+```typescript
+
+const log = logger.withContext('UserService');
+log.info('User created', userId);
+log.error('Failed to create user', error);
+
+```
+
+If not using `withContext`, prefix message with `[ComponentName]`.
+
+### Emoji Guidelines
+
+Recommended set for visual scanning:
+
+- Start/finish: 🚀 / ✅
+
+- Retry/loop: 🔄
+
+- External call: 📡
+
+- Data/metrics: 📊
+
+- Inspection: 🔍
+
+## Quick Before/After
+
+### **Before**
+
+```typescript
+
+console.log('User signed in', user.id, meta);
+console.error('Failed to update profile', err);
+console.info('Filter toggled', this.hasVisibleDid);
+
+```
+
+### **After**
+
+```typescript
+
+import { logger } from '@/utils/logger';
+
+logger.info('User signed in', user.id, meta);
+logger.error('Failed to update profile', err);
+logger.debug('[FeedFilters] Filter toggled', this.hasVisibleDid);
+
+```
+
+## Checklist (for every PR)
+
+- [ ] No `console.*` (or properly pragma'd in the allowed locations)
+
+- [ ] Correct import path for `logger`
+
+- [ ] Rest-parameter call shape (`message, ...args`)
+
+- [ ] Right level chosen (debug/info/warn/error)
+
+- [ ] No secrets / oversized payloads / throwaway context objects
+
+- [ ] Component context provided (scoped logger or `[Component]` prefix)
+
+**See also**:
+  `.cursor/rules/development/logging_standards.mdc` for the core standards and rules.
+
+## Model Implementation Checklist
+
+### Before Logging Migration
+
+- [ ] **Code Review**: Identify all `console.*` calls in the codebase
+- [ ] **Logger Import**: Verify logger utility is available and accessible
+- [ ] **Context Planning**: Plan component context for each logging call
+- [ ] **Level Assessment**: Determine appropriate log levels for each call
+
+### During Logging Migration
+
+- [ ] **Import Replacement**: Replace `console.*` with `logger.*` calls
+- [ ] **Context Addition**: Add component context using scoped logger or prefix
+- [ ] **Level Selection**: Choose appropriate log level (debug/info/warn/error)
+- [ ] **Parameter Format**: Use rest-parameter call shape (`message, ...args`)
+
+### After Logging Migration
+
+- [ ] **Console Check**: Ensure no `console.*` methods remain (unless pragma'd)
+- [ ] **Context Validation**: Verify all logging calls have proper context
+- [ ] **Level Review**: Confirm log levels are appropriate for each situation
+- [ ] **Testing**: Test logging functionality across all platforms

.cursor/rules/development/logging_standards.mdc

@@ -21,29 +21,49 @@ logger; no `console.*` in production code.
 ## Non‑Negotiables (DO THIS)
 
 - You **MUST** use the project logger; **DO NOT** use any `console.*`
+
   methods.
+
 - Import exactly as:
+
   - `import { logger } from '@/utils/logger'`
+
   - If `@` alias is unavailable, compute the correct relative path (do not
+
     fail).
+
 - Call signatures use **rest parameters**: `logger.info(message, ...args)`
+
 - Prefer primitives/IDs and small objects in `...args`; **never build a
+
   throwaway object** just to "wrap context".
+
 - Production defaults: Web = `warn+`, Electron = `error`, Dev/Capacitor =
+
   `info+` (override via `VITE_LOG_LEVEL`).
+
 - **Database persistence**: `info|warn|error` are persisted; `debug` is not.
+
   Use `logger.toDb(msg, level?)` for DB-only.
 
 ## Available Logger API (Authoritative)
 
 - `logger.debug(message, ...args)` — verbose internals, timings, input/output
+
   shapes
+
 - `logger.log(message, ...args)` — synonym of `info` for general info
+
 - `logger.info(message, ...args)` — lifecycle, state changes, success paths
+
 - `logger.warn(message, ...args)` — recoverable issues, retries, degraded mode
+
 - `logger.error(message, ...args)` — failures, thrown exceptions, aborts
+
 - `logger.toDb(message, level?)` — DB-only entry (default level = `info`)
+
 - `logger.toConsoleAndDb(message, isError)` — console + DB (use sparingly)
+
 - `logger.withContext(componentName)` — returns a scoped logger
 
 ## Level Guidelines (Use These Heuristics)
@@ -53,108 +73,34 @@ logger; no `console.*` in production code.
 Use for method entry/exit, computed values, filters, loops, retries, and
 external call payload sizes.
 
-```typescript
-logger.debug('[HomeView] reloadFeedOnChange() called');
-logger.debug('[HomeView] Current filter settings', 
-  settings.filterFeedByVisible, 
-  settings.filterFeedByNearby, 
-  settings.searchBoxes?.length ?? 0);
-logger.debug('[FeedFilters] Toggling nearby filter', 
-  this.isNearby, this.settingChanged, this.activeDid);
-```
-
-**Avoid**: Vague messages (`'Processing data'`).
-
 ### INFO
 
 Use for user-visible lifecycle and completed operations.
 
-```typescript
-logger.info('[StartView] Component mounted', process.env.VITE_PLATFORM);
-logger.info('[StartView] User selected new seed generation');
-logger.info('[SearchAreaView] Search box stored', 
-  searchBox.name, searchBox.bbox);
-logger.info('[ContactQRScanShowView] Contact registration OK', 
-  contact.did);
-```
-
-**Avoid**: Diagnostic details that belong in `debug`.
-
 ### WARN
 
 Use for recoverable issues, fallbacks, unexpected-but-handled conditions.
 
-```typescript
-logger.warn('[ContactQRScanShowView] Invalid scan result – no value', 
-  resultType);
-logger.warn('[ContactQRScanShowView] Invalid QR format – no JWT in URL');
-logger.warn('[ContactQRScanShowView] JWT missing "own" field');
-```
-
-**Avoid**: Hard failures (those are `error`).
-
 ### ERROR
 
 Use for unrecoverable failures, data integrity issues, and thrown
 exceptions.
 
-```typescript
-logger.error('[HomeView Settings] initializeIdentity() failed', err);
-logger.error('[StartView] Failed to load initialization data', error);
-logger.error('[ContactQRScanShowView] Error processing contact QR', 
-  error, rawValue);
-```
-
-**Avoid**: Expected user cancels (use `info`/`debug`).
-
 ## Context Hygiene (Consistent, Minimal, Helpful)
 
 - **Component context**: Prefer scoped logger.
 
-```typescript
-const log = logger.withContext('UserService');
-log.info('User created', userId);
-log.error('Failed to create user', error);
-```
-
-If not using `withContext`, prefix message with `[ComponentName]`.
-
-- **Emojis**: Optional and minimal for visual scanning. Recommended set:
-  - Start/finish: 🚀 / ✅
-  - Retry/loop: 🔄
-  - External call: 📡
-  - Data/metrics: 📊
-  - Inspection: 🔍
+- **Emojis**: Optional and minimal for visual scanning.
 
 - **Sensitive data**: Never log secrets (tokens, keys, passwords) or
   payloads >10KB. Prefer IDs over objects; redact/hash when needed.
 
-## Migration — Auto‑Rewrites (Apply Every Time)
-
-- Exact transforms:
-  - `console.debug(...)` → `logger.debug(...)`
-  - `console.log(...)` → `logger.log(...)` (or `logger.info(...)` when
-    clearly stateful)
-  - `console.info(...)` → `logger.info(...)`
-  - `console.warn(...)` → `logger.warn(...)`
-  - `console.error(...)` → `logger.error(...)`
-
-- Multi-arg handling:
-  - First arg becomes `message` (stringify safely if non-string).
-  - Remaining args map 1:1 to `...args`:
-    `console.info(msg, a, b)` → `logger.info(String(msg), a, b)`
-
-- Sole `Error`:
-  - `console.error(err)` → `logger.error(err.message, err)`
-
-- **Object-wrapping cleanup**: Replace `{{ userId, meta }}` wrappers with
-  separate args:
-  `logger.info('User signed in', userId, meta)`
-
 ## DB Logging Rules
 
 - `debug` **never** persists automatically.
+
 - `info|warn|error` persist automatically.
+
 - For DB-only events (no console), call `logger.toDb('Message',
   'info'|'warn'|'error')`.
 
@@ -163,60 +109,68 @@ If not using `withContext`, prefix message with `[ComponentName]`.
 Allowed paths (still prefer logger):
 
 - `**/*.test.*`, `**/*.spec.*`
+
 - `scripts/dev/**`, `scripts/migrate/**`
 
 To intentionally keep `console.*`, add a pragma on the previous line:
 
 ```typescript
+
 // cursor:allow-console reason="short justification"
 console.log('temporary output');
-```
 
-Without the pragma, rewrite to `logger.*`.
+```
 
 ## CI & Diff Enforcement
 
 - Do not introduce `console.*` anywhere outside allowed, pragma'd spots.
+
 - If an import is missing, insert it and resolve alias/relative path
   correctly.
+
 - Enforce rest-parameter call shape in reviews; replace object-wrapped
   context.
+
 - Ensure environment log level rules remain intact (`VITE_LOG_LEVEL`
   respected).
 
-## Quick Before/After
-
-### **Before**
-
-```typescript
-console.log('User signed in', user.id, meta);
-console.error('Failed to update profile', err);
-console.info('Filter toggled', this.hasVisibleDid);
-```
-
-### **After**
-
-```typescript
-import { logger } from '@/utils/logger';
-
-logger.info('User signed in', user.id, meta);
-logger.error('Failed to update profile', err);
-logger.debug('[FeedFilters] Filter toggled', this.hasVisibleDid);
-```
-
-## Checklist (for every PR)
-
-- [ ] No `console.*` (or properly pragma'd in the allowed locations)
-- [ ] Correct import path for `logger`
-- [ ] Rest-parameter call shape (`message, ...args`)
-- [ ] Right level chosen (debug/info/warn/error)
-- [ ] No secrets / oversized payloads / throwaway context objects
-- [ ] Component context provided (scoped logger or `[Component]` prefix)
-
 ---
 
+**See also**:
+  `.cursor/rules/development/logging_migration.mdc` for migration patterns and examples.
+
 **Status**: Active and enforced
 **Priority**: Critical
 **Estimated Effort**: Ongoing reference
 **Dependencies**: TimeSafari logger utility
 **Stakeholders**: Development team, Code review team
+
+## Model Implementation Checklist
+
+### Before Adding Logging
+
+- [ ] **Logger Import**: Import logger as `import { logger } from
+  '@/utils/logger'`
+- [ ] **Log Level Selection**: Determine appropriate log level
+  (debug/info/warn/error)
+- [ ] **Context Planning**: Plan what context information to include
+- [ ] **Sensitive Data Review**: Identify any sensitive data that needs redaction
+
+### During Logging Implementation
+
+- [ ] **Rest Parameters**: Use `logger.info(message, ...args)` format, not object
+  wrapping
+- [ ] **Context Addition**: Include relevant IDs, primitives, or small objects in
+  args
+- [ ] **Level Appropriateness**: Use correct log level for the situation
+- [ ] **Scoped Logger**: Use `logger.withContext(componentName)` for
+  component-specific logging
+
+### After Logging Implementation
+
+- [ ] **Console Check**: Ensure no `console.*` methods are used (unless in
+  allowed paths)
+- [ ] **Performance Review**: Verify logging doesn't impact performance
+- [ ] **DB Persistence**: Use `logger.toDb()` for database-only logging if needed
+- [ ] **Environment Compliance**: Respect `VITE_LOG_LEVEL` environment
+  variable

.cursor/rules/development/planning_examples.mdc

@@ -0,0 +1,160 @@
+# Planning Examples — No Time Estimates
+
+> **Agent role**: Reference this file for detailed planning examples and
+  anti-patterns when creating project plans.
+
+## 🎯 Example Planning (No Time Estimates)
+
+### **Example 1: Simple Feature**
+
+```
+
+Phase 1: Core implementation
+
+- Basic functionality
+
+- Single platform support
+
+- Unit tests
+
+Phase 2: Platform expansion
+
+- Multi-platform support
+
+- Integration tests
+
+Phase 3: Polish
+
+- User testing
+
+- Edge case handling
+
+```
+
+### **Example 2: Complex Cross-Platform Feature**
+
+```
+
+Phase 1: Foundation
+
+- Architecture design
+
+- Core service implementation
+
+- Basic web platform support
+
+Phase 2: Platform Integration
+
+- Mobile platform support
+
+- Desktop platform support
+
+- Cross-platform consistency
+
+Phase 3: Testing & Polish
+
+- Comprehensive testing
+
+- Error handling
+
+- User experience refinement
+
+```
+
+## 🚫 Anti-Patterns to Avoid
+
+- **"This should take X days"** - Red flag for time estimation
+
+- **"Just a few hours"** - Ignores complexity and testing
+
+- **"Similar to X"** - Without considering differences
+
+- **"Quick fix"** - Nothing is ever quick in software
+
+- **"No testing needed"** - Testing always takes effort
+
+## ✅ Best Practices
+
+### **When Planning:**
+
+1. **Break down everything** - no work is too small to plan
+
+2. **Consider all platforms** - web, mobile, desktop differences
+
+3. **Include testing strategy** - unit, integration, and user testing
+
+4. **Account for unknowns** - there are always surprises
+
+5. **Focus on dependencies** - what blocks what
+
+### **When Presenting Plans:**
+
+1. **Show the phases** - explain the logical progression
+
+2. **Highlight dependencies** - what could block progress
+
+3. **Define milestones** - clear success criteria
+
+4. **Identify risks** - what could go wrong
+
+5. **Suggest alternatives** - ways to reduce scope or complexity
+
+## 🔄 Continuous Improvement
+
+### **Track Progress**
+
+- Record planned vs. actual phases completed
+
+- Identify what took longer than expected
+
+- Learn from complexity misjudgments
+
+- Adjust planning process based on experience
+
+### **Learn from Experience**
+
+- **Underestimated complexity**: Increase complexity categories
+
+- **Missed dependencies**: Improve dependency mapping
+
+- **Platform surprises**: Better platform research upfront
+
+## 🎯 Integration with Harbor Pilot
+
+This rule works in conjunction with:
+
+- **Project Planning**: Focuses on phases and milestones
+
+- **Resource Allocation**: Based on complexity, not time
+
+- **Risk Management**: Identifies blockers and dependencies
+
+- **Stakeholder Communication**: Sets progress-based expectations
+
+---
+
+**See also**: `.cursor/rules/development/realistic_time_estimation.mdc` for
+  the core principles and framework.
+
+## Model Implementation Checklist
+
+### Before Planning
+
+- [ ] **Requirements Review**: Understand all requirements completely
+- [ ] **Stakeholder Input**: Gather input from all stakeholders
+- [ ] **Complexity Assessment**: Evaluate technical and business complexity
+- [ ] **Platform Analysis**: Consider requirements across all target platforms
+
+### During Planning
+
+- [ ] **Phase Definition**: Define clear phases and milestones
+- [ ] **Dependency Mapping**: Map dependencies between tasks
+- [ ] **Risk Identification**: Identify potential risks and challenges
+- [ ] **Testing Strategy**: Plan comprehensive testing approach
+
+### After Planning
+
+- [ ] **Stakeholder Review**: Review plan with stakeholders
+- [ ] **Documentation**: Document plan clearly with phases and milestones
+- [ ] **Team Communication**: Communicate plan to team
+- [ ] **Progress Tracking**: Set up monitoring and tracking mechanisms

.cursor/rules/development/realistic_time_estimation.mdc

@@ -0,0 +1,128 @@
+# Realistic Time Estimation — Development Guidelines
+
+> **Agent role**: **DO NOT MAKE TIME ESTIMATES**. Instead, use phases,
+> milestones, and complexity levels. Time estimates are consistently wrong
+> and create unrealistic expectations.
+
+## Purpose
+
+Development time estimates are consistently wrong and create unrealistic
+expectations. This rule ensures we focus on phases, milestones, and
+complexity rather than trying to predict specific timeframes.
+
+## Critical Rule
+
+**NEVER provide specific time estimates** (hours, days, weeks) for
+development tasks. Instead, use:
+
+- **Complexity levels** (Low, Medium, High, Critical)
+
+- **Phases and milestones** with clear acceptance criteria
+
+- **Platform-specific considerations** (Web, Mobile, Desktop)
+
+- **Testing requirements** and validation steps
+
+## Planning Framework
+
+### Complexity Assessment
+
+- **Low**: Simple changes, existing patterns, minimal testing
+
+- **Medium**: New features, moderate testing, some integration
+
+- **High**: Complex features, extensive testing, multiple platforms
+
+- **Critical**: Core architecture changes, full regression testing
+
+### Platform Categories
+
+- **Web**: Browser compatibility, responsive design, accessibility
+
+- **Mobile**: Native APIs, platform-specific testing, deployment
+
+- **Desktop**: Electron integration, system APIs, distribution
+
+### Testing Strategy
+
+- **Unit tests**: Core functionality validation
+
+- **Integration tests**: Component interaction testing
+
+- **E2E tests**: User workflow validation
+
+- **Platform tests**: Cross-platform compatibility
+
+## Process Guidelines
+
+### Planning Phase
+
+1. **Scope Definition**: Clear requirements and acceptance criteria
+
+2. **Complexity Assessment**: Evaluate technical and business complexity
+
+3. **Phase Breakdown**: Divide into logical, testable phases
+
+4. **Milestone Definition**: Define success criteria for each phase
+
+### Execution Phase
+
+1. **Phase 1**: Foundation and core implementation
+
+2. **Phase 2**: Feature completion and integration
+
+3. **Phase 3**: Testing, refinement, and documentation
+
+4. **Phase 4**: Deployment and validation
+
+### Validation Phase
+
+1. **Acceptance Testing**: Verify against defined criteria
+
+2. **Platform Testing**: Validate across target platforms
+
+3. **Performance Testing**: Ensure performance requirements met
+
+4. **Documentation**: Update relevant documentation
+
+## Remember
+
+**Your first estimate is wrong. Your second estimate is probably still
+wrong. Focus on progress, not deadlines.**
+
+---
+
+**See also**:
+
+- `.cursor/rules/development/planning_examples.mdc` for detailed planning examples
+
+- `.cursor/rules/development/complexity_assessment.mdc` for complexity evaluation
+
+**Status**: Active development guidelines
+**Priority**: High
+**Estimated Effort**: Ongoing reference
+**Dependencies**: None
+**Stakeholders**: Development team, Project managers
+
+## Model Implementation Checklist
+
+### Before Time Estimation
+
+- [ ] **Requirements Analysis**: Understand all requirements and acceptance criteria
+- [ ] **Complexity Assessment**: Evaluate technical and business complexity
+- [ ] **Platform Review**: Identify requirements across all target platforms
+- [ ] **Stakeholder Input**: Gather input from all affected parties
+
+### During Time Estimation
+
+- [ ] **Phase Breakdown**: Divide work into logical, testable phases
+- [ ] **Complexity Classification**: Assign complexity levels (Low/Medium/High/Critical)
+- [ ] **Platform Considerations**: Account for platform-specific requirements
+- [ ] **Testing Strategy**: Plan comprehensive testing approach
+
+### After Time Estimation
+
+- [ ] **Milestone Definition**: Define success criteria for each phase
+- [ ] **Progress Tracking**: Set up monitoring and tracking mechanisms
+- [ ] **Documentation**: Document estimation process and assumptions
+- [ ] **Stakeholder Communication**: Share estimation approach and progress focus

.cursor/rules/development/research_diagnostic.mdc

@@ -1,8 +1,12 @@
 ---
-description: Use this workflow when doing **pre-implementation research, defect investigations with uncertain repros, or clarifying system architecture and behaviors**.
+description: Use this workflow when doing **pre-implementation research, defect
+  investigations with uncertain repros, or clarifying system architecture and
+  behaviors**.
 alwaysApply: false
 ---
+
 ```json
+
 {
   "coaching_level": "light",
   "socratic_max_questions": 2,
@@ -10,6 +14,7 @@ alwaysApply: false
   "timebox_minutes": null,
   "format_enforcement": "strict"
 }
+
 ```
 
 # Research & Diagnostic Workflow (R&D)
@@ -23,7 +28,9 @@ steps—**not** code changes.
 ## When to Use
 
 - Pre-implementation research for new features
+
 - Defect investigations (repros uncertain, user-specific failures)
+
 - Architecture/behavior clarifications (e.g., auth flows, merges, migrations)
 
 ---
@@ -33,7 +40,9 @@ steps—**not** code changes.
 When investigating software issues, also apply:
 
 - **Code Path Tracing**: Required for technical investigations
+
 - **Evidence Validation**: Ensure claims are code-backed
+
 - **Solution Complexity Assessment**: Justify architectural changes
 
 ---
@@ -60,48 +69,73 @@ When investigating software issues, also apply:
 Copy/paste and fill:
 
 ```md
+
 # Investigation — <short title>
 
 ## Objective
+
 <one or two lines>
 
 ## System Map
+
 - <module> → <function> → <downstream>
+
 - <data path> → <db table> → <api>
 
 ## Findings (Evidence)
-- <claim> — evidence: `src/path/file.ts:function` (lines X–Y); log snippet/trace id
+
+- <claim> — 
+
+  evidence: `src/path/file.ts:function` (lines X–Y); log snippet/trace id
+
 - <claim> — evidence: `...`
 
 ## Hypotheses & Failure Modes
+
 - H1: <hypothesis>; would fail when <condition>
+
 - H2: <hypothesis>; watch for <signal>
 
 ## Corrections
+
 - Updated: <old statement> → <new statement with evidence>
 
 ## Diagnostics (Next Checks)
+
 - [ ] Repro on <platform/version>
+
 - [ ] Inspect <table/store> for <record>
+
 - [ ] Capture <log/trace>
 
 ## Risks & Scope
+
 - Impacted: <areas/components>; Data: <tables/keys>; Users: <segments>
 
 ## Decision / Next Steps
+
 - Owner: <name>; By: <date> (YYYY-MM-DD)
+
 - Action: <spike/bugfix/ADR>; Exit criteria: <binary checks>
 
 ## References
+
 - `src/...`
-- ADR: `docs/adr/xxxx-yy-zz-something.md`
-- Design: `docs/...`
+
+- ADR: `doc/adr/xxxx-yy-zz-something.md`
+
+- Design: `doc/...`
 
 ## Competence Hooks
+
 - Why this works: <≤3 bullets>
+
 - Common pitfalls: <≤3 bullets>
+
 - Next skill: <≤1 item>
+
 - Teach-back: "<one question>"
+
 ```
 
 ---
@@ -109,8 +143,13 @@ Copy/paste and fill:
 ## Evidence Quality Bar
 
 - **Cite the source** (file:func, line range if possible).
+
 - **Prefer primary evidence** (code, logs) over inference.
-- **Disambiguate platform** (Web/Capacitor/Electron) and **state** (migration, auth).
+
+- **Disambiguate platform** (Web/Capacitor/Electron) and **state** (migration,
+
+  auth).
+
 - **Note uncertainty** explicitly.
 
 ---
@@ -119,10 +158,16 @@ Copy/paste and fill:
 
 Before proposing solutions, trace the actual execution path:
 
-- [ ] **Entry Points**: Identify where the flow begins (user action, API call, etc.)
+- [ ] **Entry Points**:
+
+  Identify where the flow begins (user action, API call, etc.)
+
 - [ ] **Component Flow**: Map which components/methods are involved
+
 - [ ] **Data Path**: Track how data moves through the system
+
 - [ ] **Exit Points**: Confirm where the flow ends and what results
+
 - [ ] **Evidence Collection**: Gather specific code citations for each step
 
 ---
@@ -130,7 +175,9 @@ Before proposing solutions, trace the actual execution path:
 ## Collaboration Hooks
 
 - **Syncs:** 10–15m with QA/Security/Platform owners for high-risk areas.
+
 - **ADR:** Record major decisions; link here.
+
 - **Review:** Share repro + diagnostics checklist in PR/issue.
 
 ---
@@ -139,13 +186,20 @@ Before proposing solutions, trace the actual execution path:
 
 ### With software_development.mdc
 
-- **Enhanced Evidence Validation**: Use code path tracing for technical investigations
-- **Architecture Assessment**: Apply complexity justification to proposed solutions
+- **Enhanced Evidence Validation**:
+
+  Use code path tracing for technical investigations
+
+- **Architecture Assessment**:
+
+  Apply complexity justification to proposed solutions
+
 - **Impact Analysis**: Assess effects on existing systems before recommendations
 
 ### With base_context.mdc
 
 - **Competence Building**: Focus on technical investigation skills
+
 - **Collaboration**: Structure outputs for team review and discussion
 
 ---
@@ -153,11 +207,17 @@ Before proposing solutions, trace the actual execution path:
 ## Self-Check (model, before responding)
 
 - [ ] Output matches the **Output Contract** sections.
+
 - [ ] Each claim has **evidence** or **uncertainty** is flagged.
+
 - [ ] Hypotheses are testable; diagnostics are actionable.
+
 - [ ] Competence + collaboration hooks present (≤120 words total).
+
 - [ ] Respect toggles; keep it concise.
+
 - [ ] **Code path traced** (for software investigations).
+
 - [ ] **Evidence validated** against actual code execution.
 
 ---
@@ -166,9 +226,37 @@ Before proposing solutions, trace the actual execution path:
 
 > Uncomment `globs` in the header if you want auto-attach behavior.
 
-- `src/platforms/**`, `src/services/**` — attach during service/feature investigations
-- `docs/adr/**` — attach when editing ADRs
+- `src/platforms/**`, `src/services/**` —
+
+  attach during service/feature investigations
+
+- `doc/adr/**` — attach when editing ADRs
 
 ## Referenced Files
 
-- Consider including templates as context: `@adr_template.mdc`, `@investigation_report_example.mdc`
+- Consider including templates as context: `@adr_template.mdc`,
+
+  `@investigation_report_example.mdc`
+
+## Model Implementation Checklist
+
+### Before Investigation
+
+- [ ] **Problem Definition**: Clearly define the research question or issue
+- [ ] **Scope Definition**: Determine investigation scope and boundaries
+- [ ] **Methodology Planning**: Plan investigation approach and methods
+- [ ] **Resource Assessment**: Identify required resources and tools
+
+### During Investigation
+
+- [ ] **Evidence Collection**: Gather relevant evidence and data systematically
+- [ ] **Code Path Tracing**: Map execution flow for software investigations
+- [ ] **Analysis**: Analyze evidence using appropriate methods
+- [ ] **Documentation**: Document investigation process and findings
+
+### After Investigation
+
+- [ ] **Synthesis**: Synthesize findings into actionable insights
+- [ ] **Report Creation**: Create comprehensive investigation report
+- [ ] **Recommendations**: Provide clear, actionable recommendations
+- [ ] **Team Communication**: Share findings and next steps with team

.cursor/rules/development/software_development.mdc

@@ -1,4 +1,9 @@
 
+---
+
+alwaysApply: false
+---
+
 # Software Development Ruleset
 
 **Author**: Matthew Raymer
@@ -15,34 +20,52 @@ debugging, architecture decisions, and testing.
 ### 1. Evidence-First Development
 
 - **Code Citations Required**: Always cite specific file:line references when
+
   making claims
+
 - **Execution Path Tracing**: Trace actual code execution before proposing
+
   architectural changes
+
 - **Assumption Validation**: Flag assumptions as "assumed" vs "evidence-based"
 
 ### 2. Code Review Standards
 
 - **Trace Before Proposing**: Always trace execution paths before suggesting
+
   changes
+
 - **Evidence Over Inference**: Prefer code citations over logical deductions
+
 - **Scope Validation**: Confirm the actual scope of problems before proposing
+
   solutions
 
 ### 3. Problem-Solution Validation
 
 - **Problem Scope**: Does the solution address the actual problem?
+
 - **Evidence Alignment**: Does the solution match the evidence?
+
 - **Complexity Justification**: Is added complexity justified by real needs?
+
 - **Alternative Analysis**: What simpler solutions were considered?
 
 ### 4. Dependency Management & Environment Validation
 
-- **Pre-build Validation**: Always validate critical dependencies before executing
+- **Pre-build Validation**:
+
+  Always validate critical dependencies before executing
   build scripts
+
 - **Environment Consistency**: Ensure team members have identical development
+
   environments
+
 - **Dependency Verification**: Check that required packages are installed and
+
   accessible
+
 - **Path Resolution**: Use `npx` for local dependencies to avoid PATH issues
 
 ## Required Workflows
@@ -50,18 +73,27 @@ debugging, architecture decisions, and testing.
 ### Before Proposing Changes
 
 - [ ] **Code Path Tracing**: Map execution flow from entry to exit
+
 - [ ] **Evidence Collection**: Gather specific code citations and logs
+
 - [ ] **Assumption Surfacing**: Identify what's proven vs. inferred
+
 - [ ] **Scope Validation**: Confirm the actual extent of the problem
+
 - [ ] **Dependency Validation**: Verify all required dependencies are available
+
   and accessible
 
 ### During Solution Design
 
 - [ ] **Evidence Alignment**: Ensure solution addresses proven problems
+
 - [ ] **Complexity Assessment**: Justify any added complexity
+
 - [ ] **Alternative Evaluation**: Consider simpler approaches first
+
 - [ ] **Impact Analysis**: Assess effects on existing systems
+
 - [ ] **Environment Impact**: Assess how changes affect team member setups
 
 ## Software-Specific Competence Hooks
@@ -69,78 +101,53 @@ debugging, architecture decisions, and testing.
 ### Evidence Validation
 
 - **"What code path proves this claim?"**
+
 - **"How does data actually flow through the system?"**
+
 - **"What am I assuming vs. what can I prove?"**
 
 ### Code Tracing
 
 - **"What's the execution path from user action to system response?"**
+
 - **"Which components actually interact in this scenario?"**
+
 - **"Where does the data originate and where does it end up?"**
 
 ### Architecture Decisions
 
 - **"What evidence shows this change is necessary?"**
+
 - **"What simpler solution could achieve the same goal?"**
+
 - **"How does this change affect the existing system architecture?"**
 
 ### Dependency & Environment Management
 
 - **"What dependencies does this feature require and are they properly
+
   declared?"**
+
 - **"How will this change affect team member development environments?"**
+
 - **"What validation can we add to catch dependency issues early?"**
 
-## Dependency Management Best Practices
-
-### Pre-build Validation
-
-- **Check Critical Dependencies**: Validate essential tools before executing build
-  scripts
-- **Use npx for Local Dependencies**: Prefer `npx tsx` over direct `tsx` to
-  avoid PATH issues
-- **Environment Consistency**: Ensure all team members have identical dependency
-  versions
-
-### Common Pitfalls
-
-- **Missing npm install**: Team members cloning without running `npm install`
-- **PATH Issues**: Direct command execution vs. npm script execution differences
-- **Version Mismatches**: Different Node.js/npm versions across team members
-
-### Validation Strategies
-
-- **Dependency Check Scripts**: Implement pre-build validation for critical
-  dependencies
-- **Environment Requirements**: Document and enforce minimum Node.js/npm versions
-- **Onboarding Checklist**: Standardize team member setup procedures
-
-### Error Messages and Guidance
-
-- **Specific Error Context**: Provide clear guidance when dependency issues occur
-- **Actionable Solutions**: Direct users to specific commands (`npm install`,
-  `npm run check:dependencies`)
-- **Environment Diagnostics**: Implement comprehensive environment validation
-  tools
-
-### Build Script Enhancements
-
-- **Early Validation**: Check dependencies before starting build processes
-- **Graceful Degradation**: Continue builds when possible but warn about issues
-- **Helpful Tips**: Remind users about dependency management best practices
-
 ## Integration with Other Rulesets
 
 ### With base_context.mdc
 
 - Inherits generic competence principles
+
 - Adds software-specific evidence requirements
+
 - Maintains collaboration and learning focus
 
 ### With research_diagnostic.mdc
 
 - Enhances investigation with code path tracing
+
 - Adds evidence validation to diagnostic workflow
+
 - Strengthens problem identification accuracy
 
 ## Usage Guidelines
@@ -148,78 +155,73 @@ debugging, architecture decisions, and testing.
 ### When to Use This Ruleset
 
 - Code reviews and architectural decisions
+
 - Bug investigation and debugging
+
 - Performance optimization
+
 - Feature implementation planning
+
 - Testing strategy development
 
 ### When to Combine with Others
 
 - **base_context + software_development**: General development tasks
+
 - **research_diagnostic + software_development**: Technical investigations
+
 - **All three**: Complex architectural decisions or major refactoring
 
 ## Self-Check (model, before responding)
 
 - [ ] Code path traced and documented
+
 - [ ] Evidence cited with specific file:line references
+
 - [ ] Assumptions clearly flagged as proven vs. inferred
+
 - [ ] Solution complexity justified by evidence
+
 - [ ] Simpler alternatives considered and documented
+
 - [ ] Impact on existing systems assessed
+
 - [ ] Dependencies validated and accessible
+
 - [ ] Environment impact assessed for team members
+
 - [ ] Pre-build validation implemented where appropriate
 
-## Additional Core Principles
+---
 
-### 4. Dependency Management & Environment Validation
-- **Pre-build Validation**: Always validate critical dependencies before executing build scripts
-- **Environment Consistency**: Ensure team members have identical development environments
-- **Dependency Verification**: Check that required packages are installed and accessible
-- **Path Resolution**: Use `npx` for local dependencies to avoid PATH issues
+**See also**: `.cursor/rules/development/dependency_management.mdc` for
+  detailed dependency management practices.
 
-## Additional Required Workflows
+**Status**: Active development guidelines
+**Priority**: High
+**Estimated Effort**: Ongoing reference
+**Dependencies**: base_context.mdc, research_diagnostic.mdc
+**Stakeholders**: Development team, Code review team
 
-### Dependency Validation (Before Proposing Changes)
-- [ ] **Dependency Validation**: Verify all required dependencies are available and accessible
+## Model Implementation Checklist
 
-### Environment Impact Assessment (During Solution Design)
+### Before Development Work
+
+- [ ] **Code Path Tracing**: Map execution flow from entry to exit
+- [ ] **Evidence Collection**: Gather specific code citations and logs
+- [ ] **Assumption Surfacing**: Identify what's proven vs. inferred
+- [ ] **Scope Validation**: Confirm the actual extent of the problem
+
+### During Development
+
+- [ ] **Evidence Alignment**: Ensure solution addresses proven problems
+- [ ] **Complexity Assessment**: Justify any added complexity
+- [ ] **Alternative Evaluation**: Consider simpler approaches first
+- [ ] **Impact Analysis**: Assess effects on existing systems
+
+### After Development
+
+- [ ] **Code Path Validation**: Verify execution paths are correct
+- [ ] **Evidence Documentation**: Document all code citations and evidence
+- [ ] **Assumption Review**: Confirm all assumptions are documented
 - [ ] **Environment Impact**: Assess how changes affect team member setups
-
-## Additional Competence Hooks
-
-### Dependency & Environment Management
-- **"What dependencies does this feature require and are they properly declared?"**
-- **"How will this change affect team member development environments?"**
-- **"What validation can we add to catch dependency issues early?"**
-
-## Dependency Management Best Practices
-
-### Pre-build Validation
-- **Check Critical Dependencies**: Validate essential tools before executing build scripts
-- **Use npx for Local Dependencies**: Prefer `npx tsx` over direct `tsx` to avoid PATH issues
-- **Environment Consistency**: Ensure all team members have identical dependency versions
-
-### Common Pitfalls
-- **Missing npm install**: Team members cloning without running `npm install`
-- **PATH Issues**: Direct command execution vs. npm script execution differences
-- **Version Mismatches**: Different Node.js/npm versions across team members
-
-### Validation Strategies
-- **Dependency Check Scripts**: Implement pre-build validation for critical dependencies
-- **Environment Requirements**: Document and enforce minimum Node.js/npm versions
-- **Onboarding Checklist**: Standardize team member setup procedures
-
-### Error Messages and Guidance
-- **Specific Error Context**: Provide clear guidance when dependency issues occur
-- **Actionable Solutions**: Direct users to specific commands (`npm install`, `npm run check:dependencies`)
-- **Environment Diagnostics**: Implement comprehensive environment validation tools
-
-### Build Script Enhancements
-- **Early Validation**: Check dependencies before starting build processes
-- **Graceful Degradation**: Continue builds when possible but warn about issues
-- **Helpful Tips**: Remind users about dependency management best practices
-
-- **Narrow Types Properly**: Use type guards to narrow `unknown` types safely
-- **Document Type Decisions**: Explain complex type structures and their purpose

.cursor/rules/development/time.mdc

@@ -0,0 +1,146 @@
+# Time Handling in Development Workflow
+
+**Author**: Matthew Raymer
+**Date**: 2025-08-17
+**Status**: 🎯 **ACTIVE** - Production Ready
+
+## Overview
+
+This guide establishes **how time should be referenced and used** across the
+development workflow. It is not tied to any one project, but applies to **all
+feature development, issue investigations, ADRs, and documentation**.
+
+## General Principles
+
+- **Explicit over relative**: Always prefer absolute dates (`2025-08-17`) over
+
+  relative references like "last week."
+
+- **ISO 8601 Standard**: Use `YYYY-MM-DD` format for all date references in
+
+  docs, issues, ADRs, and commits.
+
+- **Time zones**: Default to **UTC** unless explicitly tied to user-facing
+
+  behavior.
+
+- **Precision**: Only specify as much precision as needed (date vs. datetime vs.
+
+  timestamp).
+
+- **Consistency**: Align time references across ADRs, commits, and investigation
+
+  reports.
+
+## In Documentation & ADRs
+
+- Record decision dates using **absolute ISO dates**.
+
+- For ongoing timelines, state start and end explicitly (e.g., `2025-08-01` →
+
+  `2025-08-17`).
+
+- Avoid ambiguous terms like *recently*, *last month*, or *soon*.
+
+- For time-based experiments (e.g., A/B tests), always include:
+
+  - Start date
+
+  - Expected duration
+
+  - Review date checkpoint
+
+## In Code & Commits
+
+- Use **UTC timestamps** in logs, DB migrations, and serialized formats.
+
+- In commits, link changes to **date-bound ADRs or investigation docs**.
+
+- For migrations, include both **applied date** and **intended version window**.
+
+- Use constants for known fixed dates; avoid hardcoding arbitrary strings.
+
+## In Investigations & Research
+
+- Capture **when** an issue occurred (absolute time or version tag).
+
+- When describing failures: note whether they are **time-sensitive** (e.g.,
+
+  after
+  migrations, cache expirations).
+
+- Record diagnostic timelines in ISO format (not relative).
+
+- For performance regressions, annotate both **baseline timeframe** and
+
+  **measurement timeframe**.
+
+## Collaboration Hooks
+
+- During reviews, verify **time references are clear, absolute, and
+
+  standardized**.
+
+- In syncs, reframe relative terms ("this week") into shared absolute
+
+  references.
+
+- Tag ADRs with both **date created** and **review by** checkpoints.
+
+## Self-Check Before Submitting
+
+- [ ] Did I check the time using the **developer's actual system time and
+
+      timezone**?
+
+- [ ] Am I using absolute ISO dates?
+
+- [ ] Is UTC assumed unless specified otherwise?
+
+- [ ] Did I avoid ambiguous relative terms?
+
+- [ ] If duration matters, did I specify both start and end?
+
+- [ ] For future work, did I include a review/revisit date?
+
+---
+
+**See also**:
+
+- `.cursor/rules/development/time_implementation.mdc` for
+
+  detailed implementation instructions
+
+- `.cursor/rules/development/time_examples.mdc` for practical examples and patterns
+
+**Status**: Active time handling guidelines
+**Priority**: High
+**Estimated Effort**: Ongoing reference
+**Dependencies**: None
+**Stakeholders**: Development team, Documentation team
+
+**Maintainer**: Matthew Raymer
+**Next Review**: 2025-09-17
+
+## Model Implementation Checklist
+
+### Before Time-Related Work
+
+- [ ] **Time Context**: Understand what time information is needed
+- [ ] **Format Review**: Review time formatting standards (UTC, ISO 8601)
+- [ ] **Platform Check**: Identify platform-specific time requirements
+- [ ] **User Context**: Consider user's timezone and preferences
+
+### During Time Implementation
+
+- [ ] **UTC Usage**: Use UTC for all system and log timestamps
+- [ ] **Format Consistency**: Apply consistent time formatting patterns
+- [ ] **Timezone Handling**: Properly handle timezone conversions
+- [ ] **User Display**: Format times appropriately for user display
+
+### After Time Implementation
+
+- [ ] **Validation**: Verify time formats are correct and consistent
+- [ ] **Testing**: Test time handling across different scenarios
+- [ ] **Documentation**: Update relevant documentation with time patterns
+- [ ] **Review**: Confirm implementation follows time standards

.cursor/rules/development/time_examples.mdc

@@ -0,0 +1,243 @@
+# Time Examples — Practical Patterns
+
+> **Agent role**: Reference this file for practical examples and
+  patterns when working with time handling in development.
+
+## Examples
+
+### Good
+
+- "Feature flag rollout started on `2025-08-01` and will be reviewed on
+
+  `2025-08-21`."
+
+- "Migration applied on `2025-07-15T14:00Z`."
+
+- "Issue reproduced on `2025-08-17T09:00-05:00 (local)` /
+
+  `2025-08-17T14:00Z (UTC)`."
+
+### Bad
+
+- "Feature flag rolled out last week."
+
+- "Migration applied recently."
+
+- "Now is August, so we assume this was last month."
+
+### More Examples
+
+#### Issue Reports
+
+- ✅ **Good**: "User reported login failure at `2025-08-17T14:30:00Z`. Issue
+
+  persisted until `2025-08-17T15:45:00Z`."
+
+- ❌ **Bad**: "User reported login failure earlier today. Issue lasted for a
+
+  while."
+
+#### Release Planning
+
+- ✅ **Good**: "Feature X scheduled for release on `2025-08-25`. Testing
+
+  window: `2025-08-20` to `2025-08-24`."
+
+- ❌ **Bad**: "Feature X will be released next week after testing."
+
+#### Performance Monitoring
+
+- ✅ **Good**: "Baseline performance measured on `2025-08-10T09:00:00Z`.
+
+  Regression detected on `2025-08-15T14:00:00Z`."
+
+- ❌ **Bad**: "Performance was good last week but got worse this week."
+
+## Technical Implementation Examples
+
+### Database Storage
+
+```sql
+
+-- ✅ Good: Store in UTC
+created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
+updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
+
+-- ❌ Bad: Store in local time
+created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
+updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
+
+```
+
+### API Responses
+
+```json
+
+// ✅ Good: Include both UTC and local time
+{
+  "eventTime": "2025-08-17T14:00:00Z",
+  "localTime": "2025-08-17T10:00:00-04:00",
+  "timezone": "America/New_York"
+}
+
+// ❌ Bad: Only local time
+{
+  "eventTime": "2025-08-17T10:00:00-04:00"
+}
+
+```
+
+### Logging
+
+```python
+
+# ✅ Good: Log in UTC with timezone info
+
+logger.info(f"User action at {datetime.utcnow().isoformat()}Z (UTC)")
+
+# ❌ Bad: Log in local time
+
+logger.info(f"User action at {datetime.now()}")
+
+```
+
+## Timezone Handling Examples
+
+### Good Timezone Usage
+
+```typescript
+
+// ✅ Good: Store UTC, convert for display
+const eventTime = new Date().toISOString(); // Store in UTC
+const localTime = new Date().toLocaleString('en-US', {
+  timeZone: 'America/New_York'
+}); // Convert for display
+
+// ✅ Good: Include timezone context
+const timestamp = {
+  utc: "2025-08-17T14:00:00Z",
+  local: "2025-08-17T10:00:00-04:00",
+  timezone: "America/New_York"
+};
+
+```
+
+### Bad Timezone Usage
+
+```typescript
+
+// ❌ Bad: Assume timezone
+const now = new Date(); // Assumes system timezone
+
+// ❌ Bad: Mix formats
+const timestamp = "2025-08-17 10:00 AM"; // Ambiguous format
+
+```
+
+## Common Patterns
+
+### Date Range References
+
+```typescript
+
+// ✅ Good: Explicit date ranges
+const dateRange = {
+  start: "2025-08-01T00:00:00Z",
+  end: "2025-08-31T23:59:59Z"
+};
+
+// ❌ Bad: Relative ranges
+const dateRange = {
+  start: "beginning of month",
+  end: "end of month"
+};
+
+```
+
+### Duration References
+
+```typescript
+
+// ✅ Good: Specific durations
+const duration = {
+  value: 30,
+  unit: "days",
+  startDate: "2025-08-01T00:00:00Z"
+};
+
+// ❌ Bad: Vague durations
+const duration = "about a month";
+
+```
+
+### Version References
+
+```typescript
+
+// ✅ Good: Version with date
+const version = {
+  number: "1.2.3",
+  releaseDate: "2025-08-17T10:00:00Z",
+  buildDate: "2025-08-17T09:30:00Z"
+};
+
+// ❌ Bad: Version without context
+const version = "latest";
+
+```
+
+## References
+
+- [ISO 8601 Date and Time Standard](https://en.wikipedia.org/wiki/ISO_8601)
+
+- [IANA Timezone Database](https://www.iana.org/time-zones)
+
+- [ADR Template](./adr_template.md)
+
+- [Research & Diagnostic Workflow](./research_diagnostic.mdc)
+
+---
+
+**Rule of Thumb**: Every time reference in development artifacts should be
+**clear in 6 months without context**, and aligned to the **developer's actual
+current time**.
+
+**Technical Rule of Thumb**: **Store in UTC, display in local time, always
+include timezone context.**
+
+---
+
+**See also**:
+
+- `.cursor/rules/development/time.mdc` for core principles
+
+- `.cursor/rules/development/time_implementation.mdc` for implementation instructions
+
+**Status**: Active examples and patterns
+**Priority**: Medium
+**Estimated Effort**: Ongoing reference
+**Dependencies**: time.mdc, time_implementation.mdc
+**Stakeholders**: Development team, Documentation team
+
+## Model Implementation Checklist
+
+### Before Time Implementation
+
+- [ ] **Time Context**: Understand what time information needs to be implemented
+- [ ] **Format Review**: Review time formatting standards (UTC, ISO 8601)
+- [ ] **Platform Check**: Identify platform-specific time requirements
+- [ ] **User Context**: Consider user's timezone and display preferences
+
+### During Time Implementation
+
+- [ ] **UTC Storage**: Use UTC for all system and log timestamps
+- [ ] **Format Consistency**: Apply consistent time formatting patterns
+- [ ] **Timezone Handling**: Properly handle timezone conversions
+- [ ] **User Display**: Format times appropriately for user display
+
+### After Time Implementation
+
+- [ ] **Format Validation**: Verify time formats are correct and consistent
+- [ ] **Cross-Platform Testing**: Test time handling across different platforms
+- [ ] **Documentation**: Update relevant documentation with time patterns
+- [ ] **User Experience**: Confirm time display is clear and user-friendly

.cursor/rules/development/time_implementation.mdc

@@ -1,91 +1,28 @@
----
-alwaysApply: true
----
-# Time Handling in Development Workflow
+# Time Implementation — Technical Instructions
 
-**Author**: Matthew Raymer
-**Date**: 2025-08-17
-**Status**: 🎯 **ACTIVE** - Production Ready
-
-## Overview
-
-This guide establishes **how time should be referenced and used** across the
-development workflow. It is not tied to any one project, but applies to **all
-feature development, issue investigations, ADRs, and documentation**.
-
-## General Principles
-
-- **Explicit over relative**: Always prefer absolute dates (`2025-08-17`) over
-  relative references like "last week."
-- **ISO 8601 Standard**: Use `YYYY-MM-DD` format for all date references in
-  docs, issues, ADRs, and commits.
-- **Time zones**: Default to **UTC** unless explicitly tied to user-facing
-  behavior.
-- **Precision**: Only specify as much precision as needed (date vs. datetime vs.
-  timestamp).
-- **Consistency**: Align time references across ADRs, commits, and investigation
-  reports.
-
-## In Documentation & ADRs
-
-- Record decision dates using **absolute ISO dates**.
-- For ongoing timelines, state start and end explicitly (e.g., `2025-08-01` →
-  `2025-08-17`).
-- Avoid ambiguous terms like *recently*, *last month*, or *soon*.
-- For time-based experiments (e.g., A/B tests), always include:
-
-  - Start date
-  - Expected duration
-  - Review date checkpoint
-
-## In Code & Commits
-
-- Use **UTC timestamps** in logs, DB migrations, and serialized formats.
-- In commits, link changes to **date-bound ADRs or investigation docs**.
-- For migrations, include both **applied date** and **intended version window**.
-- Use constants for known fixed dates; avoid hardcoding arbitrary strings.
-
-## In Investigations & Research
-
-- Capture **when** an issue occurred (absolute time or version tag).
-- When describing failures: note whether they are **time-sensitive** (e.g., after
-  migrations, cache expirations).
-- Record diagnostic timelines in ISO format (not relative).
-- For performance regressions, annotate both **baseline timeframe** and
-  **measurement timeframe**.
-
-## Collaboration Hooks
-
-- During reviews, verify **time references are clear, absolute, and
-  standardized**.
-- In syncs, reframe relative terms ("this week") into shared absolute
-  references.
-- Tag ADRs with both **date created** and **review by** checkpoints.
-
-## Self-Check Before Submitting
-
-- [ ] Did I check the time using the **developer's actual system time and
-      timezone**?
-- [ ] Am I using absolute ISO dates?
-- [ ] Is UTC assumed unless specified otherwise?
-- [ ] Did I avoid ambiguous relative terms?
-- [ ] If duration matters, did I specify both start and end?
-- [ ] For future work, did I include a review/revisit date?
+> **Agent role**: Reference this file for detailed implementation instructions
+  when working with time handling in development.
 
 ## Real-Time Context in Developer Interactions
 
 - The model must always resolve **"current time"** using the **developer's
+
   actual system time and timezone**.
+
 - When generating timestamps (e.g., in investigation logs, ADRs, or examples),
+
   the model should:
 
   - Use the **developer's current local time** by default.
+
   - Indicate the timezone explicitly (e.g., `2025-08-17T10:32-05:00`).
+
   - Optionally provide UTC alongside if context requires cross-team clarity.
 
 - When interpreting relative terms like *now*, *today*, *last week*:
 
   - Resolve them against the **developer's current time**.
+
   - Convert them into **absolute ISO-8601 values** in the output.
 
 ## LLM Time Checking Instructions
@@ -98,15 +35,21 @@ than assuming or inventing times.
 #### 1. **Query System Time (Required)**
 
 - **Always start** by querying the current system time using available tools
+
 - **Never assume** what the current time is
+
 - **Never use** placeholder values like "current time" or "now"
 
 #### 2. **Available Time Query Methods**
 
 - **System Clock**: Use `date` command or equivalent system time function
+
 - **Programming Language**: Use language-specific time functions (e.g.,
+
   `Date.now()`, `datetime.now()`)
+
 - **Environment Variables**: Check for time-related environment variables
+
 - **API Calls**: Use time service APIs if available
 
 #### 3. **Required Time Information**
@@ -114,53 +57,75 @@ than assuming or inventing times.
 When querying time, always obtain:
 
 - **Current Date**: YYYY-MM-DD format
+
 - **Current Time**: HH:MM:SS format (24-hour)
+
 - **Timezone**: Current system timezone or UTC offset
+
 - **UTC Equivalent**: Convert local time to UTC for cross-team clarity
 
 #### 4. **Time Query Examples**
 
 ```bash
+
 # Example: Query system time
+
 $ date
+
 # Expected output: Mon Aug 17 10:32:45 EDT 2025
 
 # Example: Query UTC time
+
 $ date -u
+
 # Expected output: Mon Aug 17 14:32:45 UTC 2025
+
 ```
 
 ```python
+
 # Example: Python time query
+
 import datetime
 current_time = datetime.datetime.now()
 utc_time = datetime.datetime.utcnow()
 print(f"Local: {current_time}")
 print(f"UTC: {utc_time}")
+
 ```
 
 ```javascript
+
 // Example: JavaScript time query
 const now = new Date();
 const utc = new Date().toISOString();
 console.log(`Local: ${now}`);
 console.log(`UTC: ${utc}`);
+
 ```
 
 #### 5. **LLM Time Checking Workflow**
 
 1. **Query**: Actively query system for current time
+
 2. **Validate**: Confirm time data is reasonable and current
+
 3. **Format**: Convert to ISO 8601 format
+
 4. **Context**: Provide both local and UTC times when helpful
+
 5. **Document**: Show the source of time information
 
 #### 6. **Error Handling for Time Queries**
 
 - **If time query fails**: Ask user for current time or use "unknown time"
+
   with explanation
+
 - **If timezone unclear**: Default to UTC and ask for clarification
+
 - **If time seems wrong**: Verify with user before proceeding
+
 - **Always log**: Record when and how time was obtained
 
 #### 7. **Time Query Verification**
@@ -168,64 +133,37 @@ console.log(`UTC: ${utc}`);
 Before using queried time, verify:
 
 - [ ] Time is recent (within last few minutes)
+
 - [ ] Timezone information is available
+
 - [ ] UTC conversion is accurate
+
 - [ ] Format follows ISO 8601 standard
 
 ## Model Behavior Rules
 
 - **Never invent a "fake now"**: All "current time" references must come from
+
   the real system clock available at runtime.
+
 - **Check developer time zone**: If ambiguous, ask for clarification (e.g.,
+
   "Should I use UTC or your local timezone?").
+
 - **Format for clarity**:
 
   - Local time: `YYYY-MM-DDTHH:mm±hh:mm`
+
   - UTC equivalent (if needed): `YYYY-MM-DDTHH:mmZ`
 
-## Examples
-
-### Good
-
-- "Feature flag rollout started on `2025-08-01` and will be reviewed on
-  `2025-08-21`."
-- "Migration applied on `2025-07-15T14:00Z`."
-- "Issue reproduced on `2025-08-17T09:00-05:00 (local)` /
-  `2025-08-17T14:00Z (UTC)`."
-
-### Bad
-
-- "Feature flag rolled out last week."
-- "Migration applied recently."
-- "Now is August, so we assume this was last month."
-
-### More Examples
-
-#### Issue Reports
-
-- ✅ **Good**: "User reported login failure at `2025-08-17T14:30:00Z`. Issue
-  persisted until `2025-08-17T15:45:00Z`."
-- ❌ **Bad**: "User reported login failure earlier today. Issue lasted for a
-  while."
-
-#### Release Planning
-
-- ✅ **Good**: "Feature X scheduled for release on `2025-08-25`. Testing
-  window: `2025-08-20` to `2025-08-24`."
-- ❌ **Bad**: "Feature X will be released next week after testing."
-
-#### Performance Monitoring
-
-- ✅ **Good**: "Baseline performance measured on `2025-08-10T09:00:00Z`.
-  Regression detected on `2025-08-15T14:00:00Z`."
-- ❌ **Bad**: "Performance was good last week but got worse this week."
-
 ## Technical Implementation Notes
 
 ### UTC Storage Principle
 
 - **Store all timestamps in UTC** in databases, logs, and serialized formats
+
 - **Convert to local time only for user display**
+
 - **Use ISO 8601 format** for all storage: `YYYY-MM-DDTHH:mm:ss.sssZ`
 
 ### Common Implementation Patterns
@@ -233,18 +171,17 @@ Before using queried time, verify:
 #### Database Storage
 
 ```sql
+
 -- ✅ Good: Store in UTC
 created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
 updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
 
--- ❌ Bad: Store in local time
-created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
-updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
 ```
 
 #### API Responses
 
 ```json
+
 // ✅ Good: Include both UTC and local time
 {
   "eventTime": "2025-08-17T14:00:00Z",
@@ -252,20 +189,16 @@ updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
   "timezone": "America/New_York"
 }
 
-// ❌ Bad: Only local time
-{
-  "eventTime": "2025-08-17T10:00:00-04:00"
-}
 ```
 
 #### Logging
 
 ```python
+
 # ✅ Good: Log in UTC with timezone info
+
 logger.info(f"User action at {datetime.utcnow().isoformat()}Z (UTC)")
 
-# ❌ Bad: Log in local time
-logger.info(f"User action at {datetime.now()}")
 ```
 
 ### Timezone Handling Best Practices
@@ -273,19 +206,25 @@ logger.info(f"User action at {datetime.now()}")
 #### 1. Always Store Timezone Information
 
 - Include IANA timezone identifier (e.g., `America/New_York`)
+
 - Store UTC offset at time of creation
+
 - Handle daylight saving time transitions automatically
 
 #### 2. User Display Considerations
 
 - Convert UTC to user's preferred timezone
+
 - Show timezone abbreviation when helpful
+
 - Use relative time for recent events ("2 hours ago")
 
 #### 3. Edge Case Handling
 
 - **Daylight Saving Time**: Use timezone-aware libraries
+
 - **Leap Seconds**: Handle gracefully (rare but important)
+
 - **Invalid Times**: Validate before processing
 
 ### Common Mistakes to Avoid
@@ -293,37 +232,54 @@ logger.info(f"User action at {datetime.now()}")
 #### 1. Timezone Confusion
 
 - ❌ **Don't**: Assume server timezone is user timezone
+
 - ✅ **Do**: Always convert UTC to user's local time for display
 
 #### 2. Format Inconsistency
 
 - ❌ **Don't**: Mix different time formats in the same system
+
 - ✅ **Do**: Standardize on ISO 8601 for all storage
 
 #### 3. Relative Time References
 
 - ❌ **Don't**: Use relative terms in persistent storage
+
 - ✅ **Do**: Convert relative terms to absolute timestamps immediately
 
-## References
-
-- [ISO 8601 Date and Time Standard](https://en.wikipedia.org/wiki/ISO_8601)
-- [IANA Timezone Database](https://www.iana.org/time-zones)
-- [ADR Template](./adr_template.md)
-- [Research & Diagnostic Workflow](./research_diagnostic.mdc)
-
 ---
 
-**Rule of Thumb**: Every time reference in development artifacts should be
-**clear in 6 months without context**, and aligned to the **developer's actual
-current time**.
+**See also**:
 
-**Technical Rule of Thumb**: **Store in UTC, display in local time, always
-include timezone context.**
+- `.cursor/rules/development/time.mdc` for core principles
 
----
+- `.cursor/rules/development/time_examples.mdc` for practical examples
 
-**Status**: Active
-**Version**: 1.0
-**Maintainer**: Matthew Raymer
-**Next Review**: 2025-09-17
+**Status**: Active implementation guidelines
+**Priority**: Medium
+**Estimated Effort**: Ongoing reference
+**Dependencies**: time.mdc
+**Stakeholders**: Development team, DevOps team
+
+## Model Implementation Checklist
+
+### Before Time Implementation
+
+- [ ] **Time Context**: Understand what time information needs to be implemented
+- [ ] **Format Review**: Review time formatting standards (UTC, ISO 8601)
+- [ ] **Platform Check**: Identify platform-specific time requirements
+- [ ] **User Context**: Consider user's timezone and display preferences
+
+### During Time Implementation
+
+- [ ] **UTC Storage**: Use UTC for all system and log timestamps
+- [ ] **Format Consistency**: Apply consistent time formatting patterns
+- [ ] **Timezone Handling**: Properly handle timezone conversions
+- [ ] **User Display**: Format times appropriately for user display
+
+### After Time Implementation
+
+- [ ] **Format Validation**: Verify time formats are correct and consistent
+- [ ] **Cross-Platform Testing**: Test time handling across different platforms
+- [ ] **Documentation**: Update relevant documentation with time patterns
+- [ ] **User Experience**: Confirm time display is clear and user-friendly

.cursor/rules/development/type_safety_guide.mdc

@@ -2,7 +2,9 @@
 description: when dealing with types and Typesript
 alwaysApply: false
 ---
+
 ```json
+
 {
   "coaching_level": "light",
   "socratic_max_questions": 7,
@@ -10,6 +12,7 @@ alwaysApply: false
   "timebox_minutes": null,
   "format_enforcement": "strict"
 }
+
 ```
 
 # TypeScript Type Safety Guidelines
@@ -25,18 +28,25 @@ Practical rules to keep TypeScript strict and predictable. Minimize exceptions.
 ## Core Rules
 
 1. **No `any`**
+
    - Use explicit types. If unknown, use `unknown` and **narrow** via guards.
 
 2. **Error handling uses guards**
+
    - Reuse guards from `src/interfaces/**` (e.g., `isDatabaseError`,
+
      `isApiError`).
+
    - Catch with `unknown`; never cast to `any`.
 
 3. **Dynamic property access is type‑safe**
+
    - Use `keyof` + `in` checks:
 
      ```ts
+
      obj[k as keyof typeof obj]
+
      ```
 
    - Avoid `(obj as any)[k]`.
@@ -46,24 +56,45 @@ Practical rules to keep TypeScript strict and predictable. Minimize exceptions.
 ### Core Type Safety Rules
 
 - **No `any` Types**: Use explicit types or `unknown` with proper type guards
-- **Error Handling Uses Guards**: Implement and reuse type guards from `src/interfaces/**`
-- **Dynamic Property Access**: Use `keyof` + `in` checks for type-safe property access
+
+- **Error Handling Uses Guards**:
+
+  Implement and reuse type guards from `src/interfaces/**`
+
+- **Dynamic Property Access**:
+
+  Use `keyof` + `in` checks for type-safe property access
 
 ### Type Guard Patterns
+
 - **API Errors**: Use `isApiError(error)` guards for API error handling
-- **Database Errors**: Use `isDatabaseError(error)` guards for database operations
-- **Axios Errors**: Implement `isAxiosError(error)` guards for HTTP error handling
+
+- **Database Errors**:
+
+  Use `isDatabaseError(error)` guards for database operations
+
+- **Axios Errors**:
+
+  Implement `isAxiosError(error)` guards for HTTP error handling
 
 ### Implementation Guidelines
-- **Avoid Type Assertions**: Replace `as any` with proper type guards and interfaces
+
+- **Avoid Type Assertions**:
+
+  Replace `as any` with proper type guards and interfaces
+
 - **Narrow Types Properly**: Use type guards to narrow `unknown` types safely
+
 - **Document Type Decisions**: Explain complex type structures and their purpose
 
 ## Minimal Special Cases (document in PR when used)
 
 - **Vue refs / instances**: Use `ComponentPublicInstance` or specific
+
   component types for dynamic refs.
+
 - **3rd‑party libs without types**: Narrow immediately to a **known
+
   interface**; do not leave `any` hanging.
 
 ## Patterns (short)
@@ -71,31 +102,38 @@ Practical rules to keep TypeScript strict and predictable. Minimize exceptions.
 ### Database errors
 
 ```ts
+
 try { await this.$addContact(contact); }
 catch (e: unknown) {
   if (isDatabaseError(e) && e.message.includes("Key already exists")) {
     /* handle duplicate */
   }
 }
+
 ```
 
 ### API errors
 
 ```ts
+
 try { await apiCall(); }
 catch (e: unknown) {
   if (isApiError(e)) {
     const msg = e.response?.data?.error?.message;
   }
 }
+
 ```
 
 ### Dynamic keys
 
 ```ts
+
 const keys = Object.keys(newSettings).filter(
-  k => k in newSettings && newSettings[k as keyof typeof newSettings] !== undefined
+k => k in newSettings && newSettings[k as keyof typeof newSettings] !==
+  undefined
 );
+
 ```
 
 ## Checklists
@@ -103,28 +141,38 @@ const keys = Object.keys(newSettings).filter(
 **Before commit**
 
 - [ ] No `any` (except documented, justified cases)
+
 - [ ] Errors handled via guards
+
 - [ ] Dynamic access uses `keyof`/`in`
+
 - [ ] Imports point to correct interfaces/types
 
 **Code review**
 
 - [ ] Hunt hidden `as any`
+
 - [ ] Guard‑based error paths verified
+
 - [ ] Dynamic ops are type‑safe
+
 - [ ] Prefer existing types over re‑inventing
 
 ## Tools
 
 - `npm run lint-fix` — lint & auto‑fix
+
 - `npm run type-check` — strict type compilation (CI + pre‑release)
+
 - IDE: enable strict TS, ESLint/TS ESLint, Volar (Vue 3)
 
 ## References
 
-- TS Handbook — https://www.typescriptlang.org/docs/
-- TS‑ESLint — https://typescript-eslint.io/rules/
-- Vue 3 + TS — https://vuejs.org/guide/typescript/
+- TS Handbook — <https://www.typescriptlang.org/docs/>
+
+- TS‑ESLint — <https://typescript-eslint.io/rules/>
+
+- Vue 3 + TS — <https://vuejs.org/guide/typescript/>
 
 ---
 
@@ -134,6 +182,31 @@ const keys = Object.keys(newSettings).filter(
 **Dependencies**: TypeScript, ESLint, Vue 3
 **Stakeholders**: Development team
 
-- TS Handbook — https://www.typescriptlang.org/docs/
-- TS‑ESLint — https://typescript-eslint.io/rules/
-- Vue 3 + TS — https://vuejs.org/guide/typescript/
+- TS Handbook — <https://www.typescriptlang.org/docs/>
+
+- TS‑ESLint — <https://typescript-eslint.io/rules/>
+
+- Vue 3 + TS — <https://vuejs.org/guide/typescript/>
+
+## Model Implementation Checklist
+
+### Before Type Implementation
+
+- [ ] **Type Analysis**: Understand current type definitions and usage
+- [ ] **Interface Review**: Review existing interfaces and types
+- [ ] **Error Handling**: Plan error handling with type guards
+- [ ] **Dynamic Access**: Identify dynamic access patterns that need type safety
+
+### During Type Implementation
+
+- [ ] **Type Safety**: Ensure types provide meaningful safety guarantees
+- [ ] **Error Guards**: Implement proper error handling with type guards
+- [ ] **Dynamic Operations**: Use `keyof`/`in` for dynamic access
+- [ ] **Import Validation**: Verify imports point to correct interfaces/types
+
+### After Type Implementation
+
+- [ ] **Linting Check**: Run `npm run lint-fix` to verify code quality
+- [ ] **Type Check**: Run `npm run type-check` for strict type compilation
+- [ ] **Code Review**: Hunt for hidden `as any` and type safety issues
+- [ ] **Documentation**: Update type documentation and examples

.cursor/rules/docs/documentation.mdc

@@ -1,14 +1,37 @@
 ---
-alwaysApply: true
+alwaysApply: false
 ---
 # Directive for Documentation Generation
 
 1. Produce a **small, focused set of documents** rather than an overwhelming volume.
 2. Ensure the content is **maintainable and worth preserving**, so that humans
-are motivated to keep it up to date.
+   are motivated to keep it up to date.
 3. Prioritize **educational value**: the documents must clearly explain the
-workings of the system.
-4. Avoid **shallow, generic, or filler explanations** often found in
-AI-generated documentation.
+   workings of the system.
+4. Avoid **shallow, generic, or filler explanations** often found in AI-generated
+   documentation.
 5. Aim for **clarity, depth, and usefulness**, so readers gain genuine understanding.
 6. Always check the local system date to determine current date.
+
+## Model Implementation Checklist
+
+### Before Documentation Creation
+
+- [ ] **Scope Definition**: Define what needs to be documented
+- [ ] **Audience Analysis**: Identify target readers and their needs
+- [ ] **Content Planning**: Plan focused, educational content structure
+- [ ] **Maintenance Planning**: Ensure content will be worth preserving
+
+### During Documentation Creation
+
+- [ ] **Educational Focus**: Clearly explain how the system works
+- [ ] **Depth and Clarity**: Provide genuine understanding, not surface explanations
+- [ ] **Focused Content**: Keep documents small and focused on specific topics
+- [ ] **Current Date**: Check local system date for time-sensitive content
+
+### After Documentation Creation
+
+- [ ] **Quality Review**: Ensure content is clear, deep, and useful
+- [ ] **Maintainability Check**: Verify content motivates humans to keep it updated
+- [ ] **Audience Validation**: Confirm content meets target reader needs
+- [ ] **Integration**: Integrate with existing documentation structure

.cursor/rules/docs/markdown-automation.mdc

@@ -1,79 +0,0 @@
----
-alwaysApply: true
----
-
-# Markdown Automation System
-
-**Author**: Matthew Raymer
-**Date**: 2025-08-20
-**Status**: 🎯 **ACTIVE** - Markdown formatting automation
-
-## Overview
-
-The Markdown Automation System ensures your markdown formatting standards are
-followed **during content generation** by AI agents, not just applied after the
-fact.
-
-## AI-First Approach
-
-### **Primary Method**: AI Agent Compliance
-
-- **AI agents follow markdown rules** while generating content
-- **No post-generation fixes needed** - content is compliant from creation
-- **Consistent formatting** across all generated documentation
-
-### **Secondary Method**: Automated Validation
-
-- **Pre-commit hooks** catch any remaining issues
-- **GitHub Actions** validate formatting before merge
-- **Manual tools** for bulk fixes when needed
-
-## How It Works
-
-### 1. **AI Agent Compliance** (Primary)
-
-- **When**: Every time AI generates markdown content
-- **What**: AI follows markdown rules during generation
-- **Result**: Content is properly formatted from creation
-
-### 2. **Pre-commit Hooks** (Backup)
-
-- **When**: Every time you commit
-- **What**: Catches any remaining formatting issues
-- **Result**: Clean, properly formatted markdown files
-
-### 3. **GitHub Actions** (Pre-merge)
-
-- **When**: Every pull request
-- **What**: Validates markdown formatting across all files
-- **Result**: Blocks merge if formatting issues exist
-
-## AI Agent Rules Integration
-
-The AI agent follows markdown rules defined in `.cursor/rules/docs/markdown.mdc`:
-
-- **alwaysApply: true** - Rules are enforced during generation
-- **Line Length**: AI never generates lines > 80 characters
-- **Blank Lines**: AI adds proper spacing around all elements
-- **Structure**: AI uses established templates and patterns
-
-## Available Commands
-
-### NPM Scripts
-
-- **`npm run markdown:setup`** - Install the automation system
-- **`npm run markdown:fix`** - Fix formatting in all markdown files
-- **`npm run markdown:check`** - Validate formatting without fixing
-
-## Benefits
-
-- **No more manual fixes** - AI generates compliant content from start
-- **Consistent style** - All files follow same standards
-- **Faster development** - No need to fix formatting manually
-
----
-
-**Status**: Active automation system
-**Priority**: High
-**Maintainer**: Development team
-**Next Review**: 2025-09-20

.cursor/rules/docs/markdown.mdc

@@ -1,366 +0,0 @@
----
-globs: ["*.md", "*.mdc"]
-alwaysApply: false
----
-# Cursor Markdown Ruleset for TimeSafari Documentation
-
-## Overview
-
-This ruleset enforces consistent markdown formatting standards across all project
-documentation, ensuring readability, maintainability, and compliance with
-markdownlint best practices.
-
-**⚠️ CRITICAL FOR AI AGENTS**: These rules must be followed DURING content
-generation, not applied after the fact. Always generate markdown that complies
-with these standards from the start.
-
-## AI Generation Guidelines
-
-### **MANDATORY**: Follow These Rules While Writing
-
-When generating markdown content, you MUST:
-
-1. **Line Length**: Never exceed 80 characters per line
-2. **Blank Lines**: Always add blank lines around headings, lists, and code
-   blocks
-3. **Structure**: Use proper heading hierarchy and document templates
-4. **Formatting**: Apply consistent formatting patterns immediately
-
-### **DO NOT**: Generate content that violates these rules
-
-- ❌ Generate long lines that need breaking
-- ❌ Create content without proper blank line spacing
-- ❌ Use inconsistent formatting patterns
-- ❌ Assume post-processing will fix violations
-
-### **DO**: Generate compliant content from the start
-
-- ✅ Write within 80-character limits
-- ✅ Add blank lines around all structural elements
-- ✅ Use established templates and patterns
-- ✅ Apply formatting standards immediately
-
-## General Formatting Standards
-
-### Line Length
-
-- **Maximum line length**: 80 characters
-- **Exception**: Code blocks (JSON, shell, TypeScript, etc.) - no line length
-  enforcement
-- **Rationale**: Ensures readability across different screen sizes and terminal
-  widths
-
-### Blank Lines
-
-- **Headings**: Must be surrounded by blank lines above and below
-- **Lists**: Must be surrounded by blank lines above and below
-- **Code blocks**: Must be surrounded by blank lines above and below
-- **Maximum consecutive blank lines**: 1 (no multiple blank lines)
-- **File start**: No blank lines at the beginning of the file
-- **File end**: Single newline character at the end
-
-### Whitespace
-
-- **No trailing spaces**: Remove all trailing whitespace from lines
-- **No tabs**: Use spaces for indentation
-- **Consistent indentation**: 2 spaces for list items and nested content
-
-## Heading Standards
-
-### Format
-
-- **Style**: ATX-style headings (`#`, `##`, `###`, etc.)
-- **Case**: Title case for general headings
-- **Code references**: Use backticks for file names and technical terms
-  - ✅ `### Current package.json Scripts`
-  - ❌ `### Current Package.json Scripts`
-
-### Hierarchy
-
-- **H1 (#)**: Document title only
-- **H2 (##)**: Major sections
-- **H3 (###)**: Subsections
-- **H4 (####)**: Sub-subsections
-- **H5+**: Avoid deeper nesting
-
-## List Standards
-
-### Unordered Lists
-
-- **Marker**: Use `-` (hyphen) consistently
-- **Indentation**: 2 spaces for nested items
-- **Blank lines**: Surround lists with blank lines
-
-### Ordered Lists
-
-- **Format**: `1.`, `2.`, `3.` (sequential numbering)
-- **Indentation**: 2 spaces for nested items
-- **Blank lines**: Surround lists with blank lines
-
-### Task Lists
-
-- **Format**: `- [ ]` for incomplete, `- [x]` for complete
-- **Use case**: Project planning, checklists, implementation tracking
-
-## Code Block Standards
-
-### Fenced Code Blocks
-
-- **Syntax**: Triple backticks with language specification
-- **Languages**: `json`, `bash`, `typescript`, `javascript`, `yaml`, `markdown`
-- **Blank lines**: Must be surrounded by blank lines above and below
-- **Line length**: No enforcement within code blocks
-
-### Inline Code
-
-- **Format**: Single backticks for inline code references
-- **Use case**: File names, commands, variables, properties
-
-## Special Content Standards
-
-### JSON Examples
-
-```json
-{
-  "property": "value",
-  "nested": {
-    "property": "value"
-  }
-}
-```
-
-### Shell Commands
-
-```bash
-# Command with comment
-npm run build:web
-
-# Multi-line command
-VITE_GIT_HASH=`git log -1 --pretty=format:%h` \
-  vite build --config vite.config.web.mts
-```
-
-### TypeScript Examples
-
-```typescript
-// Function with JSDoc
-/**
- * Get environment configuration
- * @param env - Environment name
- * @returns Environment config object
- */
-const getEnvironmentConfig = (env: string) => {
-  switch (env) {
-    case 'prod':
-      return { /* production settings */ };
-    default:
-      return { /* development settings */ };
-  }
-};
-```
-
-## File Structure Standards
-
-### Document Header
-
-```markdown
-# Document Title
-
-**Author**: Matthew Raymer
-**Date**: YYYY-MM-DD
-**Status**: 🎯 **STATUS** - Brief description
-
-## Overview
-
-Brief description of the document's purpose and scope.
-```
-
-### Section Organization
-
-1. **Overview/Introduction**
-2. **Current State Analysis**
-3. **Implementation Plan**
-4. **Technical Details**
-5. **Testing & Validation**
-6. **Next Steps**
-
-## Markdownlint Configuration
-
-### Required Rules
-
-```json
-{
-  "MD013": { "code_blocks": false },
-  "MD012": true,
-  "MD022": true,
-  "MD031": true,
-  "MD032": true,
-  "MD047": true,
-  "MD009": true
-}
-```
-
-### Rule Explanations
-
-- **MD013**: Line length (disabled for code blocks)
-- **MD012**: No multiple consecutive blank lines
-- **MD022**: Headings should be surrounded by blank lines
-- **MD031**: Fenced code blocks should be surrounded by blank lines
-- **MD032**: Lists should be surrounded by blank lines
-- **MD047**: Files should end with a single newline
-- **MD009**: No trailing spaces
-
-## Validation Commands
-
-### Check Single File
-
-```bash
-npx markdownlint docs/filename.md
-```
-
-### Check All Documentation
-
-```bash
-npx markdownlint docs/
-```
-
-### Auto-fix Common Issues
-
-```bash
-# Remove trailing spaces
-sed -i 's/[[:space:]]*$//' docs/filename.md
-
-# Remove multiple blank lines
-sed -i '/^$/N;/^\n$/D' docs/filename.md
-
-# Add newline at end if missing
-echo "" >> docs/filename.md
-```
-
-## Common Patterns
-
-### Implementation Plans
-
-```markdown
-## Implementation Plan
-
-### Phase 1: Foundation (Day 1)
-
-#### 1.1 Component Setup
-
-- [ ] Create new component file
-- [ ] Add basic structure
-- [ ] Implement core functionality
-
-#### 1.2 Configuration
-
-- [ ] Update configuration files
-- [ ] Add environment variables
-- [ ] Test configuration loading
-```
-
-### Status Tracking
-
-```markdown
-**Status**: ✅ **COMPLETE** - All phases finished
-**Progress**: 75% (15/20 components)
-**Next**: Ready for testing phase
-```
-
-### Performance Metrics
-
-```markdown
-#### 📊 Performance Metrics
-- **Build Time**: 2.3 seconds (50% faster than baseline)
-- **Bundle Size**: 1.2MB (30% reduction)
-- **Success Rate**: 100% (no failures in 50 builds)
-```
-
-## Enforcement
-
-### Pre-commit Hooks
-
-- Run markdownlint on all changed markdown files
-- Block commits with linting violations
-- Auto-fix common issues when possible
-
-### CI/CD Integration
-
-- Include markdownlint in build pipeline
-- Generate reports for documentation quality
-- Fail builds with critical violations
-
-### Team Guidelines
-
-- All documentation PRs must pass markdownlint
-- Use provided templates for new documents
-- Follow established patterns for consistency
-
-## Templates
-
-### New Document Template
-
-```markdown
-# Document Title
-
-**Author**: Matthew Raymer
-**Date**: YYYY-MM-DD
-**Status**: 🎯 **PLANNING** - Ready for Implementation
-
-## Overview
-
-Brief description of the document's purpose and scope.
-
-## Current State
-
-Description of current situation or problem.
-
-## Implementation Plan
-
-### Phase 1: Foundation
-
-- [ ] Task 1
-- [ ] Task 2
-
-## Next Steps
-
-1. **Review and approve plan**
-2. **Begin implementation**
-3. **Test and validate**
-
----
-
-**Status**: Ready for implementation
-**Priority**: Medium
-**Estimated Effort**: X days
-**Dependencies**: None
-**Stakeholders**: Development team
-```
-
----
-
-**Last Updated**: 2025-07-09
-**Version**: 1.0
-**Maintainer**: Matthew Raymer
-
-
-### Heading Uniqueness
-
-- **Rule**: No duplicate heading content at the same level
-- **Scope**: Within a single document
-- **Rationale**: Maintains clear document structure and navigation
-- **Example**:
-
-  ```markdown
-  ## Features        ✅
-  ### Authentication
-  ### Authorization
-
-  ## Features        ❌ (Duplicate heading)
-  ### Security
-  ### Performance
-  ```
-  ## Features        ❌ (Duplicate heading)
-  ### Security
-  ### Performance
-  ```

.cursor/rules/docs/markdown_core.mdc

@@ -0,0 +1,210 @@
+# Markdown Core Standards & Automation
+
+**Author**: Matthew Raymer
+**Date**: 2025-08-21
+**Status**: 🎯 **ACTIVE** - Core markdown standards and automation
+
+## Overview
+
+This file combines core markdown formatting standards with automation
+guidelines. AI agents must follow these rules DURING content generation,
+not apply them after the fact.
+
+**Primary Focus**: Create educational content that increases human
+competence, not just technical descriptions.
+
+## AI Generation Guidelines
+
+### **MANDATORY**: Follow These Rules While Writing
+
+When generating markdown content, you MUST:
+
+1. **Line Length**: Never exceed 80 characters per line
+2. **Blank Lines**: Always add blank lines around headings, lists, and
+   code blocks
+3. **Structure**: Use proper heading hierarchy and document templates
+4. **Formatting**: Apply consistent formatting patterns immediately
+5. **Educational Value**: Focus on increasing reader competence and
+   understanding
+
+### **DO NOT**: Generate content that violates these rules
+
+- ❌ Generate long lines that need breaking
+- ❌ Create content without proper blank line spacing
+- ❌ Use inconsistent formatting patterns
+- ❌ Assume post-processing will fix violations
+- ❌ Focus only on technical details without educational context
+- ❌ Assume reader has extensive prior knowledge
+
+### **DO**: Generate compliant content from the start
+
+- ✅ Write within 80-character limits
+- ✅ Add blank lines around all structural elements
+- ✅ Use established templates and patterns
+- ✅ Apply formatting standards immediately
+- ✅ Explain concepts before implementation details
+- ✅ Provide context and motivation for technical choices
+- ✅ Include examples that illustrate key concepts
+
+## Core Formatting Standards
+
+### Line Length
+
+- **Maximum line length**: 80 characters
+- **Exception**: Code blocks (JSON, shell, TypeScript, etc.) - no line
+  length enforcement
+- **Rationale**: Ensures readability across different screen sizes and
+  terminal widths
+
+### Blank Lines
+
+- **Headings**: Must be surrounded by blank lines above and below
+- **Lists**: Must be surrounded by blank lines above and below
+- **Code blocks**: Must be surrounded by blank lines above and below
+- **Maximum consecutive blank lines**: 1 (no multiple blank lines)
+- **File start**: No blank lines at the beginning of the file
+- **File end**: Single newline character at the end
+
+### Whitespace
+
+- **No trailing spaces**: Remove all trailing whitespace from lines
+- **No tabs**: Use spaces for indentation
+- **Consistent indentation**: 2 spaces for list items and nested content
+
+## Heading Standards
+
+### Format
+
+- **Style**: ATX-style headings (`#`, `##`, `###`, etc.)
+- **Case**: Title case for general headings
+- **Code references**: Use backticks for file names and technical terms
+  - ✅ `### Current package.json Scripts`
+  - ❌ `### Current Package.json Scripts`
+
+### Hierarchy
+
+- **H1 (#)**: Document title only
+- **H2 (##)**: Major sections
+- **H3 (###)**: Subsections
+- **H4 (####)**: Sub-subsections
+- **H5+**: Avoid deeper nesting
+
+## List Standards
+
+### Unordered Lists
+
+- **Marker**: Use `-` (hyphen) consistently
+- **Indentation**: 2 spaces for nested items
+- **Blank lines**: Surround lists with blank lines
+
+### Ordered Lists
+
+- **Format**: `1.`, `2.`, `3.` (sequential numbering)
+- **Indentation**: 2 spaces for nested items
+- **Blank lines**: Surround lists with blank lines
+
+### Task Lists
+
+- **Format**: `- [ ]` for incomplete, `- [x]` for complete
+- **Indentation**: 2 spaces for nested items
+- **Blank lines**: Surround lists with blank lines
+
+## Educational Content Standards
+
+### **Content Structure for Learning**
+
+- **Concept First**: Explain what something is before how to use it
+- **Context Matters**: Explain why and when to use a feature
+- **Progressive Disclosure**: Start simple, add complexity gradually
+- **Real Examples**: Use concrete, relatable scenarios
+- **Common Questions**: Anticipate and answer reader questions
+
+### **Writing for Understanding**
+
+- **Conversational Tone**: Write as if explaining to a colleague
+- **Active Voice**: "You can do this" not "This can be done"
+- **Question Format**: "What happens when..." to engage thinking
+- **Analogies**: Use familiar concepts to explain complex ideas
+- **Limitations**: Clearly state what solutions don't do
+
+## Code Block Standards
+
+### Inline Code
+
+- **Format**: Single backticks for inline code
+- **Use cases**: File names, commands, variables, technical terms
+- **Examples**: `package.json`, `npm run build`, `VITE_PLATFORM`
+
+### Code Blocks
+
+- **Format**: Triple backticks with language specification
+- **Language**: Always specify the language for syntax highlighting
+- **Blank lines**: Surround with blank lines above and below
+
+## Automation System
+
+### Available Commands
+
+- **`npm run markdown:fix`** - Fix formatting in all markdown files
+  using markdownlint-cli2 --fix
+- **`npm run markdown:check`** - Validate formatting without fixing
+  using markdownlint-cli2
+
+### How It Works
+
+1. **AI Agent Compliance** (Primary): AI follows markdown rules during
+   generation
+2. **Pre-commit Hooks** (Backup): Catches any remaining formatting
+   issues
+3. **GitHub Actions** (Pre-merge): Validates formatting before merge
+
+### Benefits
+
+- **No more manual fixes** - AI generates compliant content from start
+- **Consistent style** - All files follow same standards
+- **Faster development** - No need to fix formatting manually
+
+## Model Implementation Checklist
+
+### Before Generating Markdown Content
+
+- [ ] **Line Length**: Ensure no line exceeds 80 characters
+- [ ] **Blank Lines**: Add blank lines around headings, lists, and code blocks
+- [ ] **Whitespace**: Remove all trailing spaces, use 2-space indentation
+- [ ] **Headings**: Use ATX-style with proper hierarchy (H1 for title only)
+- [ ] **Lists**: Use consistent markers (- for unordered, 1. for ordered)
+- [ ] **Code**: Specify language for fenced blocks, use backticks for inline
+- [ ] **Educational Focus**: Plan content structure for learning progression
+- [ ] **Audience Consideration**: Identify target reader knowledge level
+
+### After Generating Markdown Content
+
+- [ ] **Validation**: Run `npm run markdown:check` to verify compliance
+- [ ] **Auto-fix**: Use `npm run markdown:fix` if any issues found
+- [ ] **Review**: Confirm content follows established templates and patterns
+- [ ] **Cross-reference**: Link to related documentation and templates
+- [ ] **Educational Review**: Verify content increases reader competence
+- [ ] **Example Validation**: Ensure examples illustrate key concepts clearly
+
+### Quality Assurance
+
+- [ ] **Readability**: Content is clear and follows project conventions
+- [ ] **Consistency**: Formatting matches existing documentation style
+- [ ] **Completeness**: All required sections and information included
+- [ ] **Accuracy**: Technical details are correct and up-to-date
+- [ ] **Educational Value**: Content increases reader understanding and competence
+- [ ] **Context Clarity**: Reader understands when and why to use the information
+
+---
+
+**See also**:
+
+- `.cursor/rules/meta_documentation.mdc` for comprehensive documentation workflow
+- `.cursor/rules/docs/markdown_templates.mdc` for document templates
+- `.cursor/rules/docs/markdown_workflow.mdc` for validation workflows
+
+**Status**: Active core standards and automation
+**Priority**: High
+**Estimated Effort**: Ongoing reference
+**Dependencies**: None
+**Stakeholders**: Documentation team, Development team

.cursor/rules/docs/markdown_templates.mdc

@@ -0,0 +1,314 @@
+# Markdown Templates & Examples
+
+> **Agent role**: Reference this file for document templates, structure,
+> and examples when creating new documentation.
+>
+> **Focus**: Create educational content that increases human competence,
+> not just technical descriptions.
+
+## Document Templates
+
+### Standard Document Template
+
+```markdown
+# Document Title
+
+**Author**: Matthew Raymer
+**Date**: YYYY-MM-DD
+**Status**: 🎯 **STATUS** - Brief description
+
+## Overview
+
+Brief description of the document's purpose and scope.
+
+**Educational Goal**: What will the reader learn and how will it increase
+their competence?
+
+## Current State
+
+Description of current situation or problem.
+
+**Why This Matters**: Explain the business value and user benefit of
+addressing this situation.
+
+## Implementation Plan
+
+### Phase 1: Foundation
+
+- [ ] Task 1
+- [ ] Task 2
+
+**Learning Context**: What concepts should the reader understand before
+proceeding with implementation?
+
+## Next Steps
+
+1. **Review and approve plan**
+2. **Begin implementation**
+3. **Test and validate**
+
+**Continued Learning**: Where can the reader go next to deepen their
+understanding?
+
+---
+
+**Status**: Ready for implementation
+**Priority**: Medium
+**Estimated Effort**: X days
+**Dependencies**: None
+**Stakeholders**: Development team
+```
+
+### Technical Specification Template
+
+```markdown
+# Technical Specification: [Feature Name]
+
+**Author**: Matthew Raymer
+**Date**: YYYY-MM-DD
+**Status**: 🎯 **DRAFT** - Under Review
+
+## Overview
+
+Brief description of the technical specification.
+
+**Business Context**: Why is this specification needed and what problem
+does it solve for users?
+
+## Requirements
+
+### Functional Requirements
+
+- [ ] Requirement 1
+- [ ] Requirement 2
+
+### Non-Functional Requirements
+
+- [ ] Performance requirement
+- [ ] Security requirement
+
+## Technical Design
+
+### Architecture
+
+Description of the technical architecture.
+
+**Design Rationale**: Why was this architecture chosen over alternatives?
+What are the trade-offs and benefits?
+
+### Data Models
+
+```typescript
+interface ExampleModel {
+  id: string;
+  name: string;
+  createdAt: Date;
+}
+```
+
+### API Design
+
+```typescript
+interface APIResponse<T> {
+  success: boolean;
+  data: T;
+  error?: string;
+}
+```
+
+## Testing Strategy
+
+- [ ] Unit tests
+
+**Learning from Testing**: What insights does testing provide about the
+system's behavior and design?
+
+---
+
+## Educational Documentation Template
+
+### **Concept Explanation Template**
+
+```markdown
+## What is [Concept Name]?
+
+Brief, clear definition of the concept.
+
+## Why Does [Concept Name] Matter?
+
+Explain the business value and user benefit.
+
+## How Does [Concept Name] Work?
+
+High-level explanation of the mechanism.
+
+## When Would You Use [Concept Name]?
+
+Real-world scenarios and use cases.
+
+## Common Misconceptions
+
+Address typical misunderstandings.
+
+## Examples
+
+Concrete examples that illustrate the concept.
+
+## Next Steps
+
+Where to learn more about related concepts.
+```
+
+### **Tutorial Template**
+
+```markdown
+## Learning Objective
+
+What the reader will accomplish by the end.
+
+## Prerequisites
+
+What the reader should know before starting.
+
+## Step-by-Step Guide
+
+1. **Step 1**: What to do and why
+2. **Step 2**: What to do and why
+3. **Step 3**: What to do and why
+
+## Verification
+
+How to confirm the tutorial was successful.
+
+## Troubleshooting
+
+Common issues and how to resolve them.
+
+## What You've Learned
+
+Summary of key concepts and skills.
+
+## Next Steps
+
+Where to apply this knowledge next.
+```
+- [ ] Integration tests
+- [ ] E2E tests
+
+---
+
+**Status**: Draft
+**Priority**: High
+**Estimated Effort**: X days
+**Dependencies**: None
+**Stakeholders**: Development team
+
+```
+
+## Content Examples
+
+### JSON Examples
+
+```json
+{
+  "property": "value",
+  "nested": {
+    "property": "value"
+  }
+}
+```
+
+### Shell Commands
+
+```bash
+# Command with comment
+npm run build:web
+
+# Multi-line command
+VITE_GIT_HASH=`git log -1 --pretty=format:%h` \
+  vite build --config vite.config.web.mts
+```
+
+### TypeScript Examples
+
+```typescript
+// Function with JSDoc
+const getEnvironmentConfig = (env: string) => {
+  switch (env) {
+    case 'prod':
+      return { /* production settings */ };
+    default:
+      return { /* development settings */ };
+  }
+};
+```
+
+## File Structure Standards
+
+### Document Header
+
+```markdown
+# Document Title
+
+**Author**: Matthew Raymer
+**Date**: YYYY-MM-DD
+**Status**: 🎯 **STATUS** - Brief description
+
+## Overview
+
+Brief description of the document's purpose and scope.
+```
+
+### Section Organization
+
+Standard sections: Overview, Current State, Implementation Plan,
+Technical Details, Testing & Validation, Next Steps
+
+## Common Patterns
+
+Standard implementation plans follow Phase 1 (Foundation), Phase 2
+(Features), Phase 3 (Testing & Polish) structure.
+
+## Model Implementation Checklist
+
+### Before Using Templates
+
+- [ ] **Template Selection**: Choose appropriate template for document type
+- [ ] **Structure Review**: Understand required sections and organization
+- [ ] **Content Planning**: Plan what information goes in each section
+- [ ] **Audience Analysis**: Ensure template matches target audience needs
+
+### During Template Usage
+
+- [ ] **Section Completion**: Fill in all required sections completely
+- [ ] **Example Integration**: Include relevant code examples and patterns
+- [ ] **Formatting Consistency**: Apply markdown standards from core rules
+- [ ] **Cross-references**: Link to related documentation and resources
+
+### After Template Usage
+
+- [ ] **Content Review**: Verify all sections contain appropriate content
+- [ ] **Formatting Check**: Run `npm run markdown:check` for compliance
+- [ ] **Template Validation**: Confirm document follows template structure
+- [ ] **Quality Assessment**: Ensure content meets project standards
+
+### Template-Specific Requirements
+
+- [ ] **Standard Documents**: Include all required metadata and sections
+- [ ] **Technical Specs**: Complete all requirement and design sections
+- [ ] **Implementation Plans**: Define clear phases and milestones
+- [ ] **Examples**: Provide relevant, working code examples
+
+---
+
+**See also**:
+
+- `.cursor/rules/meta_documentation.mdc` for comprehensive documentation workflow
+- `.cursor/rules/docs/markdown_core.mdc` for core formatting standards
+- `.cursor/rules/docs/markdown_workflow.mdc` for validation workflows
+
+**Status**: Active templates and examples
+**Priority**: Medium
+**Estimated Effort**: Ongoing reference
+**Dependencies**: markdown_core.mdc
+**Stakeholders**: Documentation team, Development team

.cursor/rules/docs/markdown_workflow.mdc

@@ -0,0 +1,168 @@
+# Markdown Workflow & Validation
+
+> **Agent role**: Reference this file for markdown validation rules,
+> enforcement procedures, and workflow management.
+
+## Markdownlint Configuration
+
+### Core Rules
+
+```json
+{
+  "MD013": { "line_length": 80, "code_blocks": false },
+  "MD012": true,
+  "MD022": true,
+  "MD031": true,
+  "MD032": true,
+  "MD047": true,
+  "MD009": true,
+  "MD004": { "style": "dash" }
+}
+```
+
+### Rule Explanations
+
+- **MD013**: Line length (80 chars, disabled for code blocks)
+- **MD012**: No multiple consecutive blank lines
+- **MD022**: Headings should be surrounded by blank lines
+- **MD031**: Fenced code blocks should be surrounded by blank lines
+- **MD032**: Lists should be surrounded by blank lines
+- **MD047**: Files should end with a single newline
+- **MD009**: No trailing spaces
+- **MD004**: Consistent list markers (dash style)
+
+## Validation Commands
+
+### Check All MDC Files
+
+```bash
+npm run markdown:check
+```
+
+### Auto-fix Formatting Issues
+
+```bash
+npm run markdown:fix
+```
+
+### Check Single File
+
+```bash
+npx markdownlint-cli2 .cursor/rules/filename.mdc
+```
+
+## Enforcement Workflow
+
+### Pre-commit Hooks
+
+- **Automatic**: `lint-staged` runs `markdownlint-cli2 --fix` on all
+  staged `.mdc` files
+- **Result**: Files are automatically formatted before commit
+- **Blocking**: Commits with unfixable violations are blocked
+
+### CI/CD Integration
+
+- **Build Pipeline**: Include markdownlint in automated builds
+- **Quality Reports**: Generate documentation quality metrics
+- **Build Failure**: Fail builds with critical violations
+
+### Team Guidelines
+
+- **PR Requirements**: All documentation PRs must pass markdownlint
+- **Templates**: Use provided templates for new documents
+- **Patterns**: Follow established patterns for consistency
+- **Auto-fixing**: Let automation handle formatting, focus on content
+
+## Quality Assurance
+
+### Validation Checklist
+
+- [ ] All files pass `npm run markdown:check`
+- [ ] Line length under 80 characters
+- [ ] Proper blank line spacing around elements
+- [ ] No trailing spaces
+- [ ] Consistent list markers
+- [ ] Proper heading hierarchy
+- [ ] Code blocks have language specification
+
+### Common Issues & Fixes
+
+#### Trailing Spaces
+
+```bash
+# Remove trailing spaces
+sed -i 's/[[:space:]]*$//' .cursor/rules/**/*.mdc
+```
+
+#### Multiple Blank Lines
+
+```bash
+# Remove multiple blank lines
+sed -i '/^$/N;/^\n$/D' .cursor/rules/**/*.mdc
+```
+
+#### Missing Newlines
+
+```bash
+# Add newline at end if missing
+find .cursor/rules -name "*.mdc" -exec sed -i -e '$a\' {} \;
+```
+
+## Integration Points
+
+### Git Workflow
+
+1. **Edit**: Make changes to MDC files
+2. **Stage**: `git add .cursor/rules/filename.mdc`
+3. **Auto-fix**: `lint-staged` runs `markdownlint-cli2 --fix`
+4. **Commit**: Changes are committed with perfect formatting
+
+### Development Workflow
+
+1. **Create/Edit**: Use templates from `markdown_templates.mdc`
+2. **Validate**: Run `npm run markdown:check` before committing
+3. **Auto-fix**: Use `npm run markdown:fix` for bulk fixes
+4. **Review**: Ensure content quality, not just formatting
+
+## Model Implementation Checklist
+
+### Before Starting Workflow
+
+- [ ] **Configuration Review**: Understand markdownlint rules and settings
+- [ ] **Tool Availability**: Ensure markdownlint-cli2 is installed and working
+- [ ] **File Scope**: Identify which files need validation or fixing
+- [ ] **Backup Strategy**: Consider backing up files before bulk operations
+
+### During Workflow Execution
+
+- [ ] **Validation First**: Run `npm run markdown:check` to identify issues
+- [ ] **Issue Analysis**: Review and understand each validation error
+- [ ] **Auto-fix Application**: Use `npm run markdown:fix` for automatic fixes
+- [ ] **Manual Review**: Check files that couldn't be auto-fixed
+
+### After Workflow Completion
+
+- [ ] **Final Validation**: Confirm all files pass `npm run markdown:check`
+- [ ] **Quality Review**: Verify formatting meets project standards
+- [ ] **Documentation Update**: Update any related documentation or guides
+- [ ] **Team Communication**: Share workflow results and any manual fixes needed
+
+### Workflow-Specific Requirements
+
+- [ ] **Pre-commit Hooks**: Ensure lint-staged configuration is working
+- [ ] **CI/CD Integration**: Verify build pipeline includes markdown validation
+- [ ] **Team Guidelines**: Confirm all team members understand the workflow
+- [ ] **Error Resolution**: Document common issues and their solutions
+
+---
+
+**See also**:
+
+- `.cursor/rules/docs/markdown_core.mdc` for core formatting standards
+- `.cursor/rules/docs/markdown_templates.mdc` for document templates
+
+**Status**: Active workflow and validation
+**Priority**: Medium
+**Estimated Effort**: Ongoing reference
+**Dependencies**: markdown_core.mdc, markdown_templates.mdc
+**Stakeholders**: Development team, Documentation team

.cursor/rules/features/camera-implementation.mdc

@@ -1,7 +1,3 @@
----
-description: when dealing with cameras in the application
-alwaysApply: false
----
 # Camera Implementation Documentation
 
 ## Overview
@@ -10,6 +6,7 @@ This document describes how camera functionality is implemented across the
 TimeSafari application. The application uses cameras for two main purposes:
 
 1. QR Code scanning
+
 2. Photo capture
 
 ## Components
@@ -21,17 +18,25 @@ Primary component for QR code scanning in web browsers.
 **Key Features:**
 
 - Uses `qrcode-stream` for web-based QR scanning
+
 - Supports both front and back cameras
+
 - Provides real-time camera status feedback
+
 - Implements error handling with user-friendly messages
+
 - Includes camera switching functionality
 
 **Camera Access Flow:**
 
 1. Checks for camera API availability
+
 2. Enumerates available video devices
+
 3. Requests camera permissions
+
 4. Initializes camera stream with preferred settings
+
 5. Handles various error conditions with specific messages
 
 ### PhotoDialog.vue
@@ -41,8 +46,11 @@ Component for photo capture and selection.
 **Key Features:**
 
 - Cross-platform photo capture interface
+
 - Image cropping capabilities
+
 - File selection fallback
+
 - Unified interface for different platforms
 
 ## Services
@@ -56,8 +64,11 @@ Web-based implementation of QR scanning.
 **Key Methods:**
 
 - `checkPermissions()`: Verifies camera permission status
+
 - `requestPermissions()`: Requests camera access
+
 - `isSupported()`: Checks for camera API support
+
 - Handles various error conditions with specific messages
 
 #### CapacitorQRScanner
@@ -67,8 +78,11 @@ Native implementation using Capacitor's MLKit.
 **Key Features:**
 
 - Uses `@capacitor-mlkit/barcode-scanning`
+
 - Supports both front and back cameras
+
 - Implements permission management
+
 - Provides continuous scanning capability
 
 ### Platform Services
@@ -80,7 +94,9 @@ Web-specific implementation of platform features.
 **Camera Capabilities:**
 
 - Uses HTML5 file input with capture attribute
+
 - Falls back to file selection if camera unavailable
+
 - Processes captured images for consistent format
 
 #### CapacitorPlatformService
@@ -90,133 +106,58 @@ Native implementation using Capacitor.
 **Camera Features:**
 
 - Uses `Camera.getPhoto()` for native camera access
+
 - Supports image editing
+
 - Configures high-quality image capture
+
 - Handles base64 image processing
 
 #### ElectronPlatformService
 
 Desktop implementation (currently unimplemented).
 
-**Status:**
+---
 
-- Camera functionality not yet implemented
-- Planned to use Electron's media APIs
+**See also**:
 
-## Platform-Specific Considerations
+- `.cursor/rules/features/camera_technical.mdc` for
 
-### iOS
+  detailed technical implementation
 
-- Requires `NSCameraUsageDescription` in Info.plist
-- Supports both front and back cameras
-- Implements proper permission handling
+- `.cursor/rules/features/camera_platforms.mdc` for platform-specific details
 
-### Android
+**Status**: Active camera implementation overview
+**Priority**: Medium
+**Estimated Effort**: Ongoing reference
+**Dependencies**: None
+**Stakeholders**: Development team, Camera feature team
 
-- Requires camera permissions in manifest
-- Supports both front and back cameras
-- Handles permission requests through Capacitor
-
-### Web
-
-- Requires HTTPS for camera access
-- Implements fallback mechanisms
-- Handles browser compatibility issues
-
-## Error Handling
-
-### Common Error Scenarios
-
-1. No camera found
-2. Permission denied
-3. Camera in use by another application
-4. HTTPS required
-5. Browser compatibility issues
-
-### Error Response
-
-- User-friendly error messages
-- Troubleshooting tips
-- Clear instructions for resolution
-- Platform-specific guidance
-
-## Security Considerations
-
-### Permission Management
-
-- Explicit permission requests
-- Permission state tracking
-- Graceful handling of denied permissions
-
-### Data Handling
-
-- Secure image processing
-- Proper cleanup of camera resources
-- No persistent storage of camera data
-
-## Best Practices
-
-### Camera Access
-
-1. Always check for camera availability
-2. Request permissions explicitly
-3. Handle all error conditions
-4. Provide clear user feedback
-5. Implement proper cleanup
-
-### Performance
-
-1. Optimize camera resolution
-2. Implement proper resource cleanup
-3. Handle camera switching efficiently
-4. Manage memory usage
-
-### User Experience
-
-1. Clear status indicators
-2. Intuitive camera controls
-3. Helpful error messages
-4. Smooth camera switching
-5. Responsive UI feedback
-
-## Future Improvements
-
-### Planned Enhancements
-
-1. Implement Electron camera support
-2. Add advanced camera features
-3. Improve error handling
-4. Enhance user feedback
-5. Optimize performance
-
-### Known Issues
-
-1. Electron camera implementation pending
-2. Some browser compatibility limitations
-3. Platform-specific quirks to address
-
-## Dependencies
-
-### Key Packages
-
-- `@capacitor-mlkit/barcode-scanning`
-- `qrcode-stream`
-- `vue-picture-cropper`
-- Platform-specific camera APIs
-
-## Testing
-
-### Test Scenarios
-
-1. Permission handling
-2. Camera switching
-3. Error conditions
-4. Platform compatibility
-5. Performance metrics
-
-### Test Environment
-
-- Multiple browsers
 - iOS and Android devices
+
 - Desktop platforms
+
 - Various network conditions
+
+## Model Implementation Checklist
+
+### Before Camera Implementation
+
+- [ ] **Platform Analysis**: Understand camera requirements across all platforms
+- [ ] **Feature Planning**: Plan QR scanning and photo capture features
+- [ ] **Service Planning**: Plan camera service architecture
+- [ ] **Testing Strategy**: Plan testing across web, mobile, and desktop
+
+### During Camera Implementation
+
+- [ ] **Component Development**: Implement QRScannerDialog and PhotoDialog
+- [ ] **Service Implementation**: Implement platform-specific camera services
+- [ ] **Permission Handling**: Implement proper camera permission management
+- [ ] **Error Handling**: Implement graceful error handling for camera failures
+
+### After Camera Implementation
+
+- [ ] **Cross-Platform Testing**: Test camera functionality across all platforms
+- [ ] **Feature Validation**: Verify QR scanning and photo capture work correctly
+- [ ] **Performance Testing**: Ensure camera performance meets requirements
+- [ ] **Documentation Update**: Update camera implementation documentation

.cursor/rules/features/camera_platforms.mdc

@@ -0,0 +1,225 @@
+# Camera Platform-Specific Implementation
+
+> **Agent role**:
+  Reference this file for platform-specific camera implementation details.
+
+## Web Platform
+
+### Implementation Details
+
+- Uses `getUserMedia` API for camera access
+
+- Implements fallback to file input if camera unavailable
+
+- Handles browser compatibility issues
+
+- Requires HTTPS for camera access
+
+### Browser Support
+
+- Chrome: Full support
+
+- Firefox: Full support
+
+- Safari: Limited support
+
+- Edge: Full support
+
+### Fallback Mechanisms
+
+1. Camera access via getUserMedia
+
+2. File input for image upload
+
+3. Drag and drop support
+
+4. Clipboard paste support
+
+## Mobile Platform (Capacitor)
+
+### iOS Implementation
+
+- Uses `@capacitor-mlkit/barcode-scanning`
+
+- Implements proper permission handling
+
+- Supports both front and back cameras
+
+- Handles camera switching
+
+### Android Implementation
+
+- Uses `@capacitor-mlkit/barcode-scanning`
+
+- Implements proper permission handling
+
+- Supports both front and back cameras
+
+- Handles camera switching
+
+### Permission Handling
+
+- Camera permissions requested at runtime
+
+- Permission state tracked and cached
+
+- Graceful handling of denied permissions
+
+- Clear user guidance for enabling permissions
+
+## Desktop Platform (Electron)
+
+### Current Status
+
+- Camera implementation pending
+
+- Will use platform-specific APIs
+
+- Requires proper permission handling
+
+- Will support both built-in and external cameras
+
+### Planned Implementation
+
+- Native camera access via Electron
+
+- Platform-specific camera APIs
+
+- Proper permission handling
+
+- Camera switching support
+
+## Platform Detection
+
+### Implementation
+
+- Uses `PlatformServiceFactory` for platform detection
+
+- Implements platform-specific camera services
+
+- Handles platform-specific error conditions
+
+- Provides platform-specific user guidance
+
+### Service Selection
+
+- Web: `WebPlatformService`
+
+- Mobile: `CapacitorPlatformService`
+
+- Desktop: `ElectronPlatformService`
+
+## Cross-Platform Compatibility
+
+### Common Interface
+
+- Unified camera service interface
+
+- Platform-specific implementations
+
+- Consistent error handling
+
+- Unified user experience
+
+### Feature Parity
+
+- Core camera functionality across platforms
+
+- Platform-specific optimizations
+
+- Consistent user interface
+
+- Unified error messages
+
+## Platform-Specific Features
+
+### Web
+
+- Browser-based camera access
+
+- File upload fallback
+
+- Drag and drop support
+
+- Clipboard paste support
+
+### Mobile
+
+- Native camera access
+
+- Barcode scanning
+
+- Photo capture
+
+- Camera switching
+
+### Desktop
+
+- Native camera access (planned)
+
+- External camera support (planned)
+
+- Advanced camera controls (planned)
+
+## Testing Strategy
+
+### Platform Coverage
+
+- Web: Multiple browsers
+
+- Mobile: iOS and Android devices
+
+- Desktop: Windows, macOS, Linux
+
+### Test Scenarios
+
+- Permission handling
+
+- Camera access
+
+- Error conditions
+
+- Platform compatibility
+
+- Performance metrics
+
+---
+
+**See also**:
+
+- `.cursor/rules/features/camera-implementation.mdc` for
+
+  core implementation overview
+
+- `.cursor/rules/features/camera_technical.mdc` for
+
+  technical implementation details
+
+**Status**: Active platform-specific implementation guide
+**Priority**: Medium
+**Estimated Effort**: Ongoing reference
+**Dependencies**: camera-implementation.mdc
+**Stakeholders**: Development team, Platform team
+
+## Model Implementation Checklist
+
+### Before Camera Platform Implementation
+
+- [ ] **Platform Analysis**: Identify target platforms and their camera capabilities
+- [ ] **Feature Planning**: Plan platform-specific camera features
+- [ ] **Integration Planning**: Plan integration with existing camera systems
+- [ ] **Testing Strategy**: Plan testing across all target platforms
+
+### During Camera Platform Implementation
+
+- [ ] **Platform Services**: Implement platform-specific camera functionality
+- [ ] **Feature Development**: Implement planned camera features for each platform
+- [ ] **Integration**: Integrate with existing camera infrastructure
+- [ ] **Performance Optimization**: Optimize camera performance for each platform
+
+### After Camera Platform Implementation
+
+- [ ] **Cross-Platform Testing**: Test camera functionality across all platforms
+- [ ] **Feature Validation**: Verify all planned features work correctly
+- [ ] **Performance Testing**: Ensure camera performance meets requirements
+- [ ] **Documentation Update**: Update platform-specific camera documentation

.cursor/rules/features/camera_technical.mdc

@@ -0,0 +1,203 @@
+# Camera Technical Implementation — Details and Best Practices
+
+> **Agent role**: Reference this file for
+  detailed technical implementation when working with camera features.
+
+## Platform-Specific Considerations
+
+### iOS
+
+- Requires `NSCameraUsageDescription` in Info.plist
+
+- Supports both front and back cameras
+
+- Implements proper permission handling
+
+### Android
+
+- Requires camera permissions in manifest
+
+- Supports both front and back cameras
+
+- Handles permission requests through Capacitor
+
+### Web
+
+- Requires HTTPS for camera access
+
+- Implements fallback mechanisms
+
+- Handles browser compatibility issues
+
+## Error Handling
+
+### Common Error Scenarios
+
+1. No camera found
+
+2. Permission denied
+
+3. Camera in use by another application
+
+4. HTTPS required
+
+5. Browser compatibility issues
+
+### Error Response
+
+- User-friendly error messages
+
+- Troubleshooting tips
+
+- Clear instructions for resolution
+
+- Platform-specific guidance
+
+## Security Considerations
+
+### Permission Management
+
+- Explicit permission requests
+
+- Permission state tracking
+
+- Graceful handling of denied permissions
+
+### Data Handling
+
+- Secure image processing
+
+- Proper cleanup of camera resources
+
+- No persistent storage of camera data
+
+## Best Practices
+
+### Camera Access
+
+1. Always check for camera availability
+
+2. Request permissions explicitly
+
+3. Handle all error conditions
+
+4. Provide clear user feedback
+
+5. Implement proper cleanup
+
+### Performance
+
+1. Optimize camera resolution
+
+2. Implement proper resource cleanup
+
+3. Handle camera switching efficiently
+
+4. Manage memory usage
+
+### User Experience
+
+1. Clear status indicators
+
+2. Intuitive camera controls
+
+3. Helpful error messages
+
+4. Smooth camera switching
+
+5. Responsive UI feedback
+
+## Future Improvements
+
+### Planned Enhancements
+
+1. Implement Electron camera support
+
+2. Add advanced camera features
+
+3. Improve error handling
+
+4. Enhance user feedback
+
+5. Optimize performance
+
+### Known Issues
+
+1. Electron camera implementation pending
+
+2. Some browser compatibility limitations
+
+3. Platform-specific quirks to address
+
+## Dependencies
+
+### Key Packages
+
+- `@capacitor-mlkit/barcode-scanning`
+
+- `qrcode-stream`
+
+- `vue-picture-cropper`
+
+- Platform-specific camera APIs
+
+## Testing
+
+### Test Scenarios
+
+1. Permission handling
+
+2. Camera switching
+
+3. Error conditions
+
+4. Platform compatibility
+
+5. Performance metrics
+
+### Test Environment
+
+- Multiple browsers
+
+- iOS and Android devices
+
+- Desktop platforms
+
+---
+
+**See also**:
+
+- `.cursor/rules/features/camera-implementation.mdc` for
+
+  core implementation overview
+
+- `.cursor/rules/features/camera_platforms.mdc` for platform-specific details
+
+**Status**: Active technical implementation guide
+**Priority**: Medium
+**Estimated Effort**: Ongoing reference
+**Dependencies**: camera-implementation.mdc
+**Stakeholders**: Development team, Camera feature team
+
+## Model Implementation Checklist
+
+### Before Camera Implementation
+
+- [ ] **Platform Analysis**: Identify target platforms and camera capabilities
+- [ ] **Permission Planning**: Plan permission handling for camera access
+- [ ] **Dependency Review**: Review required camera packages and APIs
+- [ ] **Testing Strategy**: Plan testing across multiple platforms
+
+### During Camera Implementation
+
+- [ ] **Platform Services**: Implement platform-specific camera services
+- [ ] **Permission Handling**: Implement proper camera permission handling
+- [ ] **Error Handling**: Implement graceful error handling for camera failures
+- [ ] **Performance Optimization**: Optimize camera performance and responsiveness
+
+### After Camera Implementation
+
+- [ ] **Cross-Platform Testing**: Test camera functionality across all platforms
+- [ ] **Permission Testing**: Test permission handling and user feedback
+- [ ] **Performance Validation**: Verify camera performance meets requirements
+- [ ] **Documentation Update**: Update camera technical documentation

.cursor/rules/harbor_pilot_universal.mdc

@@ -1,6 +1,5 @@
 ---
-alwaysApply: true
-inherits: base_context.mdc
+alwaysApply: false
 ---
 ```json
 {

.cursor/rules/historical_comment_management.mdc

@@ -1,236 +0,0 @@
----
-description: when comments are generated by the model
-alwaysApply: false
----
-# Historical Comment Management — Harbor Pilot Directive
-
-> **Agent role**: When encountering historical comments about removed methods, deprecated patterns, or architectural changes, apply these guidelines to maintain code clarity and developer guidance.
-
-## 🎯 Purpose
-
-Historical comments should either be **removed entirely** or **transformed into actionable guidance** for future developers. Avoid keeping comments that merely state what was removed without explaining why or what to do instead.
-
-## 📋 Decision Framework
-
-### Remove Historical Comments When:
-- **Obsolete Information**: Comment describes functionality that no longer exists
-- **No Action Required**: Comment doesn't help future developers make decisions
-- **Outdated Context**: Comment refers to old patterns that are no longer relevant
-- **Self-Evident**: The current code clearly shows the current approach
-
-### Transform Historical Comments When:
-- **Architectural Context**: The change represents a significant pattern shift
-- **Migration Guidance**: Future developers might need to understand the evolution
-- **Decision Rationale**: The "why" behind the change is still relevant
-- **Alternative Approaches**: The comment can guide future implementation choices
-
-## 🔄 Transformation Patterns
-
-### 1. From Removal Notice to Migration Note
-```typescript
-// ❌ REMOVE THIS
-// turnOffNotifyingFlags method removed - notification state is now managed by NotificationSection component
-
-// ✅ TRANSFORM TO THIS
-// Note: Notification state management has been migrated to NotificationSection component
-// which handles its own lifecycle and persistence via PlatformServiceMixin
-```
-
-### 2. From Deprecation Notice to Implementation Guide
-```typescript
-// ❌ REMOVE THIS
-// This will be handled by the NewComponent now
-// No need to call oldMethod() as it's no longer needed
-
-// ✅ TRANSFORM TO THIS
-// Note: This functionality has been migrated to NewComponent
-// which provides better separation of concerns and testability
-```
-
-### 3. From Historical Note to Architectural Context
-```typescript
-// ❌ REMOVE THIS
-// Old approach: used direct database calls
-// New approach: uses service layer
-
-// ✅ TRANSFORM TO THIS
-// Note: Database access has been abstracted through service layer
-// for better testability and platform independence
-```
-
-## 🚫 Anti-Patterns to Remove
-
-- Comments that only state what was removed
-- Comments that don't explain the current approach
-- Comments that reference non-existent methods
-- Comments that are self-evident from the code
-- Comments that don't help future decision-making
-
-## ✅ Best Practices
-
-### When Keeping Historical Context:
-1. **Explain the "Why"**: Why was the change made?
-2. **Describe the "What"**: What is the current approach?
-3. **Provide Context**: When might this information be useful?
-4. **Use Actionable Language**: Guide future decisions, not just document history
-
-### When Removing Historical Context:
-1. **Verify Obsoleteness**: Ensure the information is truly outdated
-2. **Check for Dependencies**: Ensure no other code references the old approach
-3. **Update Related Docs**: If removing from code, consider adding to documentation
-4. **Preserve in Git History**: The change is preserved in version control
-
-## 🔍 Implementation Checklist
-
-- [ ] Identify historical comments about removed/deprecated functionality
-- [ ] Determine if comment provides actionable guidance
-- [ ] Transform useful comments into migration notes or architectural context
-- [ ] Remove comments that are purely historical without guidance value
-- [ ] Ensure remaining comments explain current approach and rationale
-- [ ] Update related documentation if significant context is removed
-
-## 📚 Examples
-
-### Good Historical Comment (Keep & Transform)
-```typescript
-// Note: Database access has been migrated from direct IndexedDB calls to PlatformServiceMixin
-// This provides better platform abstraction and consistent error handling across web/mobile/desktop
-// When adding new database operations, use this.$getContact(), this.$saveSettings(), etc.
-```
-
-### Bad Historical Comment (Remove)
-```typescript
-// Old method getContactFromDB() removed - now handled by PlatformServiceMixin
-// No need to call the old method anymore
-```
-
-## 🎯 Integration with Harbor Pilot
-
-This rule works in conjunction with:
-- **Component Creation Ideals**: Maintains architectural consistency
-- **Migration Patterns**: Documents evolution of patterns
-- **Code Review Guidelines**: Ensures comments provide value
-
-## 📝 Version History
-
-### v1.0.0 (2025-08-21)
-- Initial creation based on notification system cleanup
-- Established decision framework for historical comment management
-- Added transformation patterns and anti-patterns
-- Integrated with existing Harbor Pilot architecture rules
-# Historical Comment Management — Harbor Pilot Directive
-
-> **Agent role**: When encountering historical comments about removed methods, deprecated patterns, or architectural changes, apply these guidelines to maintain code clarity and developer guidance.
-
-## 🎯 Purpose
-
-Historical comments should either be **removed entirely** or **transformed into actionable guidance** for future developers. Avoid keeping comments that merely state what was removed without explaining why or what to do instead.
-
-## 📋 Decision Framework
-
-### Remove Historical Comments When:
-- **Obsolete Information**: Comment describes functionality that no longer exists
-- **No Action Required**: Comment doesn't help future developers make decisions
-- **Outdated Context**: Comment refers to old patterns that are no longer relevant
-- **Self-Evident**: The current code clearly shows the current approach
-
-### Transform Historical Comments When:
-- **Architectural Context**: The change represents a significant pattern shift
-- **Migration Guidance**: Future developers might need to understand the evolution
-- **Decision Rationale**: The "why" behind the change is still relevant
-- **Alternative Approaches**: The comment can guide future implementation choices
-
-## 🔄 Transformation Patterns
-
-### 1. From Removal Notice to Migration Note
-```typescript
-// ❌ REMOVE THIS
-// turnOffNotifyingFlags method removed - notification state is now managed by NotificationSection component
-
-// ✅ TRANSFORM TO THIS
-// Note: Notification state management has been migrated to NotificationSection component
-// which handles its own lifecycle and persistence via PlatformServiceMixin
-```
-
-### 2. From Deprecation Notice to Implementation Guide
-```typescript
-// ❌ REMOVE THIS
-// This will be handled by the NewComponent now
-// No need to call oldMethod() as it's no longer needed
-
-// ✅ TRANSFORM TO THIS
-// Note: This functionality has been migrated to NewComponent
-// which provides better separation of concerns and testability
-```
-
-### 3. From Historical Note to Architectural Context
-```typescript
-// ❌ REMOVE THIS
-// Old approach: used direct database calls
-// New approach: uses service layer
-
-// ✅ TRANSFORM TO THIS
-// Note: Database access has been abstracted through service layer
-// for better testability and platform independence
-```
-
-## 🚫 Anti-Patterns to Remove
-
-- Comments that only state what was removed
-- Comments that don't explain the current approach
-- Comments that reference non-existent methods
-- Comments that are self-evident from the code
-- Comments that don't help future decision-making
-
-## ✅ Best Practices
-
-### When Keeping Historical Context:
-1. **Explain the "Why"**: Why was the change made?
-2. **Describe the "What"**: What is the current approach?
-3. **Provide Context**: When might this information be useful?
-4. **Use Actionable Language**: Guide future decisions, not just document history
-
-### When Removing Historical Context:
-1. **Verify Obsoleteness**: Ensure the information is truly outdated
-2. **Check for Dependencies**: Ensure no other code references the old approach
-3. **Update Related Docs**: If removing from code, consider adding to documentation
-4. **Preserve in Git History**: The change is preserved in version control
-
-## 🔍 Implementation Checklist
-
-- [ ] Identify historical comments about removed/deprecated functionality
-- [ ] Determine if comment provides actionable guidance
-- [ ] Transform useful comments into migration notes or architectural context
-- [ ] Remove comments that are purely historical without guidance value
-- [ ] Ensure remaining comments explain current approach and rationale
-- [ ] Update related documentation if significant context is removed
-
-## 📚 Examples
-
-### Good Historical Comment (Keep & Transform)
-```typescript
-// Note: Database access has been migrated from direct IndexedDB calls to PlatformServiceMixin
-// This provides better platform abstraction and consistent error handling across web/mobile/desktop
-// When adding new database operations, use this.$getContact(), this.$saveSettings(), etc.
-```
-
-### Bad Historical Comment (Remove)
-```typescript
-// Old method getContactFromDB() removed - now handled by PlatformServiceMixin
-// No need to call the old method anymore
-```
-
-## 🎯 Integration with Harbor Pilot
-
-This rule works in conjunction with:
-- **Component Creation Ideals**: Maintains architectural consistency
-- **Migration Patterns**: Documents evolution of patterns
-- **Code Review Guidelines**: Ensures comments provide value
-
-## 📝 Version History
-
-### v1.0.0 (2025-08-21)
-- Initial creation based on notification system cleanup
-- Established decision framework for historical comment management
-- Added transformation patterns and anti-patterns
-- Integrated with existing Harbor Pilot architecture rules

.cursor/rules/meta_bug_diagnosis.mdc

@@ -0,0 +1,288 @@
+# Meta-Rule: Bug Diagnosis Workflow
+
+**Author**: Matthew Raymer
+**Date**: August 24, 2025
+**Status**: 🎯 **ACTIVE** - Core workflow for all bug investigation
+
+## Purpose
+
+This meta-rule defines the systematic approach for investigating and diagnosing
+bugs, defects, and unexpected behaviors in the TimeSafari application. It ensures
+consistent, thorough, and efficient problem-solving workflows.
+
+## Workflow Constraints
+
+**This meta-rule enforces DIAGNOSIS MODE for all bundled sub-rules:**
+
+```json
+{
+  "workflowMode": "diagnosis",
+  "constraints": {
+    "mode": "read_only",
+    "forbidden": ["modify", "create", "build", "commit"],
+    "required": "complete_investigation_before_fixing"
+  }
+}
+```
+
+**All bundled sub-rules automatically inherit these constraints.**
+
+## Workflow State Update
+
+**When this meta-rule is invoked, update the workflow state file:**
+
+```json
+{
+  "currentMode": "diagnosis",
+  "lastInvoked": "meta_bug_diagnosis.mdc",
+  "timestamp": "2025-01-27T15:30:00Z",
+  "constraints": {
+    "mode": "read_only",
+    "forbidden": ["modify", "create", "build", "commit"],
+    "allowed": ["read", "search", "analyze", "document"],
+    "required": "complete_investigation_before_fixing"
+  }
+}
+```
+
+**State File Location**: `.cursor/rules/.workflow_state.json`
+
+**This enables the core always-on rule to enforce diagnosis mode constraints.**
+
+## When to Use
+
+**ALWAYS** - Apply this workflow to every bug investigation, regardless of
+severity or complexity. This ensures systematic problem-solving and prevents
+common investigation pitfalls.
+
+## Bundled Rules
+
+### **Investigation Foundation**
+
+- **`development/research_diagnostic.mdc`** - Research and investigation methodologies
+- **`development/logging_standards.mdc`** - Logging and debugging best practices
+- **`development/type_safety_guide.mdc`** - Type safety and error prevention
+
+### **Development Workflow**
+
+- **`workflow/version_control.mdc`** - Version control during investigation
+- **`development/software_development.mdc`** - Development best practices
+
+## Critical Development Constraints
+
+### **🚫 NEVER Use Build Commands During Diagnosis**
+
+**Critical Rule**: Never use `npm run build:web` or similar build commands during bug diagnosis
+
+- **Reason**: These commands block the chat and prevent effective troubleshooting
+- **Impact**: Blocks user interaction, prevents real-time problem solving
+- **Alternative**: Use safe, fast commands for investigation
+- **When to use build**: Only after diagnosis is complete and fixes are ready for testing
+
+### **Safe Diagnosis Commands**
+
+✅ **Safe to use during diagnosis:**
+- `npm run lint-fix` - Syntax and style checking
+- `npm run type-check` - TypeScript validation (if available)
+- `git status` - Version control status
+- `ls` / `dir` - File listing
+- `cat` / `read_file` - File content inspection
+- `grep_search` - Text pattern searching
+
+❌ **Never use during diagnosis:**
+- `npm run build:web` - Blocks chat
+- `npm run build:electron` - Blocks chat  
+- `npm run build:capacitor` - Blocks chat
+- Any long-running build processes
+
+## Investigation Workflow
+
+### **Phase 1: Problem Definition**
+
+1. **Gather Evidence**
+   - Error messages and stack traces
+   - User-reported symptoms
+   - System logs and timestamps
+   - Reproduction steps
+
+2. **Context Analysis**
+   - When did the problem start?
+   - What changed recently?
+   - Which platform/environment?
+   - User actions leading to the issue
+
+### **Phase 2: Systematic Investigation**
+
+1. **Code Inspection**
+   - Relevant file examination
+   - Import and dependency analysis
+   - Syntax and type checking
+   - Logic flow analysis
+
+2. **Environment Analysis**
+   - Platform-specific considerations
+   - Configuration and settings
+   - Database and storage state
+   - Network and API connectivity
+
+### **Phase 3: Root Cause Identification**
+
+1. **Pattern Recognition**
+   - Similar issues in codebase
+   - Common failure modes
+   - Platform-specific behaviors
+   - Recent changes impact
+
+2. **Hypothesis Testing**
+   - Targeted code changes
+   - Configuration modifications
+   - Environment adjustments
+   - Systematic elimination
+
+## Investigation Techniques
+
+### **Safe Code Analysis**
+
+- **File Reading**: Use `read_file` tool for targeted inspection
+- **Pattern Searching**: Use `grep_search` for code patterns
+- **Semantic Search**: Use `codebase_search` for related functionality
+- **Import Tracing**: Follow dependency chains systematically
+
+### **Error Analysis**
+
+- **Stack Trace Analysis**: Identify error origin and propagation
+- **Log Correlation**: Match errors with system events
+- **Timeline Reconstruction**: Build sequence of events
+- **Context Preservation**: Maintain investigation state
+
+### **Platform Considerations**
+
+- **Web Platform**: Browser-specific behaviors and limitations
+- **Electron Platform**: Desktop app considerations
+- **Capacitor Platform**: Mobile app behaviors
+- **Cross-Platform**: Shared vs. platform-specific code
+
+## Evidence Collection Standards
+
+### **Timestamps**
+
+- **UTC Format**: All timestamps in UTC for consistency
+- **Precision**: Include milliseconds for precise correlation
+- **Context**: Include relevant system state information
+- **Correlation**: Link events across different components
+
+### **Error Context**
+
+- **Full Error Objects**: Capture complete error information
+- **Stack Traces**: Preserve call stack for analysis
+- **User Actions**: Document steps leading to error
+- **System State**: Capture relevant configuration and state
+
+### **Reproduction Steps**
+
+- **Clear Sequence**: Step-by-step reproduction instructions
+- **Environment Details**: Platform, version, configuration
+- **Data Requirements**: Required data or state
+- **Expected vs. Actual**: Clear behavior comparison
+
+## Investigation Documentation
+
+### **Problem Summary**
+
+- **Issue Description**: Clear, concise problem statement
+- **Impact Assessment**: Severity and user impact
+- **Scope Definition**: Affected components and users
+- **Priority Level**: Based on impact and frequency
+
+### **Investigation Log**
+
+- **Timeline**: Chronological investigation steps
+- **Evidence**: Collected information and findings
+- **Hypotheses**: Tested theories and results
+- **Conclusions**: Root cause identification
+
+### **Solution Requirements**
+
+- **Fix Description**: Required changes and approach
+- **Testing Strategy**: Validation and verification steps
+- **Rollback Plan**: Reversion strategy if needed
+- **Prevention Measures**: Future issue prevention
+
+## Quality Standards
+
+### **Investigation Completeness**
+
+- **Evidence Sufficiency**: Adequate information for root cause
+- **Alternative Theories**: Considered and eliminated
+- **Platform Coverage**: All relevant platforms investigated
+- **Edge Cases**: Unusual scenarios considered
+
+### **Documentation Quality**
+
+- **Clear Communication**: Understandable to all stakeholders
+- **Technical Accuracy**: Precise technical details
+- **Actionable Insights**: Clear next steps and recommendations
+- **Knowledge Transfer**: Lessons learned for future reference
+
+## Common Pitfalls
+
+### **Investigation Mistakes**
+
+- **Jumping to Solutions**: Implementing fixes before understanding
+- **Insufficient Evidence**: Making assumptions without data
+- **Platform Blindness**: Ignoring platform-specific behaviors
+- **Scope Creep**: Expanding investigation beyond original problem
+
+### **Communication Issues**
+
+- **Technical Jargon**: Using unclear terminology
+- **Missing Context**: Insufficient background information
+- **Unclear Recommendations**: Vague or ambiguous next steps
+- **Poor Documentation**: Incomplete or unclear investigation records
+
+## Success Criteria
+
+- [ ] **Problem clearly defined** with sufficient evidence
+- [ ] **Root cause identified** through systematic investigation
+- [ ] **Solution approach determined** with clear requirements
+- [ ] **Documentation complete** for knowledge transfer
+- [ ] **No chat-blocking commands** used during investigation
+- [ ] **Platform considerations** properly addressed
+- [ ] **Timeline and context** properly documented
+
+## Integration with Other Meta-Rules
+
+### **Bug Fixing**
+
+- **Investigation Results**: Provide foundation for fix implementation
+- **Solution Requirements**: Define what needs to be built
+- **Testing Strategy**: Inform validation approach
+- **Documentation**: Support implementation guidance
+
+### **Feature Planning**
+
+- **Root Cause Analysis**: Identify systemic issues
+- **Prevention Measures**: Plan future issue avoidance
+- **Architecture Improvements**: Identify structural enhancements
+- **Process Refinements**: Improve development workflows
+
+### **Research and Documentation**
+
+- **Knowledge Base**: Contribute to troubleshooting guides
+- **Pattern Recognition**: Identify common failure modes
+- **Best Practices**: Develop investigation methodologies
+- **Team Training**: Improve investigation capabilities
+
+---
+
+**See also**:
+
+- `.cursor/rules/meta_bug_fixing.mdc` for implementing fixes
+- `.cursor/rules/meta_feature_planning.mdc` for planning improvements
+- `.cursor/rules/meta_documentation.mdc` for documentation standards
+
+**Status**: Active meta-rule for bug diagnosis
+**Priority**: High
+**Estimated Effort**: Ongoing reference
+**Dependencies**: All bundled sub-rules
+**Stakeholders**: Development team, QA team, DevOps team

.cursor/rules/meta_bug_fixing.mdc

@@ -0,0 +1,214 @@
+# Meta-Rule: Bug Fixing
+
+**Author**: Matthew Raymer
+**Date**: 2025-08-21
+**Status**: 🎯 **ACTIVE** - Bug fix implementation workflow bundling
+
+## Purpose
+
+This meta-rule bundles all the rules needed for implementing bug fixes
+with proper testing and validation. Use this after diagnosis when
+implementing the actual fix.
+
+## Workflow Constraints
+
+**This meta-rule enforces FIXING MODE for all bundled sub-rules:**
+
+```json
+{
+  "workflowMode": "fixing",
+  "constraints": {
+    "mode": "implementation",
+    "allowed": ["modify", "create", "build", "test", "commit"],
+    "required": "diagnosis_complete_before_fixing"
+  }
+}
+```
+
+**All bundled sub-rules automatically inherit these constraints.**
+
+## Workflow State Update
+
+**When this meta-rule is invoked, update the workflow state file:**
+
+```json
+{
+  "currentMode": "fixing",
+  "lastInvoked": "meta_bug_fixing.mdc",
+  "timestamp": "2025-01-27T15:30:00Z",
+  "constraints": {
+    "mode": "implementation",
+    "allowed": ["modify", "create", "build", "test", "commit"],
+    "forbidden": [],
+    "required": "diagnosis_complete_before_fixing"
+  }
+}
+```
+
+**State File Location**: `.cursor/rules/.workflow_state.json`
+
+**This enables the core always-on rule to enforce fixing mode constraints.**
+
+## When to Use
+
+- **Post-Diagnosis**: After root cause is identified and fix is planned
+- **Fix Implementation**: When coding the actual bug fix
+- **Testing & Validation**: When testing the fix works correctly
+- **Code Review**: When reviewing the fix implementation
+- **Deployment**: When preparing the fix for deployment
+- **Documentation**: When documenting the fix and lessons learned
+
+## Bundled Rules
+
+### **Implementation Standards**
+
+- **`development/software_development.mdc`** - Core development
+  principles, evidence requirements, and testing strategy
+- **`development/type_safety_guide.mdc`** - Type-safe implementation
+  with proper error handling and type guards
+- **`development/logging_migration.mdc`** - Proper logging
+  implementation and migration from console.* calls
+
+### **Code Quality & Review**
+
+- **`development/historical_comment_management.mdc`** - Code quality
+  standards and comment transformation rules
+- **`development/historical_comment_patterns.mdc`** - Specific
+  patterns for transforming historical comments
+- **`development/complexity_assessment.mdc`** - Complexity evaluation
+  for fix implementation
+
+### **Platform & Testing**
+
+- **`app/timesafari_development.mdc`** - TimeSafari-specific
+  development workflow and testing requirements
+- **`app/timesafari_platforms.mdc`** - Platform-specific testing
+  and validation requirements
+- **`architecture/build_validation.mdc`** - Build system validation
+  and testing procedures
+
+## Workflow Sequence
+
+### **Phase 1: Fix Implementation (Start Here)**
+
+1. **Development Standards** - Apply `software_development.mdc` for
+   core implementation principles
+2. **Type Safety** - Use `type_safety_guide.mdc` for type-safe
+   implementation
+3. **Logging Implementation** - Apply `logging_migration.mdc` for
+   proper logging
+
+### **Phase 2: Quality & Review**
+
+1. **Code Quality** - Use `historical_comment_management.mdc` for
+   code quality standards
+2. **Complexity Assessment** - Apply `complexity_assessment.mdc` to
+   evaluate fix complexity
+3. **Code Review** - Follow review standards from bundled rules
+
+### **Phase 3: Testing & Validation**
+
+1. **Platform Testing** - Use `timesafari_platforms.mdc` for
+   platform-specific testing
+2. **Build Validation** - Apply `build_validation.mdc` for build
+   system compliance
+3. **Final Validation** - Verify fix works across all platforms
+
+## Success Criteria
+
+- [ ] **Fix implemented** following development standards
+- [ ] **Type safety maintained** with proper error handling
+- [ ] **Logging properly implemented** with component context
+- [ ] **Code quality standards met** with clean, maintainable code
+- [ ] **Testing completed** across all target platforms
+- [ ] **Build validation passed** with no build system issues
+- [ ] **Code review completed** with all feedback addressed
+- [ ] **Documentation updated** with fix details and lessons learned
+
+## Common Pitfalls
+
+- **Don't skip type safety** - leads to runtime errors
+- **Don't ignore logging** - makes future debugging harder
+- **Don't skip platform testing** - misses platform-specific issues
+- **Don't ignore code quality** - creates technical debt
+- **Don't skip build validation** - can break build system
+- **Don't forget documentation** - loses fix context for future
+
+## Integration Points
+
+### **With Other Meta-Rules**
+
+- **Bug Diagnosis**: Investigation results drive fix implementation
+- **Feature Implementation**: Fix patterns inform future development
+- **Feature Planning**: Fix complexity informs future planning
+
+### **With Development Workflow**
+
+- Fix implementation follows development standards
+- Testing strategy ensures fix quality
+- Code review maintains code quality
+
+## Feedback & Improvement
+
+### **Sub-Rule Ratings (1-5 scale)**
+
+- **Development Standards**: ___/5 - Comments: _______________
+- **Type Safety**: ___/5 - Comments: _______________
+- **Logging Migration**: ___/5 - Comments: _______________
+- **Code Quality**: ___/5 - Comments: _______________
+- **Platform Testing**: ___/5 - Comments: _______________
+
+### **Workflow Feedback**
+
+- **Implementation Clarity**: How clear was the implementation guidance?
+- **Testing Coverage**: Were testing requirements sufficient or excessive?
+- **Process Effectiveness**: How well did the workflow work for you?
+
+### **Sub-Rule Improvements**
+
+- **Clarity Issues**: Which rules were unclear or confusing?
+- **Missing Examples**: What examples would make rules more useful?
+- **Integration Problems**: Do any rules conflict or overlap?
+
+### **Overall Experience**
+
+- **Time Saved**: How much time did this meta-rule save you?
+- **Quality Improvement**: Did following these rules improve your fix?
+- **Recommendation**: Would you recommend this meta-rule to others?
+
+## Model Implementation Checklist
+
+### Before Bug Fixing
+
+- [ ] **Root Cause Understood**: Confirm root cause is clearly identified
+- [ ] **Fix Strategy Planned**: Plan implementation approach and testing
+- [ ] **Platform Impact Assessed**: Understand impact across all platforms
+- [ ] **Testing Strategy Planned**: Plan testing approach for the fix
+
+### During Bug Fixing
+
+- [ ] **Rule Application**: Apply bundled rules in recommended sequence
+- [ ] **Implementation**: Implement fix following development standards
+- [ ] **Testing**: Test fix across all target platforms
+- [ ] **Documentation**: Document implementation details and decisions
+
+### After Bug Fixing
+
+- [ ] **Validation**: Verify fix meets all success criteria
+- [ ] **Code Review**: Complete code review with team
+- [ ] **Deployment**: Deploy fix following deployment procedures
+- [ ] **Feedback Collection**: Collect feedback on meta-rule effectiveness
+
+---
+
+**See also**:
+
+- `.cursor/rules/meta_bug_diagnosis.mdc` for investigation workflow
+- `.cursor/rules/meta_feature_implementation.mdc` for implementation patterns
+- `.cursor/rules/meta_feature_planning.mdc` for planning future work
+
+**Status**: Active meta-rule for bug fixing
+**Priority**: High
+**Estimated Effort**: Ongoing reference
+**Dependencies**: All bundled sub-rules
+**Stakeholders**: Development team, QA team, DevOps team

.cursor/rules/meta_change_evaluation.mdc

@@ -0,0 +1,383 @@
+# Meta-Rule: Change Evaluation and Breaking Change Detection
+
+**Author**: Matthew Raymer  
+**Date**: 2025-08-25  
+**Status**: 🎯 **ACTIVE** - Manually activated change evaluation rule
+
+## Purpose
+
+This meta-rule provides a systematic approach to evaluate changes between
+branches and detect potential breaking changes. It's designed to catch
+problematic model behavior by analyzing the nature, scope, and impact of
+code changes before they cause issues.
+
+## When to Use
+
+**Manual Activation Only** - This rule should be invoked when:
+
+- Reviewing changes before merging branches
+- Investigating unexpected behavior after updates
+- Validating that model-generated changes are safe
+- Analyzing the impact of recent commits
+- Debugging issues that may be caused by recent changes
+
+## Workflow State Enforcement
+
+**This meta-rule enforces current workflow mode constraints:**
+
+### **Current Workflow State**
+
+```json
+{
+  "workflowState": {
+    "currentMode": "diagnosis|fixing|planning|research|documentation",
+    "constraints": {
+      "mode": "read_only|implementation|design_only|investigation|writing_only",
+      "allowed": ["array", "of", "allowed", "actions"],
+      "forbidden": ["array", "of", "forbidden", "actions"]
+    }
+  }
+}
+```
+
+### **Mode-Specific Enforcement**
+
+**Diagnosis Mode (read_only):**
+
+- ❌ **Forbidden**: File modification, code creation, build commands, git
+  commits
+- ✅ **Allowed**: File reading, code analysis, investigation, documentation
+- **Response**: Focus on analysis and documentation, not implementation
+
+**Fixing Mode (implementation):**
+
+- ✅ **Allowed**: File modification, code creation, build commands, testing,
+  git commits
+- ❌ **Forbidden**: None (full implementation mode)
+- **Response**: Proceed with implementation and testing
+
+**Planning Mode (design_only):**
+
+- ❌ **Forbidden**: Implementation, coding, building, deployment
+- ✅ **Allowed**: Analysis, design, estimation, documentation, architecture
+- **Response**: Focus on planning and design, not implementation
+
+**Research Mode (investigation):**
+
+- ❌ **Forbidden**: File modification, implementation, deployment
+- ✅ **Allowed**: Investigation, analysis, research, documentation
+- **Response**: Focus on investigation and analysis
+
+**Documentation Mode (writing_only):**
+
+- ❌ **Forbidden**: Implementation, coding, building, deployment
+- ✅ **Allowed**: Writing, editing, formatting, structuring, reviewing
+- **Response**: Focus on documentation creation and improvement
+
+## Change Evaluation Process
+
+### **Phase 1: Change Discovery and Analysis**
+
+1. **Branch Comparison Analysis**
+
+   - Compare working branch with master/main branch
+   - Identify all changed files and their modification types
+   - Categorize changes by scope and impact
+
+2. **Change Pattern Recognition**
+
+   - Identify common change patterns (refactoring, feature addition, bug
+     fixes)
+   - Detect unusual or suspicious change patterns
+   - Flag changes that deviate from established patterns
+
+3. **Dependency Impact Assessment**
+
+   - Analyze changes to imports, exports, and interfaces
+   - Identify potential breaking changes to public APIs
+   - Assess impact on dependent components and services
+
+### **Phase 2: Breaking Change Detection**
+
+1. **API Contract Analysis**
+
+   - Check for changes to function signatures, method names, class
+     interfaces
+   - Identify removed or renamed public methods/properties
+   - Detect changes to configuration options and constants
+
+2. **Data Structure Changes**
+
+   - Analyze database schema modifications
+   - Check for changes to data models and interfaces
+   - Identify modifications to serialization/deserialization logic
+
+3. **Behavioral Changes**
+
+   - Detect changes to business logic and algorithms
+   - Identify modifications to error handling and validation
+   - Check for changes to user experience and workflows
+
+### **Phase 3: Risk Assessment and Recommendations**
+
+1. **Risk Level Classification**
+
+   - **LOW**: Cosmetic changes, documentation updates, minor refactoring
+   - **MEDIUM**: Internal API changes, configuration modifications,
+     performance improvements
+   - **HIGH**: Public API changes, breaking interface modifications, major
+     architectural changes
+   - **CRITICAL**: Database schema changes, authentication modifications,
+     security-related changes
+
+2. **Impact Analysis**
+
+   - Identify affected user groups and use cases
+   - Assess potential for data loss or corruption
+   - Evaluate impact on system performance and reliability
+
+3. **Mitigation Strategies**
+
+   - Recommend testing approaches for affected areas
+   - Suggest rollback strategies if needed
+   - Identify areas requiring additional validation
+
+## Implementation Guidelines
+
+### **Change Analysis Tools**
+
+1. **Git Diff Analysis**
+
+   ```bash
+   # Compare working branch with master
+   git diff master..HEAD --name-only
+   git diff master..HEAD --stat
+   git log master..HEAD --oneline
+   ```
+
+2. **File Change Categorization**
+
+   - **Core Files**: Application entry points, main services, critical
+     utilities
+   - **Interface Files**: Public APIs, component interfaces, data models
+   - **Configuration Files**: Environment settings, build configurations,
+     deployment scripts
+   - **Test Files**: Unit tests, integration tests, test utilities
+
+3. **Change Impact Mapping**
+
+   - Map changed files to affected functionality
+   - Identify cross-dependencies and ripple effects
+   - Document potential side effects and unintended consequences
+
+### **Breaking Change Detection Patterns**
+
+1. **Function Signature Changes**
+
+   ```typescript
+   // BEFORE
+   function processData(data: string, options?: Options): Result
+   
+   // AFTER - BREAKING CHANGE
+   function processData(data: string, options: Required<Options>): Result
+   ```
+
+2. **Interface Modifications**
+
+   ```typescript
+   // BEFORE
+   interface UserProfile {
+     name: string;
+     email: string;
+   }
+   
+   // AFTER - BREAKING CHANGE
+   interface UserProfile {
+     name: string;
+     email: string;
+     phone: string; // Required new field
+   }
+   ```
+
+3. **Configuration Changes**
+
+   ```typescript
+   // BEFORE
+   const config = {
+     apiUrl: 'https://api.example.com',
+     timeout: 5000
+   };
+   
+   // AFTER - BREAKING CHANGE
+   const config = {
+     apiUrl: 'https://api.example.com',
+     timeout: 5000,
+     retries: 3 // New required configuration
+   };
+   ```
+
+## Output Format
+
+### **Change Evaluation Report**
+
+```markdown
+# Change Evaluation Report
+
+## Executive Summary
+
+- **Risk Level**: [LOW|MEDIUM|HIGH|CRITICAL]
+- **Overall Assessment**: [SAFE|CAUTION|DANGEROUS|CRITICAL]
+- **Recommendation**: [PROCEED|REVIEW|HALT|IMMEDIATE_ROLLBACK]
+
+## Change Analysis
+
+### Files Modified
+
+- **Total Changes**: [X] files
+- **Core Files**: [X] files
+- **Interface Files**: [X] files
+- **Configuration Files**: [X] files
+- **Test Files**: [X] files
+
+### Change Categories
+
+- **Refactoring**: [X] changes
+- **Feature Addition**: [X] changes
+- **Bug Fixes**: [X] changes
+- **Configuration**: [X] changes
+- **Documentation**: [X] changes
+
+## Breaking Change Detection
+
+### API Contract Changes
+
+- **Function Signatures**: [X] modified
+- **Interface Definitions**: [X] modified
+- **Public Methods**: [X] added/removed/modified
+
+### Data Structure Changes
+
+- **Database Schema**: [X] modifications
+- **Data Models**: [X] changes
+- **Serialization**: [X] changes
+
+### Behavioral Changes
+
+- **Business Logic**: [X] modifications
+- **Error Handling**: [X] changes
+- **User Experience**: [X] changes
+
+## Risk Assessment
+
+### Impact Analysis
+
+- **User Groups Affected**: [Description]
+- **Use Cases Impacted**: [Description]
+- **Performance Impact**: [Description]
+- **Reliability Impact**: [Description]
+
+### Dependencies
+
+- **Internal Dependencies**: [List]
+- **External Dependencies**: [List]
+- **Configuration Dependencies**: [List]
+
+## Recommendations
+
+### Testing Requirements
+
+- [ ] Unit tests for modified components
+- [ ] Integration tests for affected workflows
+- [ ] Performance tests for changed algorithms
+- [ ] User acceptance tests for UI changes
+
+### Validation Steps
+
+- [ ] Code review by domain experts
+- [ ] API compatibility testing
+- [ ] Database migration testing
+- [ ] End-to-end workflow testing
+
+### Rollback Strategy
+
+- **Rollback Complexity**: [LOW|MEDIUM|HIGH]
+- **Rollback Time**: [Estimated time]
+- **Data Preservation**: [Strategy description]
+
+## Conclusion
+
+[Summary of findings and final recommendation]
+```
+
+## Usage Examples
+
+### **Example 1: Safe Refactoring**
+
+```bash
+@meta_change_evaluation.mdc analyze changes between feature-branch and master
+```
+
+### **Example 2: Breaking Change Investigation**
+
+```bash
+@meta_change_evaluation.mdc evaluate potential breaking changes in recent commits
+```
+
+### **Example 3: Pre-Merge Validation**
+
+```bash
+@meta_change_evaluation.mdc validate changes before merging feature-branch to master
+```
+
+## Success Criteria
+
+- [ ] **Change Discovery**: All modified files are identified and categorized
+- [ ] **Pattern Recognition**: Unusual change patterns are detected and flagged
+- [ ] **Breaking Change Detection**: All potential breaking changes are identified
+- [ ] **Risk Assessment**: Accurate risk levels are assigned with justification
+- [ ] **Recommendations**: Actionable recommendations are provided
+- [ ] **Documentation**: Complete change evaluation report is generated
+
+## Common Pitfalls
+
+- **Missing Dependencies**: Failing to identify all affected components
+- **Underestimating Impact**: Not considering ripple effects of changes
+- **Incomplete Testing**: Missing critical test scenarios for changes
+- **Configuration Blindness**: Overlooking configuration file changes
+- **Interface Assumptions**: Assuming internal changes won't affect external
+  users
+
+## Integration with Other Meta-Rules
+
+### **With Bug Diagnosis**
+
+- Use change evaluation to identify recent changes that may have caused
+  bugs
+- Correlate change patterns with reported issues
+
+### **With Feature Planning**
+
+- Evaluate the impact of planned changes before implementation
+- Identify potential breaking changes early in the planning process
+
+### **With Bug Fixing**
+
+- Validate that fixes don't introduce new breaking changes
+- Ensure fixes maintain backward compatibility
+
+---
+
+**See also**:
+
+- `.cursor/rules/meta_core_always_on.mdc` for core always-on rules
+- `.cursor/rules/meta_feature_planning.mdc` for feature development
+  workflows
+- `.cursor/rules/meta_bug_diagnosis.mdc` for bug investigation workflows
+- `.cursor/rules/meta_bug_fixing.mdc` for fix implementation workflows
+
+**Status**: Active change evaluation meta-rule
+**Priority**: High (applies to all change evaluation tasks)
+**Estimated Effort**: Ongoing reference
+**Dependencies**: All bundled sub-rules
+**Stakeholders**: Development team, Quality Assurance team, Release
+Management team

.cursor/rules/meta_core_always_on.mdc

@@ -0,0 +1,307 @@
+---
+alwaysApply: false
+---
+# Meta-Rule: Core Always-On Rules
+
+**Author**: Matthew Raymer
+**Date**: 2025-08-21
+**Status**: 🎯 **ACTIVE** - Core rules for every prompt
+
+## Purpose
+
+This meta-rule bundles the core rules that should be applied to **every single
+prompt** because they define fundamental behaviors, principles, and context
+that are essential for all AI interactions.
+
+## Workflow Constraints
+
+**This meta-rule enforces ALWAYS-ON MODE for all bundled sub-rules:**
+
+```json
+{
+  "workflowMode": "always_on",
+  "constraints": {
+    "mode": "foundation",
+    "alwaysApplied": true,
+    "required": "applied_to_every_prompt"
+  }
+}
+```
+
+**All bundled sub-rules automatically inherit these constraints.**
+
+## Workflow State Enforcement
+
+**This meta-rule enforces current workflow mode constraints for all interactions:**
+
+### **Current Workflow State**
+```json
+{
+  "workflowState": {
+    "currentMode": "diagnosis|fixing|planning|research|documentation",
+    "constraints": {
+      "mode": "read_only|implementation|design_only|investigation|writing_only",
+      "allowed": ["array", "of", "allowed", "actions"],
+      "forbidden": ["array", "of", "forbidden", "actions"]
+    }
+  }
+}
+```
+
+### **Constraint Enforcement Rules**
+
+**Before responding to any user request, enforce current mode constraints:**
+
+1. **Read current workflow state** from `.cursor/rules/.workflow_state.json`
+2. **Identify current mode** and its constraints
+3. **Validate user request** against current mode constraints
+4. **Enforce constraints** before generating response
+5. **Guide model behavior** based on current mode
+
+### **Mode-Specific Enforcement**
+
+**Diagnosis Mode (read_only):**
+- ❌ **Forbidden**: File modification, code creation, build commands, git commits
+- ✅ **Allowed**: File reading, code analysis, investigation, documentation
+- **Response**: Guide user toward investigation and analysis, not implementation
+
+**Fixing Mode (implementation):**
+- ✅ **Allowed**: File modification, code creation, build commands, testing, git commits
+- ❌ **Forbidden**: None (full implementation mode)
+- **Response**: Proceed with implementation and testing
+
+**Planning Mode (design_only):**
+- ❌ **Forbidden**: Implementation, coding, building, deployment
+- ✅ **Allowed**: Analysis, design, estimation, documentation, architecture
+- **Response**: Focus on planning and design, not implementation
+
+**Research Mode (investigation):**
+- ❌ **Forbidden**: File modification, implementation, deployment
+- ✅ **Allowed**: Investigation, analysis, research, documentation
+- **Response**: Focus on investigation and analysis
+
+**Documentation Mode (writing_only):**
+- ❌ **Forbidden**: Implementation, coding, building, deployment
+- ✅ **Allowed**: Writing, editing, formatting, structuring, reviewing
+- **Response**: Focus on documentation creation and improvement
+
+### **Constraint Violation Response**
+
+**If user request violates current mode constraints:**
+
+```
+❌ **WORKFLOW CONSTRAINT VIOLATION**
+
+**Current Mode**: [MODE_NAME]
+**Requested Action**: [ACTION] 
+**Constraint Violation**: [DESCRIPTION]
+
+**What You Can Do Instead**:
+- [LIST OF ALLOWED ALTERNATIVES]
+
+**To Enable This Action**: Invoke @meta_[appropriate_mode].mdc
+```
+
+### **Mode Transition Guidance**
+
+**When user needs to change modes, provide clear guidance:**
+
+```
+🔄 **MODE TRANSITION REQUIRED**
+
+**Current Mode**: [CURRENT_MODE]
+**Required Mode**: [REQUIRED_MODE]
+**Action**: Invoke @meta_[required_mode].mdc
+
+**This will enable**: [DESCRIPTION OF NEW CAPABILITIES]
+```
+
+## When to Use
+
+**ALWAYS** - These rules apply to every single prompt, regardless of the task
+or context. They form the foundation for all AI assistant behavior.
+
+## Bundled Rules
+
+### **Core Human Competence Principles**
+
+- **`core/base_context.mdc`** - Human competence first principles, interaction
+  guidelines, and output contract requirements
+- **`core/less_complex.mdc`** - Minimalist solution principle and complexity
+  guidelines
+
+### **Time & Context Standards**
+
+- **`development/time.mdc`** - Time handling principles and UTC standards
+- **`development/time_examples.mdc`** - Practical time implementation examples
+- **`development/time_implementation.mdc`** - Detailed time implementation
+  guidelines
+
+### **Version Control & Process**
+
+- **`workflow/version_control.mdc`** - Version control principles and commit
+  guidelines
+- **`workflow/commit_messages.mdc`** - Commit message format and conventions
+
+### **Application Context**
+
+- **`app/timesafari.mdc`** - Core TimeSafari application context and
+  development principles
+- **`app/timesafari_development.mdc`** - TimeSafari-specific development
+  workflow and quality standards
+
+## Why These Rules Are Always-On
+
+### **Base Context**
+
+- **Human Competence First**: Every interaction must increase human competence
+- **Output Contract**: All responses must follow the required structure
+- **Competence Hooks**: Learning and collaboration must be built into every response
+
+### **Time Standards**
+
+- **UTC Consistency**: All timestamps must use UTC for system operations
+- **Evidence Collection**: Time context is essential for debugging and investigation
+- **Cross-Platform**: Time handling affects all platforms and features
+
+### **Version Control**
+
+- **Commit Standards**: Every code change must follow commit message conventions
+- **Process Consistency**: Version control affects all development work
+- **Team Collaboration**: Commit standards enable effective team communication
+
+### **Application Context**
+
+- **Platform Awareness**: Every task must consider web/mobile/desktop platforms
+- **Architecture Principles**: All work must follow TimeSafari patterns
+- **Development Standards**: Quality and testing requirements apply to all work
+
+## Application Priority
+
+### **Primary (Apply First)**
+
+1. **Base Context** - Human competence and output contract
+2. **Time Standards** - UTC and timestamp requirements
+3. **Application Context** - TimeSafari principles and platforms
+
+### **Secondary (Apply as Needed)**
+
+1. **Version Control** - When making code changes
+2. **Complexity Guidelines** - When evaluating solution approaches
+
+## Integration with Other Meta-Rules
+
+### **Feature Planning**
+
+- Base context ensures human competence focus
+- Time standards inform planning and estimation
+- Application context drives platform considerations
+
+### **Bug Diagnosis**
+
+- Base context ensures systematic investigation
+- Time standards enable proper evidence collection
+- Application context provides system understanding
+
+### **Bug Fixing**
+
+- Base context ensures quality implementation
+- Time standards maintain logging consistency
+- Application context guides testing strategy
+
+### **Feature Implementation**
+
+- Base context ensures proper development approach
+- Time standards maintain system consistency
+- Application context drives architecture decisions
+
+## Success Criteria
+
+- [ ] **Base context applied** to every single prompt
+- [ ] **Time standards followed** for all timestamps and logging
+- [ ] **Version control standards** applied to all code changes
+- [ ] **Application context considered** for all platform work
+- [ ] **Human competence focus** maintained in all interactions
+- [ ] **Output contract structure** followed in all responses
+
+## Common Pitfalls
+
+- **Don't skip base context** - loses human competence focus
+- **Don't ignore time standards** - creates inconsistent timestamps
+- **Don't forget application context** - misses platform considerations
+- **Don't skip version control** - creates inconsistent commit history
+- **Don't lose competence focus** - reduces learning value
+
+## Feedback & Improvement
+
+### **Rule Effectiveness Ratings (1-5 scale)**
+
+- **Base Context**: ___/5 - Comments: _______________
+- **Time Standards**: ___/5 - Comments: _______________
+- **Version Control**: ___/5 - Comments: _______________
+- **Application Context**: ___/5 - Comments: _______________
+
+### **Always-On Effectiveness**
+
+- **Consistency**: Are these rules applied consistently across all prompts?
+- **Value**: Do these rules add value to every interaction?
+- **Overhead**: Are these rules too burdensome for simple tasks?
+
+### **Integration Feedback**
+
+- **With Other Meta-Rules**: How well do these integrate with workflow rules?
+- **Context Switching**: Do these rules help or hinder context switching?
+- **Learning Curve**: Are these rules easy for new users to understand?
+
+### **Overall Experience**
+
+- **Quality Improvement**: Do these rules improve response quality?
+- **Efficiency**: Do these rules make interactions more efficient?
+- **Recommendation**: Would you recommend keeping these always-on?
+
+## Model Implementation Checklist
+
+### Before Every Prompt
+
+- [ ] **Base Context**: Ensure human competence principles are active
+- [ ] **Time Standards**: Verify UTC and timestamp requirements are clear
+- [ ] **Application Context**: Confirm TimeSafari context is loaded
+- [ ] **Version Control**: Prepare commit standards if code changes are needed
+- [ ] **Workflow State**: Read current mode constraints from state file
+- [ ] **Constraint Validation**: Validate user request against current mode
+
+### During Response Creation
+
+- [ ] **Output Contract**: Follow required response structure
+- [ ] **Competence Hooks**: Include learning and collaboration elements
+- [ ] **Time Consistency**: Apply UTC standards for all time references
+- [ ] **Platform Awareness**: Consider all target platforms
+- [ ] **Mode Enforcement**: Apply current mode constraints to response
+- [ ] **Constraint Violations**: Block forbidden actions and guide alternatives
+
+### After Response Creation
+
+- [ ] **Validation**: Verify all always-on rules were applied
+- [ ] **Quality Check**: Ensure response meets competence standards
+- [ ] **Context Review**: Confirm application context was properly considered
+- [ ] **Feedback Collection**: Note any issues with always-on application
+- [ ] **Mode Compliance**: Verify response stayed within current mode constraints
+- [ ] **Transition Guidance**: Provide clear guidance for mode changes if needed
+
+---
+
+**See also**:
+
+- `.cursor/rules/meta_feature_planning.mdc` for workflow-specific rules
+
+**Status**: Active core always-on meta-rule
+**Priority**: Critical (applies to every prompt)
+**Estimated Effort**: Ongoing reference
+**Dependencies**: All bundled sub-rules
+**Stakeholders**: All AI interactions, Development team
+
+**Dependencies**: All bundled sub-rules
+**Stakeholders**: All AI interactions, Development team
+
+**Dependencies**: All bundled sub-rules
+**Stakeholders**: All AI interactions, Development team

.cursor/rules/meta_documentation.mdc

@@ -0,0 +1,275 @@
+# Meta-Rule: Documentation Writing & Education
+
+**Author**: Matthew Raymer
+**Date**: 2025-08-21
+**Status**: 🎯 **ACTIVE** - Documentation writing and education workflow
+
+## Purpose
+
+This meta-rule bundles documentation-related rules to create comprehensive,
+educational documentation that increases human competence rather than just
+providing technical descriptions.
+
+## Workflow Constraints
+
+**This meta-rule enforces DOCUMENTATION MODE for all bundled sub-rules:**
+
+```json
+{
+  "workflowMode": "documentation",
+  "constraints": {
+    "mode": "writing_only",
+    "allowed": ["write", "edit", "format", "structure", "review"],
+    "forbidden": ["implement", "code", "build", "deploy"]
+  }
+}
+```
+
+**All bundled sub-rules automatically inherit these constraints.**
+
+## Workflow State Update
+
+**When this meta-rule is invoked, update the workflow state file:**
+
+```json
+{
+  "currentMode": "documentation",
+  "lastInvoked": "meta_documentation.mdc",
+  "timestamp": "2025-01-27T15:30:00Z",
+  "constraints": {
+    "mode": "writing_only",
+    "allowed": ["write", "edit", "format", "structure", "review"],
+    "forbidden": ["implement", "code", "build", "deploy"]
+  }
+}
+```
+
+**State File Location**: `.cursor/rules/.workflow_state.json`
+
+**This enables the core always-on rule to enforce documentation mode constraints.**
+
+## When to Use
+
+**Use this meta-rule when**:
+- Writing new documentation
+- Updating existing documentation
+- Creating technical guides
+- Writing migration documentation
+- Creating architectural documentation
+- Writing user guides or tutorials
+
+## Bundled Rules
+
+### **Core Documentation Standards**
+
+- **`docs/markdown_core.mdc`** - Core markdown formatting and automation
+- **`docs/markdown_templates.mdc`** - Document templates and structure
+- **`docs/markdown_workflow.mdc`** - Documentation validation workflows
+
+### **Documentation Principles**
+
+- **`core/base_context.mdc`** - Human competence first principles
+- **`core/less_complex.mdc`** - Minimalist solution guidelines
+- **`development/software_development.mdc`** - Development documentation standards
+
+### **Context-Specific Rules**
+
+- **`app/timesafari.mdc`** - TimeSafari application context
+- **`app/timesafari_development.mdc`** - Development documentation patterns
+- **`architecture/architectural_patterns.mdc`** - Architecture documentation
+
+## Core Documentation Philosophy
+
+### **Education Over Technical Description**
+
+**Primary Goal**: Increase human competence and understanding
+**Secondary Goal**: Provide accurate technical information
+**Approach**: Explain the "why" before the "how"
+
+### **Human Competence Principles**
+
+1. **Context First**: Explain the problem before the solution
+2. **Learning Path**: Structure content for progressive understanding
+3. **Real Examples**: Use concrete, relatable examples
+4. **Common Pitfalls**: Warn about typical mistakes and misconceptions
+5. **Decision Context**: Explain why certain choices were made
+
+### **Documentation Hierarchy**
+
+1. **Conceptual Understanding** - What is this and why does it matter?
+2. **Context and Motivation** - When and why would you use this?
+3. **Technical Implementation** - How do you implement it?
+4. **Examples and Patterns** - What does it look like in practice?
+5. **Troubleshooting** - What can go wrong and how to fix it?
+
+## Implementation Guidelines
+
+### **Document Structure**
+
+**Mandatory Sections**:
+- **Overview**: Clear purpose and scope with educational context
+- **Why This Matters**: Business value and user benefit explanation
+- **Core Concepts**: Fundamental understanding before implementation
+- **Implementation**: Step-by-step technical guidance
+- **Examples**: Real-world usage patterns
+- **Common Issues**: Troubleshooting and prevention
+- **Next Steps**: Where to go from here
+
+**Optional Sections**:
+- **Background**: Historical context and evolution
+- **Alternatives**: Other approaches and trade-offs
+- **Advanced Topics**: Deep dive into complex scenarios
+- **References**: Additional learning resources
+
+### **Writing Style**
+
+**Educational Approach**:
+- **Conversational tone**: Write as if explaining to a colleague
+- **Progressive disclosure**: Start simple, add complexity gradually
+- **Active voice**: "You can do this" not "This can be done"
+- **Question format**: "What happens when..." to engage thinking
+- **Analogies**: Use familiar concepts to explain complex ideas
+
+**Technical Accuracy**:
+- **Precise language**: Use exact technical terms consistently
+- **Code examples**: Working, tested code snippets
+- **Version information**: Specify applicable versions and platforms
+- **Limitations**: Clearly state what the solution doesn't do
+
+### **Content Quality Standards**
+
+**Educational Value**:
+- [ ] **Concept clarity**: Reader understands the fundamental idea
+- [ ] **Context relevance**: Reader knows when to apply the knowledge
+- [ ] **Practical application**: Reader can implement the solution
+- [ ] **Problem prevention**: Reader avoids common mistakes
+- [ ] **Next steps**: Reader knows where to continue learning
+
+**Technical Accuracy**:
+- [ ] **Fact verification**: All technical details are correct
+- [ ] **Code validation**: Examples compile and run correctly
+- [ ] **Version compatibility**: Platform and version requirements clear
+- [ ] **Security consideration**: Security implications addressed
+- [ ] **Performance notes**: Performance characteristics documented
+
+## Document Types and Templates
+
+### **Technical Guides**
+
+**Focus**: Implementation and technical details
+**Structure**: Problem → Solution → Implementation → Examples
+**Education**: Explain the "why" behind technical choices
+
+### **Migration Documentation**
+
+**Focus**: Process and workflow guidance
+**Structure**: Context → Preparation → Steps → Validation → Troubleshooting
+**Education**: Help users understand migration benefits and risks
+
+### **Architecture Documentation**
+
+**Focus**: System design and decision rationale
+**Structure**: Problem → Constraints → Alternatives → Decision → Implementation
+**Education**: Explain design trade-offs and decision factors
+
+### **User Guides**
+
+**Focus**: Task completion and user empowerment
+**Structure**: Goal → Prerequisites → Steps → Verification → Next Steps
+**Education**: Help users understand the system's capabilities
+
+## Quality Assurance
+
+### **Review Checklist**
+
+**Educational Quality**:
+- [ ] **Clear learning objective**: What will the reader learn?
+- [ ] **Appropriate complexity**: Matches target audience knowledge
+- [ ] **Progressive disclosure**: Information builds logically
+- [ ] **Practical examples**: Real-world scenarios and use cases
+- [ ] **Common questions**: Anticipates and answers reader questions
+
+**Technical Quality**:
+- [ ] **Accuracy**: All technical details verified
+- [ ] **Completeness**: Covers all necessary information
+- [ ] **Consistency**: Terminology and formatting consistent
+- [ ] **Currency**: Information is up-to-date
+- [ ] **Accessibility**: Clear for target audience
+
+### **Validation Workflows**
+
+1. **Content Review**: Subject matter expert review
+2. **Educational Review**: Learning effectiveness assessment
+3. **Technical Review**: Accuracy and completeness validation
+4. **User Testing**: Real user comprehension testing
+5. **Continuous Improvement**: Regular updates based on feedback
+
+## Success Metrics
+
+### **Educational Effectiveness**
+
+- **Comprehension**: Users understand the concepts
+- **Application**: Users can implement the solutions
+- **Confidence**: Users feel capable and empowered
+- **Efficiency**: Users complete tasks faster
+- **Satisfaction**: Users find documentation helpful
+
+### **Technical Quality**
+
+- **Accuracy**: Zero technical errors
+- **Completeness**: All necessary information included
+- **Consistency**: Uniform style and format
+- **Maintainability**: Easy to update and extend
+- **Accessibility**: Clear for target audience
+
+## Common Pitfalls
+
+### **Educational Mistakes**
+
+- **Assumption overload**: Assuming too much prior knowledge
+- **Information dump**: Overwhelming with details
+- **Context missing**: Not explaining why something matters
+- **Example poverty**: Insufficient practical examples
+- **Feedback missing**: No way to verify understanding
+
+### **Technical Mistakes**
+
+- **Outdated information**: Not keeping content current
+- **Incomplete coverage**: Missing important details
+- **Inconsistent terminology**: Using different terms for same concepts
+- **Poor examples**: Non-working or confusing code
+- **Missing validation**: No way to verify correctness
+
+## Feedback and Improvement
+
+### **Continuous Learning**
+
+- **User feedback**: Collect and analyze user comments
+- **Usage metrics**: Track document usage and effectiveness
+- **Review cycles**: Regular content review and updates
+- **Community input**: Engage users in documentation improvement
+- **Best practices**: Stay current with documentation standards
+
+### **Quality Metrics**
+
+- **Readability scores**: Measure content clarity
+- **User satisfaction**: Survey-based quality assessment
+- **Task completion**: Success rate of documented procedures
+- **Support reduction**: Decrease in help requests
+- **Knowledge retention**: Long-term user understanding
+
+---
+
+**See also**:
+
+- `.cursor/rules/docs/markdown_core.mdc` for core formatting standards
+- `.cursor/rules/docs/markdown_templates.mdc` for document templates
+- `.cursor/rules/docs/markdown_workflow.mdc` for validation workflows
+- `.cursor/rules/docs/meta_rule_usage_guide.md` for how to use meta-rules
+- `.cursor/rules/core/base_context.mdc` for human competence principles
+
+**Status**: Active documentation meta-rule
+**Priority**: High
+**Estimated Effort**: Ongoing reference
+**Dependencies**: All bundled sub-rules
+**Stakeholders**: Documentation team, Development team, Users

.cursor/rules/meta_feature_implementation.mdc

@@ -0,0 +1,226 @@
+# Meta-Rule: Feature Implementation
+
+**Author**: Matthew Raymer
+**Date**: 2025-08-21
+**Status**: 🎯 **ACTIVE** - Feature implementation workflow bundling
+
+## Purpose
+
+This meta-rule bundles all the rules needed for building features with
+proper architecture and cross-platform support. Use this when implementing
+planned features or refactoring existing code.
+
+## Workflow Constraints
+
+**This meta-rule enforces IMPLEMENTATION MODE for all bundled sub-rules:**
+
+```json
+{
+  "workflowMode": "implementation",
+  "constraints": {
+    "mode": "development",
+    "allowed": ["code", "build", "test", "refactor", "deploy"],
+    "required": "planning_complete_before_implementation"
+  }
+}
+```
+
+**All bundled sub-rules automatically inherit these constraints.**
+
+## Workflow State Update
+
+**When this meta-rule is invoked, update the workflow state file:**
+
+```json
+{
+  "currentMode": "implementation",
+  "lastInvoked": "meta_feature_implementation.mdc",
+  "timestamp": "2025-01-27T15:30:00Z",
+  "constraints": {
+    "mode": "development",
+    "allowed": ["code", "build", "test", "refactor", "deploy"],
+    "forbidden": [],
+    "required": "planning_complete_before_implementation"
+  }
+}
+```
+
+**State File Location**: `.cursor/rules/.workflow_state.json`
+
+**This enables the core always-on rule to enforce implementation mode constraints.**
+
+## When to Use
+
+- **Feature Development**: Building new features from planning
+- **Code Refactoring**: Restructuring existing code for better architecture
+- **Platform Expansion**: Adding features to new platforms
+- **Service Implementation**: Building new services or components
+- **Integration Work**: Connecting features with existing systems
+- **Performance Optimization**: Improving feature performance
+
+## Bundled Rules
+
+### **Development Foundation**
+
+- **`app/timesafari_development.mdc`** - TimeSafari-specific
+  development workflow and quality standards
+- **`development/software_development.mdc`** - Core development
+  principles and evidence requirements
+- **`development/type_safety_guide.mdc`** - Type-safe implementation
+  with proper error handling
+
+### **Architecture & Patterns**
+
+- **`app/architectural_patterns.mdc`** - Design patterns and
+  architectural examples for features
+- **`app/architectural_examples.mdc`** - Implementation examples
+  and testing strategies
+- **`app/architectural_implementation.mdc`** - Implementation
+  guidelines and best practices
+
+### **Platform & Services**
+
+- **`app/timesafari_platforms.mdc`** - Platform abstraction
+  patterns and platform-specific requirements
+- **`development/asset_configuration.mdc`** - Asset management
+  and build integration
+- **`development/logging_standards.mdc`** - Proper logging
+  implementation standards
+
+### **Quality & Validation**
+
+- **`architecture/build_validation.mdc`** - Build system
+  validation and testing procedures
+- **`architecture/build_testing.mdc`** - Testing requirements
+  and feedback collection
+- **`development/complexity_assessment.mdc`** - Complexity
+  evaluation for implementation
+
+## Workflow Sequence
+
+### **Phase 1: Implementation Foundation (Start Here)**
+
+1. **Development Workflow** - Use `timesafari_development.mdc` for
+   development standards and workflow
+2. **Type Safety** - Apply `type_safety_guide.mdc` for type-safe
+   implementation
+3. **Architecture Patterns** - Use `architectural_patterns.mdc` for
+   design patterns
+
+### **Phase 2: Feature Development**
+
+1. **Platform Services** - Apply `timesafari_platforms.mdc` for
+   platform abstraction
+2. **Implementation Examples** - Use `architectural_examples.mdc`
+   for implementation guidance
+3. **Asset Configuration** - Apply `asset_configuration.mdc` for
+   asset management
+
+### **Phase 3: Quality & Testing**
+
+1. **Logging Implementation** - Use `logging_standards.mdc` for
+   proper logging
+2. **Build Validation** - Apply `build_validation.mdc` for build
+   system compliance
+3. **Testing & Feedback** - Use `build_testing.mdc` for testing
+   requirements
+
+## Success Criteria
+
+- [ ] **Feature implemented** following development standards
+- [ ] **Type safety maintained** with proper error handling
+- [ ] **Architecture patterns applied** consistently
+- [ ] **Platform abstraction implemented** correctly
+- [ ] **Logging properly implemented** with component context
+- [ ] **Assets configured** and integrated with build system
+- [ ] **Build validation passed** with no build system issues
+- [ ] **Testing completed** across all target platforms
+- [ ] **Code review completed** with all feedback addressed
+
+## Common Pitfalls
+
+- **Don't skip architecture patterns** - leads to inconsistent design
+- **Don't ignore platform abstraction** - creates platform-specific code
+- **Don't skip type safety** - leads to runtime errors
+- **Don't ignore logging** - makes future debugging harder
+- **Don't skip build validation** - can break build system
+- **Don't forget asset configuration** - leads to missing assets
+
+## Integration Points
+
+### **With Other Meta-Rules**
+
+- **Feature Planning**: Planning outputs drive implementation approach
+- **Bug Fixing**: Implementation patterns inform fix strategies
+- **Bug Diagnosis**: Implementation insights help with investigation
+
+### **With Development Workflow**
+
+- Implementation follows development standards
+- Architecture decisions drive implementation approach
+- Platform requirements inform testing strategy
+
+## Feedback & Improvement
+
+### **Sub-Rule Ratings (1-5 scale)**
+
+- **Development Workflow**: ___/5 - Comments: _______________
+- **Type Safety**: ___/5 - Comments: _______________
+- **Architecture Patterns**: ___/5 - Comments: _______________
+- **Platform Services**: ___/5 - Comments: _______________
+- **Build Validation**: ___/5 - Comments: _______________
+
+### **Workflow Feedback**
+
+- **Implementation Clarity**: How clear was the implementation guidance?
+- **Pattern Effectiveness**: How well did architecture patterns work?
+- **Platform Coverage**: How well did platform guidance cover your needs?
+
+### **Sub-Rule Improvements**
+
+- **Clarity Issues**: Which rules were unclear or confusing?
+- **Missing Examples**: What examples would make rules more useful?
+- **Integration Problems**: Do any rules conflict or overlap?
+
+### **Overall Experience**
+
+- **Time Saved**: How much time did this meta-rule save you?
+- **Quality Improvement**: Did following these rules improve your implementation?
+- **Recommendation**: Would you recommend this meta-rule to others?
+
+## Model Implementation Checklist
+
+### Before Feature Implementation
+
+- [ ] **Planning Review**: Review feature planning and requirements
+- [ ] **Architecture Planning**: Plan architecture and design patterns
+- [ ] **Platform Analysis**: Understand platform-specific requirements
+- [ ] **Testing Strategy**: Plan testing approach for the feature
+
+### During Feature Implementation
+
+- [ ] **Rule Application**: Apply bundled rules in recommended sequence
+- [ ] **Implementation**: Implement feature following development standards
+- [ ] **Testing**: Test feature across all target platforms
+- [ ] **Documentation**: Document implementation details and decisions
+
+### After Feature Implementation
+
+- [ ] **Validation**: Verify feature meets all success criteria
+- [ ] **Code Review**: Complete code review with team
+- [ ] **Testing**: Complete comprehensive testing across platforms
+- [ ] **Feedback Collection**: Collect feedback on meta-rule effectiveness
+
+---
+
+**See also**:
+
+- `.cursor/rules/meta_feature_planning.mdc` for planning workflow
+- `.cursor/rules/meta_bug_fixing.mdc` for fix implementation patterns
+- `.cursor/rules/meta_bug_diagnosis.mdc` for investigation insights
+
+**Status**: Active meta-rule for feature implementation
+**Priority**: High
+**Estimated Effort**: Ongoing reference
+**Dependencies**: All bundled sub-rules
+**Stakeholders**: Development team, Architecture team, QA team

.cursor/rules/meta_feature_planning.mdc

@@ -0,0 +1,203 @@
+# Meta-Rule: Feature Planning
+
+**Author**: Matthew Raymer
+**Date**: 2025-08-21
+**Status**: 🎯 **ACTIVE** - Feature planning workflow bundling
+
+## Purpose
+
+This meta-rule bundles all the rules needed for comprehensive feature planning
+across all platforms. Use this when starting any new feature development,
+planning sprints, or estimating work effort.
+
+## Workflow Constraints
+
+**This meta-rule enforces PLANNING MODE for all bundled sub-rules:**
+
+```json
+{
+  "workflowMode": "planning",
+  "constraints": {
+    "mode": "design_only",
+    "allowed": ["analyze", "plan", "design", "estimate", "document"],
+    "forbidden": ["implement", "code", "build", "test", "deploy"]
+  }
+}
+```
+
+**All bundled sub-rules automatically inherit these constraints.**
+
+## Workflow State Update
+
+**When this meta-rule is invoked, update the workflow state file:**
+
+```json
+{
+  "currentMode": "planning",
+  "lastInvoked": "meta_feature_planning.mdc",
+  "timestamp": "2025-01-27T15:30:00Z",
+  "constraints": {
+    "mode": "design_only",
+    "allowed": ["analyze", "plan", "design", "estimate", "document"],
+    "forbidden": ["implement", "code", "build", "test", "deploy"]
+  }
+}
+```
+
+**State File Location**: `.cursor/rules/.workflow_state.json`
+
+**This enables the core always-on rule to enforce planning mode constraints.**
+
+## When to Use
+
+- **New Feature Development**: Planning features from concept to implementation
+- **Sprint Planning**: Estimating effort and breaking down work
+- **Architecture Decisions**: Planning major architectural changes
+- **Platform Expansion**: Adding features to new platforms
+- **Refactoring Planning**: Planning significant code restructuring
+
+## Bundled Rules
+
+### **Core Planning Foundation**
+
+- **`development/planning_examples.mdc`** - Planning templates, examples, and
+  best practices for structured planning
+- **`development/realistic_time_estimation.mdc`** - Time estimation framework
+  with complexity-based phases and milestones
+- **`development/complexity_assessment.mdc`** - Technical and business
+  complexity evaluation with risk assessment
+
+### **Platform & Architecture**
+
+- **`app/timesafari_platforms.mdc`** - Platform-specific requirements,
+  constraints, and capabilities across web/mobile/desktop
+- **`app/architectural_decision_record.mdc`** - ADR process for documenting
+  major architectural decisions and trade-offs
+
+### **Development Context**
+
+- **`app/timesafari.mdc`** - Core application context, principles, and
+  development focus areas
+- **`app/timesafari_development.mdc`** - TimeSafari-specific development
+  workflow and quality standards
+
+## Workflow Sequence
+
+### **Phase 1: Foundation (Start Here)**
+
+1. **Complexity Assessment** - Use `complexity_assessment.mdc` to evaluate
+   technical and business complexity
+2. **Time Estimation** - Apply `realistic_time_estimation.mdc` framework
+   based on complexity results
+3. **Core Planning** - Use `planning_examples.mdc` for structured planning
+   approach
+
+### **Phase 2: Platform & Architecture**
+
+1. **Platform Analysis** - Review `timesafari_platforms.mdc` for
+   platform-specific requirements
+2. **Architecture Planning** - Use `architectural_decision_record.mdc` if
+   major architectural changes are needed
+
+### **Phase 3: Implementation Planning**
+
+1. **Development Workflow** - Reference `timesafari_development.mdc` for
+   development standards and testing strategy
+2. **Final Planning** - Consolidate all inputs into comprehensive plan
+
+## Success Criteria
+
+- [ ] **Complexity assessed** and documented with risk factors
+- [ ] **Time estimate created** with clear phases and milestones
+- [ ] **Platform requirements identified** for all target platforms
+- [ ] **Architecture decisions documented** (if major changes needed)
+- [ ] **Testing strategy planned** with platform-specific considerations
+- [ ] **Dependencies mapped** between tasks and phases
+- [ ] **Stakeholder input gathered** and incorporated
+
+## Common Pitfalls
+
+- **Don't skip complexity assessment** - leads to unrealistic estimates
+- **Don't estimate without platform analysis** - misses platform-specific work
+- **Don't plan without stakeholder input** - creates misaligned expectations
+- **Don't ignore testing strategy** - leads to incomplete planning
+- **Don't skip architecture decisions** - creates technical debt
+
+## Integration Points
+
+### **With Other Meta-Rules**
+
+- **Bug Diagnosis**: Use complexity assessment for bug investigation planning
+- **Feature Implementation**: This planning feeds directly into implementation
+- **Code Review**: Planning standards inform review requirements
+
+### **With Development Workflow**
+
+- Planning outputs become inputs for sprint planning
+- Complexity assessment informs testing strategy
+- Platform requirements drive architecture decisions
+
+## Feedback & Improvement
+
+### **Sub-Rule Ratings (1-5 scale)**
+
+- **Complexity Assessment**: ___/5 - Comments: _______________
+- **Time Estimation**: ___/5 - Comments: _______________
+- **Planning Examples**: ___/5 - Comments: _______________
+- **Platform Analysis**: ___/5 - Comments: _______________
+- **Architecture Decisions**: ___/5 - Comments: _______________
+
+### **Workflow Feedback**
+
+- **Sequence Effectiveness**: Did the recommended order work for you?
+- **Missing Guidance**: What additional information would have helped?
+- **Process Gaps**: Where did the workflow break down?
+
+### **Sub-Rule Improvements**
+
+- **Clarity Issues**: Which rules were unclear or confusing?
+- **Missing Examples**: What examples would make rules more useful?
+- **Integration Problems**: Do any rules conflict or overlap?
+
+### **Overall Experience**
+
+- **Time Saved**: How much time did this meta-rule save you?
+- **Quality Improvement**: Did following these rules improve your planning?
+- **Recommendation**: Would you recommend this meta-rule to others?
+
+## Model Implementation Checklist
+
+### Before Feature Planning
+
+- [ ] **Scope Definition**: Clearly define the feature scope and boundaries
+- [ ] **Stakeholder Identification**: Identify all stakeholders and decision makers
+- [ ] **Platform Requirements**: Understand target platforms and constraints
+- [ ] **Complexity Assessment**: Plan complexity evaluation approach
+
+### During Feature Planning
+
+- [ ] **Rule Application**: Apply bundled rules in recommended sequence
+- [ ] **Documentation**: Document all planning decisions and rationale
+- [ ] **Stakeholder Input**: Gather and incorporate stakeholder feedback
+- [ ] **Validation**: Validate planning against success criteria
+
+### After Feature Planning
+
+- [ ] **Plan Review**: Review plan with stakeholders and team
+- [ ] **Feedback Collection**: Collect feedback on meta-rule effectiveness
+- [ ] **Documentation Update**: Update relevant documentation
+- [ ] **Process Improvement**: Identify improvements for future planning
+
+---
+
+**See also**:
+
+- `.cursor/rules/meta_bug_diagnosis.mdc` for investigation planning
+- `.cursor/rules/meta_feature_implementation.mdc` for implementation workflow
+- `.cursor/rules/meta_bug_fixing.mdc` for fix implementation
+
+**Status**: Active meta-rule for feature planning
+**Priority**: High
+**Estimated Effort**: Ongoing reference
+**Dependencies**: All bundled sub-rules
+**Stakeholders**: Development team, Product team, Architecture team

.cursor/rules/meta_research.mdc

@@ -0,0 +1,285 @@
+# Meta-Rule: Enhanced Research Workflows
+
+**Author**: Matthew Raymer
+**Date**: 2025-01-27
+**Status**: 🎯 **ACTIVE** - Research and investigation workflows
+
+## Purpose
+
+This meta-rule bundles research-specific rules that should be applied when conducting
+systematic investigation, analysis, evidence collection, or research tasks. It provides
+a comprehensive framework for thorough, methodical research workflows that produce
+actionable insights and evidence-based conclusions.
+
+## Workflow Constraints
+
+**This meta-rule enforces RESEARCH MODE for all bundled sub-rules:**
+
+```json
+{
+  "workflowMode": "research",
+  "constraints": {
+    "mode": "investigation",
+    "allowed": ["read", "search", "analyze", "plan"],
+    "forbidden": ["modify", "create", "build", "commit"]
+  }
+}
+```
+
+**All bundled sub-rules automatically inherit these constraints.**
+
+## Workflow State Update
+
+**When this meta-rule is invoked, update the workflow state file:**
+
+```json
+{
+  "currentMode": "research",
+  "lastInvoked": "meta_research.mdc",
+  "timestamp": "2025-01-27T15:30:00Z",
+  "constraints": {
+    "mode": "investigation",
+    "allowed": ["read", "search", "analyze", "plan"],
+    "forbidden": ["modify", "create", "build", "commit"]
+  }
+}
+```
+
+**State File Location**: `.cursor/rules/.workflow_state.json`
+
+**This enables the core always-on rule to enforce research mode constraints.**
+
+## When to Use
+
+**RESEARCH TASKS** - Apply this meta-rule when:
+
+- Investigating bugs, defects, or system issues
+- Conducting technical research or feasibility analysis
+- Analyzing codebases, architectures, or dependencies
+- Researching solutions, alternatives, or best practices
+- Collecting evidence for decision-making or documentation
+- Performing root cause analysis or impact assessment
+
+## Bundled Rules
+
+### **Core Research Principles**
+
+- **`development/research_diagnostic.mdc`** - Systematic investigation workflow
+  and evidence collection methodology
+- **`development/type_safety_guide.mdc`** - Type analysis and safety research
+  for TypeScript/JavaScript codebases
+
+### **Investigation & Analysis**
+
+- **`workflow/version_control.mdc`** - Git history analysis and commit research
+- **`workflow/commit_messages.mdc`** - Commit pattern analysis and history
+  investigation
+
+### **Platform & Context Research**
+
+- **`app/timesafari.mdc`** - Application context research and platform
+  understanding
+- **`app/timesafari_platforms.mdc`** - Platform-specific research and
+  capability analysis
+
+## Why These Rules Are Research-Focused
+
+### **Research Diagnostic**
+
+- **Systematic Approach**: Provides structured investigation methodology
+- **Evidence Collection**: Ensures thorough data gathering and documentation
+- **Root Cause Analysis**: Guides systematic problem investigation
+- **Impact Assessment**: Helps evaluate scope and consequences
+
+### **Type Safety Research**
+
+- **Code Analysis**: Enables systematic type system investigation
+- **Safety Assessment**: Guides research into type-related issues
+- **Migration Planning**: Supports research for architectural changes
+
+### **Version Control Research**
+
+- **History Analysis**: Enables investigation of code evolution
+- **Pattern Recognition**: Helps identify commit and change patterns
+- **Timeline Research**: Supports chronological investigation
+
+### **Platform Research**
+
+- **Capability Analysis**: Guides research into platform-specific features
+- **Context Understanding**: Ensures research considers application context
+- **Cross-Platform Research**: Supports multi-platform investigation
+
+## Application Priority
+
+### **Primary (Apply First)**
+
+1. **Research Diagnostic** - Systematic investigation methodology
+2. **Type Safety Guide** - Code analysis and type research
+3. **Application Context** - Platform and context understanding
+
+### **Secondary (Apply as Needed)**
+
+1. **Version Control** - When investigating code history
+2. **Platform Details** - When researching platform-specific capabilities
+
+## Integration with Other Meta-Rules
+
+### **Bug Diagnosis**
+
+- Research meta-rule provides investigation methodology
+- Core always-on ensures systematic approach
+- Application context provides system understanding
+
+### **Feature Planning**
+
+- Research meta-rule guides feasibility research
+- Core always-on ensures competence focus
+- Application context drives platform considerations
+
+### **Architecture Analysis**
+
+- Research meta-rule provides systematic analysis framework
+- Core always-on ensures quality standards
+- Application context informs architectural decisions
+
+### **Performance Investigation**
+
+- Research meta-rule guides systematic performance research
+- Core always-on ensures thorough investigation
+- Application context provides performance context
+
+## Research Workflow Phases
+
+### **Phase 1: Investigation Setup**
+
+1. **Scope Definition** - Define research boundaries and objectives
+2. **Context Gathering** - Collect relevant application and platform context
+3. **Methodology Selection** - Choose appropriate research approaches
+
+### **Phase 2: Evidence Collection**
+
+1. **Systematic Data Gathering** - Collect evidence using structured methods
+2. **Documentation** - Record all findings and observations
+3. **Validation** - Verify evidence accuracy and relevance
+
+### **Phase 3: Analysis & Synthesis**
+
+1. **Pattern Recognition** - Identify trends and patterns in evidence
+2. **Root Cause Analysis** - Determine underlying causes and factors
+3. **Impact Assessment** - Evaluate scope and consequences
+
+### **Phase 4: Conclusion & Action**
+
+1. **Evidence-Based Conclusions** - Draw conclusions from collected evidence
+2. **Actionable Recommendations** - Provide specific, implementable guidance
+3. **Documentation** - Create comprehensive research documentation
+
+## Success Criteria
+
+- [ ] **Research diagnostic applied** to all investigation tasks
+- [ ] **Type safety research** conducted for code analysis
+- [ ] **Evidence collection** systematic and comprehensive
+- [ ] **Root cause analysis** thorough and accurate
+- [ ] **Conclusions actionable** and evidence-based
+- [ ] **Documentation complete** and searchable
+
+## Common Research Pitfalls
+
+- **Don't skip systematic approach** - leads to incomplete investigation
+- **Don't ignore evidence validation** - creates unreliable conclusions
+- **Don't forget context** - misses important factors
+- **Don't skip documentation** - loses research value
+- **Don't rush conclusions** - produces poor recommendations
+
+## Research Quality Standards
+
+### **Evidence Quality**
+
+- **Completeness**: All relevant evidence collected
+- **Accuracy**: Evidence verified and validated
+- **Relevance**: Evidence directly addresses research questions
+- **Timeliness**: Evidence current and up-to-date
+
+### **Analysis Quality**
+
+- **Systematic**: Analysis follows structured methodology
+- **Objective**: Analysis free from bias and assumptions
+- **Thorough**: All evidence considered and evaluated
+- **Logical**: Conclusions follow from evidence
+
+### **Documentation Quality**
+
+- **Comprehensive**: All findings and methods documented
+- **Searchable**: Documentation easily findable and navigable
+- **Actionable**: Recommendations specific and implementable
+- **Maintainable**: Documentation structure supports updates
+
+## Feedback & Improvement
+
+### **Rule Effectiveness Ratings (1-5 scale)**
+
+- **Research Diagnostic**: ___/5 - Comments: _______________
+- **Type Safety Guide**: ___/5 - Comments: _______________
+- **Version Control**: ___/5 - Comments: _______________
+- **Platform Context**: ___/5 - Comments: _______________
+
+### **Research Workflow Effectiveness**
+
+- **Investigation Quality**: Are research tasks producing thorough results?
+- **Evidence Collection**: Is evidence gathering systematic and complete?
+- **Conclusion Quality**: Are conclusions actionable and evidence-based?
+- **Documentation Value**: Is research documentation useful and maintainable?
+
+### **Integration Feedback**
+
+- **With Other Meta-Rules**: How well does this integrate with workflow rules?
+- **Context Switching**: Do these rules help or hinder research context?
+- **Learning Curve**: Are these rules easy for new researchers to understand?
+
+### **Overall Research Experience**
+
+- **Quality Improvement**: Do these rules improve research outcomes?
+- **Efficiency**: Do these rules make research more efficient?
+- **Recommendation**: Would you recommend keeping this research meta-rule?
+
+## Model Implementation Checklist
+
+### Before Research Tasks
+
+- [ ] **Research Diagnostic**: Ensure systematic investigation methodology
+- [ ] **Type Safety Guide**: Prepare for code analysis if needed
+- [ ] **Application Context**: Load relevant platform and context information
+- [ ] **Version Control**: Prepare for history analysis if needed
+
+### During Research Execution
+
+- [ ] **Systematic Approach**: Follow structured investigation methodology
+- [ ] **Evidence Collection**: Gather comprehensive and validated evidence
+- [ ] **Documentation**: Record all findings and observations
+- [ ] **Context Awareness**: Consider application and platform context
+
+### After Research Completion
+
+- [ ] **Validation**: Verify all research phases completed
+- [ ] **Quality Check**: Ensure research meets quality standards
+- [ ] **Documentation Review**: Confirm research properly documented
+- [ ] **Feedback Collection**: Note any issues with research process
+
+---
+
+**See also**:
+
+- `.cursor/rules/meta_core_always_on.mdc` for core always-on rules
+- `.cursor/rules/meta_feature_planning.mdc` for feature development workflows
+- `.cursor/rules/meta_bug_diagnosis.mdc` for bug investigation workflows
+- `.cursor/rules/meta_bug_fixing.mdc` for fix implementation workflows
+
+**Status**: Active research meta-rule
+**Priority**: High (applies to all research tasks)
+**Estimated Effort**: Ongoing reference
+**Dependencies**: All bundled sub-rules
+**Stakeholders**: Development team, Research team, Quality Assurance team
+description:
+globs:
+alwaysApply: false
+---

.cursor/rules/meta_rule_architecture.md

@@ -0,0 +1,103 @@
+# Meta-Rule Architecture Overview
+
+**Author**: Matthew Raymer
+**Date**: 2025-01-27
+**Status**: 📋 **ACTIVE** - Meta-rule organization and relationships
+
+## Meta-Rule Structure
+
+### **Core Always-On Rules** (`meta_core_always_on.mdc`)
+- **Purpose**: Applied to every single prompt
+- **Scope**: Human competence, time standards, version control, application context
+- **Priority**: Critical - foundation for all interactions
+
+### **Enhanced Research Workflows** (`meta_research.mdc`) ⭐ **NEW**
+- **Purpose**: Applied to research, investigation, and analysis tasks
+- **Scope**: Systematic investigation, evidence collection, root cause analysis
+- **Priority**: High - applies to all research tasks
+- **Bundles**: Research diagnostic, type safety, version control research, platform context
+
+### **Feature Development Workflows** (`meta_feature_planning.mdc`)
+- **Purpose**: Applied to feature planning and development tasks
+- **Scope**: Requirements analysis, architecture planning, implementation strategy
+- **Priority**: High - applies to feature development
+
+### **Bug Investigation Workflows** (`meta_bug_diagnosis.mdc`)
+- **Purpose**: Applied to bug investigation and diagnosis tasks
+- **Scope**: Defect analysis, evidence collection, root cause identification
+- **Priority**: High - applies to bug investigation
+
+### **Bug Fixing Workflows** (`meta_bug_fixing.mdc`)
+- **Purpose**: Applied to bug fixing and resolution tasks
+- **Scope**: Fix implementation, testing, validation
+- **Priority**: High - applies to bug resolution
+
+## Research Meta-Rule Integration
+
+### **When to Use Research Meta-Rule**
+
+The research meta-rule should be applied when:
+- **Investigating bugs** - systematic defect analysis
+- **Researching solutions** - feasibility and alternative analysis
+- **Analyzing codebases** - architecture and dependency research
+- **Collecting evidence** - systematic data gathering
+- **Root cause analysis** - systematic problem investigation
+- **Impact assessment** - scope and consequence evaluation
+
+### **How It Complements Other Meta-Rules**
+
+- **Core Always-On**: Provides foundation (competence, time, context)
+- **Research**: Adds systematic investigation methodology
+- **Feature Planning**: Guides feasibility research and analysis
+- **Bug Diagnosis**: Provides investigation framework
+- **Bug Fixing**: Informs fix strategy through research
+
+### **Research Workflow Phases**
+
+1. **Investigation Setup** - Scope, context, methodology
+2. **Evidence Collection** - Systematic data gathering
+3. **Analysis & Synthesis** - Pattern recognition, root cause
+4. **Conclusion & Action** - Evidence-based recommendations
+
+## Usage Examples
+
+### **Bug Investigation**
+```
+Apply: meta_core_always_on + meta_research + meta_bug_diagnosis
+Result: Systematic investigation with evidence collection and root cause analysis
+```
+
+### **Feature Research**
+```
+Apply: meta_core_always_on + meta_research + meta_feature_planning
+Result: Comprehensive feasibility research with platform context
+```
+
+### **Architecture Analysis**
+```
+Apply: meta_core_always_on + meta_research
+Result: Systematic architecture investigation with evidence-based conclusions
+```
+
+## Benefits of Enhanced Research Meta-Rule
+
+- **Systematic Approach**: Structured investigation methodology
+- **Evidence-Based**: Comprehensive data collection and validation
+- **Quality Standards**: Defined research quality criteria
+- **Integration**: Seamless integration with existing workflows
+- **Documentation**: Comprehensive research documentation standards
+
+## Next Steps
+
+1. **Test Research Meta-Rule** - Apply to next research task
+2. **Validate Integration** - Ensure smooth workflow integration
+3. **Collect Feedback** - Gather effectiveness ratings
+4. **Iterate** - Refine based on usage experience
+
+---
+
+**Status**: Active documentation
+**Priority**: Medium
+**Estimated Effort**: Ongoing reference
+**Dependencies**: All meta-rules
+**Stakeholders**: Development team, Research team

.cursor/rules/realistic_time_estimation.mdc

@@ -1,348 +0,0 @@
----
-description: when generating text that has project task work estimates
-alwaysApply: false
----
-# No Time Estimates — Harbor Pilot Directive
-
-> **Agent role**: **DO NOT MAKE TIME ESTIMATES**. Instead, use phases, milestones, and complexity levels. Time estimates are consistently wrong and create unrealistic expectations.
-
-## 🎯 Purpose
-
-Development time estimates are consistently wrong and create unrealistic expectations. This rule ensures we focus on phases, milestones, and complexity rather than trying to predict specific timeframes.
-
-## 🚨 Critical Rule
-
-**DO NOT MAKE TIME ESTIMATES**
-- **Never provide specific time estimates** - they are always wrong
-- **Use phases and milestones** instead of days/weeks
-- **Focus on complexity and dependencies** rather than time
-- **Set expectations based on progress, not deadlines**
-
-## 📊 Planning Framework (Not Time Estimates)
-
-### **Complexity Categories**
-- **Simple**: Text changes, styling updates, minor bug fixes
-- **Medium**: New features, refactoring, component updates
-- **Complex**: Architecture changes, integrations, cross-platform work
-- **Unknown**: New technologies, APIs, or approaches
-
-### **Platform Complexity**
-- **Single platform**: Web-only or mobile-only changes
-- **Two platforms**: Web + mobile or web + desktop
-- **Three platforms**: Web + mobile + desktop
-- **Cross-platform consistency**: Ensuring behavior matches across all platforms
-
-### **Testing Complexity**
-- **Basic**: Unit tests for new functionality
-- **Comprehensive**: Integration tests, cross-platform testing
-- **User acceptance**: User testing, feedback integration
-
-## 🔍 Planning Process (No Time Estimates)
-
-### **Step 1: Break Down the Work**
-- Identify all subtasks and dependencies
-- Group related work into logical phases
-- Identify critical path and blockers
-
-### **Step 2: Define Phases and Milestones**
-- **Phase 1**: Foundation work (basic fixes, core functionality)
-- **Phase 2**: Enhancement work (new features, integrations)
-- **Phase 3**: Polish work (testing, user experience, edge cases)
-
-### **Step 3: Identify Dependencies**
-- **Technical dependencies**: What must be built first
-- **Platform dependencies**: What works on which platforms
-- **Testing dependencies**: What can be tested when
-
-### **Step 4: Set Progress Milestones**
-- **Milestone 1**: Basic functionality working
-- **Milestone 2**: All platforms supported
-- **Milestone 3**: Fully tested and polished
-
-## 📋 Planning Checklist (No Time Estimates)
-
-- [ ] Work broken down into logical phases
-- [ ] Dependencies identified and mapped
-- [ ] Milestones defined with clear criteria
-- [ ] Complexity levels assigned to each phase
-- [ ] Platform requirements identified
-- [ ] Testing strategy planned
-- [ ] Risk factors identified
-- [ ] Success criteria defined
-
-## 🎯 Example Planning (No Time Estimates)
-
-### **Example 1: Simple Feature**
-```
-Phase 1: Core implementation
-- Basic functionality
-- Single platform support
-- Unit tests
-
-Phase 2: Platform expansion
-- Multi-platform support
-- Integration tests
-
-Phase 3: Polish
-- User testing
-- Edge case handling
-```
-
-### **Example 2: Complex Cross-Platform Feature**
-```
-Phase 1: Foundation
-- Architecture design
-- Core service implementation
-- Basic web platform support
-
-Phase 2: Platform Integration
-- Mobile platform support
-- Desktop platform support
-- Cross-platform consistency
-
-Phase 3: Testing & Polish
-- Comprehensive testing
-- Error handling
-- User experience refinement
-```
-
-## 🚫 Anti-Patterns to Avoid
-
-- **"This should take X days"** - Red flag for time estimation
-- **"Just a few hours"** - Ignores complexity and testing
-- **"Similar to X"** - Without considering differences
-- **"Quick fix"** - Nothing is ever quick in software
-- **"No testing needed"** - Testing always takes effort
-
-## ✅ Best Practices
-
-### **When Planning:**
-1. **Break down everything** - no work is too small to plan
-2. **Consider all platforms** - web, mobile, desktop differences
-3. **Include testing strategy** - unit, integration, and user testing
-4. **Account for unknowns** - there are always surprises
-5. **Focus on dependencies** - what blocks what
-
-### **When Presenting Plans:**
-1. **Show the phases** - explain the logical progression
-2. **Highlight dependencies** - what could block progress
-3. **Define milestones** - clear success criteria
-4. **Identify risks** - what could go wrong
-5. **Suggest alternatives** - ways to reduce scope or complexity
-
-## 🔄 Continuous Improvement
-
-### **Track Progress**
-- Record planned vs. actual phases completed
-- Identify what took longer than expected
-- Learn from complexity misjudgments
-- Adjust planning process based on experience
-
-### **Learn from Experience**
-- **Underestimated complexity**: Increase complexity categories
-- **Missed dependencies**: Improve dependency mapping
-- **Platform surprises**: Better platform research upfront
-
-## 🎯 Integration with Harbor Pilot
-
-This rule works in conjunction with:
-- **Project Planning**: Focuses on phases and milestones
-- **Resource Allocation**: Based on complexity, not time
-- **Risk Management**: Identifies blockers and dependencies
-- **Stakeholder Communication**: Sets progress-based expectations
-
-## 📝 Version History
-
-### v2.0.0 (2025-08-21)
-- **Major Change**: Completely removed time estimation approach
-- **New Focus**: Phases, milestones, and complexity-based planning
-- **Eliminated**: All time multipliers, estimates, and calculations
-- **Added**: Dependency mapping and progress milestone framework
-
-### v1.0.0 (2025-08-21)
-- Initial creation based on user feedback about estimation accuracy
-- ~~Established realistic estimation multipliers and process~~
-- ~~Added comprehensive estimation checklist and examples~~
-- Integrated with Harbor Pilot planning and risk management
-
----
-
-## 🚨 Remember
-
-**DO NOT MAKE TIME ESTIMATES. Use phases, milestones, and complexity instead. Focus on progress, not deadlines.**
-
-## 🚨 Remember
-
-**Your first estimate is wrong. Your second estimate is probably still wrong. Focus on progress, not deadlines.**
-# No Time Estimates — Harbor Pilot Directive
-
-> **Agent role**: **DO NOT MAKE TIME ESTIMATES**. Instead, use phases, milestones, and complexity levels. Time estimates are consistently wrong and create unrealistic expectations.
-
-## 🎯 Purpose
-
-Development time estimates are consistently wrong and create unrealistic expectations. This rule ensures we focus on phases, milestones, and complexity rather than trying to predict specific timeframes.
-
-## 🚨 Critical Rule
-
-**DO NOT MAKE TIME ESTIMATES**
-- **Never provide specific time estimates** - they are always wrong
-- **Use phases and milestones** instead of days/weeks
-- **Focus on complexity and dependencies** rather than time
-- **Set expectations based on progress, not deadlines**
-
-## 📊 Planning Framework (Not Time Estimates)
-
-### **Complexity Categories**
-- **Simple**: Text changes, styling updates, minor bug fixes
-- **Medium**: New features, refactoring, component updates
-- **Complex**: Architecture changes, integrations, cross-platform work
-- **Unknown**: New technologies, APIs, or approaches
-
-### **Platform Complexity**
-- **Single platform**: Web-only or mobile-only changes
-- **Two platforms**: Web + mobile or web + desktop
-- **Three platforms**: Web + mobile + desktop
-- **Cross-platform consistency**: Ensuring behavior matches across all platforms
-
-### **Testing Complexity**
-- **Basic**: Unit tests for new functionality
-- **Comprehensive**: Integration tests, cross-platform testing
-- **User acceptance**: User testing, feedback integration
-
-## 🔍 Planning Process (No Time Estimates)
-
-### **Step 1: Break Down the Work**
-- Identify all subtasks and dependencies
-- Group related work into logical phases
-- Identify critical path and blockers
-
-### **Step 2: Define Phases and Milestones**
-- **Phase 1**: Foundation work (basic fixes, core functionality)
-- **Phase 2**: Enhancement work (new features, integrations)
-- **Phase 3**: Polish work (testing, user experience, edge cases)
-
-### **Step 3: Identify Dependencies**
-- **Technical dependencies**: What must be built first
-- **Platform dependencies**: What works on which platforms
-- **Testing dependencies**: What can be tested when
-
-### **Step 4: Set Progress Milestones**
-- **Milestone 1**: Basic functionality working
-- **Milestone 2**: All platforms supported
-- **Milestone 3**: Fully tested and polished
-
-## 📋 Planning Checklist (No Time Estimates)
-
-- [ ] Work broken down into logical phases
-- [ ] Dependencies identified and mapped
-- [ ] Milestones defined with clear criteria
-- [ ] Complexity levels assigned to each phase
-- [ ] Platform requirements identified
-- [ ] Testing strategy planned
-- [ ] Risk factors identified
-- [ ] Success criteria defined
-
-## 🎯 Example Planning (No Time Estimates)
-
-### **Example 1: Simple Feature**
-```
-Phase 1: Core implementation
-- Basic functionality
-- Single platform support
-- Unit tests
-
-Phase 2: Platform expansion
-- Multi-platform support
-- Integration tests
-
-Phase 3: Polish
-- User testing
-- Edge case handling
-```
-
-### **Example 2: Complex Cross-Platform Feature**
-```
-Phase 1: Foundation
-- Architecture design
-- Core service implementation
-- Basic web platform support
-
-Phase 2: Platform Integration
-- Mobile platform support
-- Desktop platform support
-- Cross-platform consistency
-
-Phase 3: Testing & Polish
-- Comprehensive testing
-- Error handling
-- User experience refinement
-```
-
-## 🚫 Anti-Patterns to Avoid
-
-- **"This should take X days"** - Red flag for time estimation
-- **"Just a few hours"** - Ignores complexity and testing
-- **"Similar to X"** - Without considering differences
-- **"Quick fix"** - Nothing is ever quick in software
-- **"No testing needed"** - Testing always takes effort
-
-## ✅ Best Practices
-
-### **When Planning:**
-1. **Break down everything** - no work is too small to plan
-2. **Consider all platforms** - web, mobile, desktop differences
-3. **Include testing strategy** - unit, integration, and user testing
-4. **Account for unknowns** - there are always surprises
-5. **Focus on dependencies** - what blocks what
-
-### **When Presenting Plans:**
-1. **Show the phases** - explain the logical progression
-2. **Highlight dependencies** - what could block progress
-3. **Define milestones** - clear success criteria
-4. **Identify risks** - what could go wrong
-5. **Suggest alternatives** - ways to reduce scope or complexity
-
-## 🔄 Continuous Improvement
-
-### **Track Progress**
-- Record planned vs. actual phases completed
-- Identify what took longer than expected
-- Learn from complexity misjudgments
-- Adjust planning process based on experience
-
-### **Learn from Experience**
-- **Underestimated complexity**: Increase complexity categories
-- **Missed dependencies**: Improve dependency mapping
-- **Platform surprises**: Better platform research upfront
-
-## 🎯 Integration with Harbor Pilot
-
-This rule works in conjunction with:
-- **Project Planning**: Focuses on phases and milestones
-- **Resource Allocation**: Based on complexity, not time
-- **Risk Management**: Identifies blockers and dependencies
-- **Stakeholder Communication**: Sets progress-based expectations
-
-## 📝 Version History
-
-### v2.0.0 (2025-08-21)
-- **Major Change**: Completely removed time estimation approach
-- **New Focus**: Phases, milestones, and complexity-based planning
-- **Eliminated**: All time multipliers, estimates, and calculations
-- **Added**: Dependency mapping and progress milestone framework
-
-### v1.0.0 (2025-08-21)
-- Initial creation based on user feedback about estimation accuracy
-- ~~Established realistic estimation multipliers and process~~
-- ~~Added comprehensive estimation checklist and examples~~
-- Integrated with Harbor Pilot planning and risk management
-
----
-
-## 🚨 Remember
-
-**DO NOT MAKE TIME ESTIMATES. Use phases, milestones, and complexity instead. Focus on progress, not deadlines.**
-
-## 🚨 Remember
-
-**Your first estimate is wrong. Your second estimate is probably still wrong. Focus on progress, not deadlines.**

.cursor/rules/templates/adr_template.mdc

@@ -1,3 +1,7 @@
+---
+alwaysApply: false
+---
+
 # ADR Template
 
 ## ADR-XXXX-YY-ZZ: [Short Title]
@@ -11,37 +15,47 @@
 
 [Describe the forces at play, including technological, political, social, and
 project local. These forces are probably in tension, and should be called out as
-such. The language in this section is value-neutral. It is simply describing facts.]
+such. The language in this section is value-neutral. It is simply describing
+  facts.]
 
 ## Decision
 
-[Describe our response to these forces. We will use the past tense ("We will...").]
+[Describe our response to these forces. We will use the past tense (
+  "We will...").]
 
 ## Consequences
 
 ### Positive
+
 - [List positive consequences]
 
 ### Negative
+
 - [List negative consequences or trade-offs]
 
 ### Neutral
+
 - [List neutral consequences or notes]
 
 ## Alternatives Considered
 
 - **Alternative 1:** [Description] - [Why rejected]
+
 - **Alternative 2:** [Description] - [Why rejected]
+
 - **Alternative 3:** [Description] - [Why rejected]
 
 ## Implementation Notes
 
-[Any specific implementation details, migration steps, or technical considerations]
+[Any specific implementation details, migration steps, or
+  technical considerations]
 
 ## References
 
 - [Link to relevant documentation]
+
 - [Link to related ADRs]
+
 - [Link to external resources]
 
 ## Related Decisions
@@ -59,7 +73,26 @@ such. The language in this section is value-neutral. It is simply describing fac
 5. **Link to related issues** and documentation
 6. **Update status** as decisions evolve
 7. **Store in** `doc/architecture-decisions/` directory
-description:
-globs:
-alwaysApply: false
----
+
+## Model Implementation Checklist
+
+### Before ADR Creation
+
+- [ ] **Decision Context**: Understand the decision that needs to be made
+- [ ] **Stakeholder Identification**: Identify all decision makers
+- [ ] **Research**: Research alternatives and gather evidence
+- [ ] **Template Selection**: Choose appropriate ADR template
+
+### During ADR Creation
+
+- [ ] **Context Documentation**: Document the context and forces at play
+- [ ] **Decision Recording**: Record the decision and rationale
+- [ ] **Consequences Analysis**: Analyze positive, negative, and neutral consequences
+- [ ] **Alternatives Documentation**: Document alternatives considered
+
+### After ADR Creation
+
+- [ ] **Review**: Review ADR with stakeholders
+- [ ] **Approval**: Get approval from decision makers
+- [ ] **Communication**: Communicate decision to team
+- [ ] **Implementation**: Plan implementation of the decision

.cursor/rules/workflow/commit_messages.mdc

@@ -0,0 +1,196 @@
+# Commit Message Format and Templates
+
+> **Agent role**:
+  Reference this file for commit message formatting and templates.
+
+## Commit Message Format (Normative)
+
+### A. Subject Line (required)
+
+```
+
+<type>(<scope>)<!>: <summary>
+
+```
+
+- **type** (lowercase, Conventional Commits):
+
+  `feat|fix|refactor|perf|docs|test|build|chore|ci|revert`
+
+- **scope**: optional module/package/area (e.g., `api`, `ui/login`, `db`)
+
+- **!**: include when a breaking change is introduced
+
+- **summary**: imperative mood, ≤ 72 chars, no trailing period
+
+**Examples**
+
+- `fix(api): handle null token in refresh path`
+
+- `feat(ui/login)!: require OTP after 3 failed attempts`
+
+### B. Body (optional, when it adds non-obvious value)
+
+- One blank line after subject.
+
+- Wrap at ~72 chars.
+
+- Explain **what** and **why**, not line-by-line "how".
+
+- Include brief notes like tests passing or TS/lint issues resolved
+
+  **only if material**.
+
+**Body checklist**
+
+- [ ] Problem/symptom being addressed
+
+- [ ] High-level approach or rationale
+
+- [ ] Risks, tradeoffs, or follow-ups (if any)
+
+### C. Footer (optional)
+
+- Issue refs: `Closes #123`, `Refs #456`
+
+- Breaking change (alternative to `!`):
+
+  `BREAKING CHANGE: <impact + migration note>`
+
+- Authors: `Co-authored-by: Name <email>`
+
+- Security: `CVE-XXXX-YYYY: <short note>` (if applicable)
+
+## Content Guidance
+
+### Include (when relevant)
+
+- Specific fixes/features delivered
+
+- Symptoms/problems fixed
+
+- Brief note that tests passed or TS/lint errors resolved
+
+### Avoid
+
+- Vague: *improved, enhanced, better*
+
+- Trivialities: tiny docs, one-liners, pure lint cleanups (separate,
+
+  focused commits if needed)
+
+- Redundancy: generic blurbs repeated across files
+
+- Multi-purpose dumps: keep commits **narrow and focused**
+
+- Long explanations that good inline code comments already cover
+
+**Guiding Principle:** Let code and inline docs speak. Use commits to
+highlight what isn't obvious.
+
+## Copy-Paste Templates
+
+### Minimal (no body)
+
+```text
+
+<type>(<scope>): <summary>
+
+```
+
+### Standard (with body & footer)
+
+```text
+
+<type>(<scope>)<!>: <summary>
+
+<why-this-change?>
+<what-it-does?>
+<risks-or-follow-ups?>
+
+Closes #<id>
+BREAKING CHANGE: <impact + migration>
+Co-authored-by: <Name> <email>
+
+```
+
+## Type Descriptions
+
+### feat
+
+New feature for the user
+
+### fix
+
+Bug fix for the user
+
+### docs
+
+Documentation only changes
+
+### style
+
+Changes that do not affect the meaning of the code
+
+### refactor
+
+Code change that neither fixes a bug nor adds a feature
+
+### perf
+
+Code change that improves performance
+
+### test
+
+Adding missing tests or correcting existing tests
+
+### build
+
+Changes that affect the build system or external dependencies
+
+### ci
+
+Changes to CI configuration files and scripts
+
+### chore
+
+Other changes that don't modify src or test files
+
+---
+
+**See also**:
+
+- `.cursor/rules/workflow/version_control.mdc` for
+
+  core version control principles
+
+- `.cursor/rules/workflow/version_sync.mdc` for version synchronization details
+
+**Status**: Active commit message guidelines
+**Priority**: High
+**Estimated Effort**: Ongoing reference
+**Dependencies**: version_control.mdc
+**Stakeholders**: Development team, AI assistants
+
+## Model Implementation Checklist
+
+### Before Creating Commits
+
+- [ ] **Change Review**: Review all changes to be committed
+- [ ] **Scope Assessment**: Determine if changes belong in single or multiple commits
+- [ ] **Message Planning**: Plan clear, descriptive commit message
+- [ ] **Convention Check**: Review commit message format requirements
+
+### During Commit Creation
+
+- [ ] **Type Selection**: Choose appropriate commit type (feat, fix, docs, etc.)
+- [ ] **Message Writing**: Write clear, concise commit message
+- [ ] **Body Content**: Add detailed description if needed
+- [ ] **Breaking Changes**: Document breaking changes with `!` and migration notes
+
+### After Commit Creation
+
+- [ ] **Message Review**: Verify commit message follows conventions
+- [ ] **Change Validation**: Confirm all intended changes are included
+- [ ] **Documentation**: Update any related documentation
+- [ ] **Team Communication**: Communicate significant changes to team

.cursor/rules/workflow/version_control.mdc

@@ -1,155 +1,41 @@
----
-description: interacting with git
-alwaysApply: false
----
 # Directive: Peaceful Co-Existence with Developers
 
 **Author**: Matthew Raymer
 **Date**: 2025-08-19
 **Status**: 🎯 **ACTIVE** - Version control guidelines
 
-## 1) Version-Control Ownership
+## Core Principles
+### 0) let the developer control git
+### 1) Version-Control Ownership
 
 - **MUST NOT** run `git add`, `git commit`, or any write action.
 - **MUST** leave staging/committing to the developer.
 
-## 2) Source of Truth for Commit Text
+### 2) Source of Truth for Commit Text
 
 - **MUST** derive messages **only** from:
+
   - files **staged** for commit (primary), and
   - files **awaiting staging** (context).
+
 - **MUST** use the **diffs** to inform content.
 - **MUST NOT** invent changes or imply work not present in diffs.
 
-## 3) Mandatory Preview Flow
+### 3) Mandatory Preview Flow
 
 - **ALWAYS** present, before any real commit:
+
   - file list + brief per-file notes,
   - a **draft commit message** (copy-paste ready),
   - nothing auto-applied.
 
-## 4) Version Synchronization Requirements
+### 4) Version Synchronization Requirements
 
 - **MUST** check for version changes in `package.json` before committing
-- **MUST** ensure `CHANGELOG.md` is updated when `package.json` version
-  changes
+- **MUST** ensure `CHANGELOG.md` is updated when `package.json` version changes
 - **MUST** validate version format consistency between both files
-- **MUST** include version bump commits in changelog with proper semantic
-  versioning
-
-### Version Sync Checklist (Before Commit)
-
-- [ ] `package.json` version matches latest `CHANGELOG.md` entry
-- [ ] New version follows semantic versioning
-  (MAJOR.MINOR.PATCH[-PRERELEASE])
-- [ ] Changelog entry includes all significant changes since last version
-- [ ] Version bump commit message follows `build(version): bump to X.Y.Z`
-  format
-- [ ] Breaking changes properly documented with migration notes
-- [ ] Alert developer in chat message that version has been updated
-
-### Version Change Detection
-
-- **Check for version changes** in staged/unstaged `package.json`
-- **Alert developer** if version changed but changelog not updated
-- **Suggest changelog update** with proper format and content
-- **Validate semantic versioning** compliance
-
-### Implementation Notes
-
-- **Version Detection**: Compare `package.json` version field with latest
-  changelog entry
-- **Semantic Validation**: Ensure version follows `X.Y.Z[-PRERELEASE]`
-  format
-- **Changelog Format**: Follow [Keep a Changelog](https://keepachangelog.com/)
-  standards
-- **Breaking Changes**: Use `!` in commit message and `BREAKING CHANGE:`
-  in changelog
-- **Pre-release Versions**: Include beta/alpha/rc suffixes in both files
-  consistently
-
-## Commit Message Format (Normative)
-
-### A. Subject Line (required)
-
-```
-<type>(<scope>)<!>: <summary>
-```
-
-- **type** (lowercase, Conventional Commits):
-  `feat|fix|refactor|perf|docs|test|build|chore|ci|revert`
-- **scope**: optional module/package/area (e.g., `api`, `ui/login`, `db`)
-- **!**: include when a breaking change is introduced
-- **summary**: imperative mood, ≤ 72 chars, no trailing period
-
-**Examples**
-
-- `fix(api): handle null token in refresh path`
-- `feat(ui/login)!: require OTP after 3 failed attempts`
-
-### B. Body (optional, when it adds non-obvious value)
-
-- One blank line after subject.
-- Wrap at ~72 chars.
-- Explain **what** and **why**, not line-by-line "how".
-- Include brief notes like tests passing or TS/lint issues resolved
-  **only if material**.
-
-**Body checklist**
-
-- [ ] Problem/symptom being addressed
-- [ ] High-level approach or rationale
-- [ ] Risks, tradeoffs, or follow-ups (if any)
-
-### C. Footer (optional)
-
-- Issue refs: `Closes #123`, `Refs #456`
-- Breaking change (alternative to `!`):
-  `BREAKING CHANGE: <impact + migration note>`
-- Authors: `Co-authored-by: Name <email>`
-- Security: `CVE-XXXX-YYYY: <short note>` (if applicable)
-
-## Content Guidance
-
-### Include (when relevant)
-
-- Specific fixes/features delivered
-- Symptoms/problems fixed
-- Brief note that tests passed or TS/lint errors resolved
-
-### Avoid
-
-- Vague: *improved, enhanced, better*
-- Trivialities: tiny docs, one-liners, pure lint cleanups (separate,
-  focused commits if needed)
-- Redundancy: generic blurbs repeated across files
-- Multi-purpose dumps: keep commits **narrow and focused**
-- Long explanations that good inline code comments already cover
-
-**Guiding Principle:** Let code and inline docs speak. Use commits to
-highlight what isn't obvious.
-
-## Copy-Paste Templates
-
-### Minimal (no body)
-
-```text
-<type>(<scope>): <summary>
-```
-
-### Standard (with body & footer)
-
-```text
-<type>(<scope>)<!>: <summary>
-
-<why-this-change?>
-<what-it-does?>
-<risks-or-follow-ups?>
-
-Closes #<id>
-BREAKING CHANGE: <impact + migration>
-Co-authored-by: <Name> <email>
-```
+- **MUST** include version bump commits in changelog with
+  proper semantic versioning
 
 ## Assistant Output Checklist (before showing the draft)
 
@@ -159,177 +45,42 @@ Co-authored-by: <Name> <email>
 - [ ] Body only if it adds non-obvious value
 - [ ] No invented changes; aligns strictly with diffs
 - [ ] Render as a single copy-paste block for the developer
+- [ ] No invented changes; aligns strictly with diffs
+- [ ] Render as a single copy-paste block for the developer
 
 ---
 
+**See also**:
+
+- `.cursor/rules/workflow/commit_messages.mdc` for commit message format and
+  templates
+- `.cursor/rules/workflow/version_sync.mdc` for version synchronization details
+
 **Status**: Active version control guidelines
 **Priority**: High
 **Estimated Effort**: Ongoing reference
 **Dependencies**: git, package.json, CHANGELOG.md
 **Stakeholders**: Development team, AI assistants
 
-- [ ] No invented changes; aligns strictly with diffs
-- [ ] Render as a single copy-paste block for the developer
+## Model Implementation Checklist
 
-## 1) Version-Control Ownership
+### Before Version Control Work
 
-- **MUST NOT** run `git add`, `git commit`, or any write action.
-- **MUST** leave staging/committing to the developer.
+- [ ] **File Analysis**: Review files staged and awaiting staging
+- [ ] **Version Check**: Check for version changes in package.json
+- [ ] **Changelog Review**: Verify CHANGELOG.md is updated if version changed
+- [ ] **Diff Analysis**: Analyze actual changes from git diffs
 
-## 2) Source of Truth for Commit Text
+### During Version Control Work
 
-- **MUST** derive messages **only** from:
-  - files **staged** for commit (primary), and
-  - files **awaiting staging** (context).
-- **MUST** use the **diffs** to inform content.
-- **MUST NOT** invent changes or imply work not present in diffs.
+- [ ] **Commit Preview**: Present file list with brief notes per file
+- [ ] **Message Draft**: Provide focused draft commit message
+- [ ] **Format Validation**: Ensure message follows type(scope)! syntax
+- [ ] **Version Sync**: Validate version consistency between files
 
-## 3) Mandatory Preview Flow
+### After Version Control Work
 
-- **ALWAYS** present, before any real commit:
-  - file list + brief per-file notes,
-  - a **draft commit message** (copy-paste ready),
-  - nothing auto-applied.
-
-## 4) Version Synchronization Requirements
-
-- **MUST** check for version changes in `package.json` before committing
-- **MUST** ensure `CHANGELOG.md` is updated when `package.json` version
-  changes
-- **MUST** validate version format consistency between both files
-- **MUST** include version bump commits in changelog with proper semantic
-  versioning
-
-### Version Sync Checklist (Before Commit)
-
-- [ ] `package.json` version matches latest `CHANGELOG.md` entry
-- [ ] New version follows semantic versioning
-  (MAJOR.MINOR.PATCH[-PRERELEASE])
-- [ ] Changelog entry includes all significant changes since last version
-- [ ] Version bump commit message follows `build(version): bump to X.Y.Z`
-  format
-- [ ] Breaking changes properly documented with migration notes
-- [ ] Alert developer in chat message that version has been updated
-
-### Version Change Detection
-
-- **Check for version changes** in staged/unstaged `package.json`
-- **Alert developer** if version changed but changelog not updated
-- **Suggest changelog update** with proper format and content
-- **Validate semantic versioning** compliance
-
-### Implementation Notes
-
-- **Version Detection**: Compare `package.json` version field with latest
-  changelog entry
-- **Semantic Validation**: Ensure version follows `X.Y.Z[-PRERELEASE]`
-  format
-- **Changelog Format**: Follow [Keep a Changelog](https://keepachangelog.com/)
-  standards
-- **Breaking Changes**: Use `!` in commit message and `BREAKING CHANGE:`
-  in changelog
-- **Pre-release Versions**: Include beta/alpha/rc suffixes in both files
-  consistently
-
-## Commit Message Format (Normative)
-
-### A. Subject Line (required)
-
-```
-<type>(<scope>)<!>: <summary>
-```
-
-- **type** (lowercase, Conventional Commits):
-  `feat|fix|refactor|perf|docs|test|build|chore|ci|revert`
-- **scope**: optional module/package/area (e.g., `api`, `ui/login`, `db`)
-- **!**: include when a breaking change is introduced
-- **summary**: imperative mood, ≤ 72 chars, no trailing period
-
-**Examples**
-
-- `fix(api): handle null token in refresh path`
-- `feat(ui/login)!: require OTP after 3 failed attempts`
-
-### B. Body (optional, when it adds non-obvious value)
-
-- One blank line after subject.
-- Wrap at ~72 chars.
-- Explain **what** and **why**, not line-by-line "how".
-- Include brief notes like tests passing or TS/lint issues resolved
-  **only if material**.
-
-**Body checklist**
-
-- [ ] Problem/symptom being addressed
-- [ ] High-level approach or rationale
-- [ ] Risks, tradeoffs, or follow-ups (if any)
-
-### C. Footer (optional)
-
-- Issue refs: `Closes #123`, `Refs #456`
-- Breaking change (alternative to `!`):
-  `BREAKING CHANGE: <impact + migration note>`
-- Authors: `Co-authored-by: Name <email>`
-- Security: `CVE-XXXX-YYYY: <short note>` (if applicable)
-
-## Content Guidance
-
-### Include (when relevant)
-
-- Specific fixes/features delivered
-- Symptoms/problems fixed
-- Brief note that tests passed or TS/lint errors resolved
-
-### Avoid
-
-- Vague: *improved, enhanced, better*
-- Trivialities: tiny docs, one-liners, pure lint cleanups (separate,
-  focused commits if needed)
-- Redundancy: generic blurbs repeated across files
-- Multi-purpose dumps: keep commits **narrow and focused**
-- Long explanations that good inline code comments already cover
-
-**Guiding Principle:** Let code and inline docs speak. Use commits to
-highlight what isn't obvious.
-
-## Copy-Paste Templates
-
-### Minimal (no body)
-
-```text
-<type>(<scope>): <summary>
-```
-
-### Standard (with body & footer)
-
-```text
-<type>(<scope>)<!>: <summary>
-
-<why-this-change?>
-<what-it-does?>
-<risks-or-follow-ups?>
-
-Closes #<id>
-BREAKING CHANGE: <impact + migration>
-Co-authored-by: <Name> <email>
-```
-
-## Assistant Output Checklist (before showing the draft)
-
-- [ ] List changed files + 1–2 line notes per file
-- [ ] Provide **one** focused draft message (subject/body/footer)
-- [ ] Subject ≤ 72 chars, imperative mood, correct `type(scope)!` syntax
-- [ ] Body only if it adds non-obvious value
-- [ ] No invented changes; aligns strictly with diffs
-- [ ] Render as a single copy-paste block for the developer
-
----
-
-**Status**: Active version control guidelines
-**Priority**: High
-**Estimated Effort**: Ongoing reference
-**Dependencies**: git, package.json, CHANGELOG.md
-**Stakeholders**: Development team, AI assistants
-
-* [ ] No invented changes; aligns strictly with diffs
-* [ ] Render as a single copy-paste block for the developer
+- [ ] **Developer Control**: Leave staging/committing to developer
+- [ ] **Message Validation**: Verify message aligns strictly with diffs
+- [ ] **Version Validation**: Confirm version format consistency
+- [ ] **Documentation**: Update relevant version control documentation

.cursor/rules/workflow/version_sync.mdc

@@ -0,0 +1,176 @@
+# Version Synchronization and Changelog Management
+
+> **Agent role**: Reference this file for version synchronization
+> requirements and changelog management.
+
+## Version Sync Checklist (Before Commit)
+
+- [ ] `package.json` version matches latest `CHANGELOG.md` entry
+- [ ] New version follows semantic versioning
+  (MAJOR.MINOR.PATCH[-PRERELEASE])
+- [ ] Changelog entry includes all significant changes since last version
+- [ ] Version bump commit message follows `build(version): bump to X.Y.Z`
+  format
+- [ ] Breaking changes properly documented with migration notes
+- [ ] Alert developer in chat message that version has been updated
+
+## Version Change Detection
+
+- **Check for version changes** in staged/unstaged `package.json`
+- **Alert developer** if version changed but changelog not updated
+- **Suggest changelog update** with proper format and content
+- **Validate semantic versioning** compliance
+
+## Implementation Notes
+
+### Version Detection
+
+- Compare `package.json` version field with latest changelog entry
+- Use semantic versioning validation
+- Check for pre-release version consistency
+
+### Semantic Validation
+
+- Ensure version follows `X.Y.Z[-PRERELEASE]` format
+- Validate major.minor.patch components
+- Handle pre-release suffixes (beta, alpha, rc)
+
+### Changelog Format
+
+- Follow [Keep a Changelog](https://keepachangelog.com/) standards
+- Use consistent section headers
+- Include breaking change notes
+- Maintain chronological order
+
+### Breaking Changes
+
+- Use `!` in commit message
+- Include `BREAKING CHANGE:` in changelog
+- Provide migration notes
+- Document impact clearly
+
+### Pre-release Versions
+
+- Include beta/alpha/rc suffixes consistently
+- Update both `package.json` and changelog
+- Maintain version number alignment
+- Document pre-release status
+
+## Changelog Sections
+
+### Added
+
+- New features
+- New capabilities
+- New dependencies
+
+### Changed
+
+- Changes in existing functionality
+- API changes
+- Performance improvements
+
+### Deprecated
+
+- Soon-to-be removed features
+- Migration paths
+- Sunset timelines
+
+### Removed
+
+- Removed features
+- Breaking changes
+- Deprecated items
+
+### Fixed
+
+- Bug fixes
+- Security patches
+- Performance fixes
+
+### Security
+
+- Security vulnerabilities
+- CVE references
+- Mitigation steps
+
+## Version Bump Guidelines
+
+### Patch (X.Y.Z+1)
+
+- Bug fixes
+- Documentation updates
+- Minor improvements
+
+### Minor (X.Y+1.Z)
+
+- New features
+- Backward-compatible changes
+- Significant improvements
+
+### Major (X+1.Y.Z)
+
+- Breaking changes
+- Major API changes
+- Incompatible changes
+
+## Pre-release Guidelines
+
+### Beta Versions
+
+- Feature complete
+- Testing phase
+- API stable
+
+### Alpha Versions
+
+- Early development
+- API may change
+- Limited testing
+
+### Release Candidates
+
+- Final testing
+- API frozen
+- Production ready
+
+---
+
+**See also**:
+
+- `.cursor/rules/workflow/version_control.mdc` for core version
+  control principles
+- `.cursor/rules/workflow/commit_messages.mdc` for commit message
+  format
+
+**Status**: Active version synchronization guide
+**Priority**: High
+**Estimated Effort**: Ongoing reference
+**Dependencies**: version_control.mdc
+**Stakeholders**: Development team, Release team
+
+## Model Implementation Checklist
+
+### Before Version Changes
+
+- [ ] **Version Review**: Check current version in `package.json` and `CHANGELOG.md`
+- [ ] **Change Assessment**: Identify what type of version bump is needed (patch/minor/major)
+- [ ] **Breaking Changes**: Review if any changes are breaking and require
+  major version
+- [ ] **Pre-release Status**: Determine if this should be a pre-release version
+
+### During Version Synchronization
+
+- [ ] **Semantic Validation**: Ensure version follows `X.Y.Z[-PRERELEASE]` format
+- [ ] **Package Update**: Update `package.json` version field
+- [ ] **Changelog Entry**: Add entry to `CHANGELOG.md` following Keep a Changelog
+  format
+- [ ] **Breaking Changes**: Document breaking changes with migration notes
+  if applicable
+
+### After Version Changes
+
+- [ ] **Commit Format**: Use `build(version): bump to X.Y.Z` commit message format
+- [ ] **Developer Alert**: Alert developer that version has been updated
+- [ ] **Validation**: Verify `package.json` and `CHANGELOG.md` are in sync
+- [ ] **Pre-release Handling**: Ensure pre-release versions are consistently formatted

.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*
@@ -51,6 +54,12 @@ vendor/
 # Build logs
 build_logs/
 
+# Guard feedback logs (for continuous improvement analysis)
+.guard-feedback.log
+
+# Workflow state file (contains dynamic state, not version controlled)
+.cursor/rules/.workflow_state.json
+
 # PWA icon files generated by capacitor-assets
 icons
 
@@ -140,4 +149,5 @@ electron/out/
 # Gradle cache files
 android/.gradle/file-system.probe
 android/.gradle/caches/
-coverage
+coverage
+.husky-enabled

.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
+"

.husky/pre-commit

@@ -1,15 +1,68 @@
 #!/usr/bin/env bash
 #
 # Husky Pre-commit Hook
-# Runs Build Architecture Guard to check staged files
+# Runs lint-fix and Build Architecture Guard on staged files
 #
 . "$(dirname -- "$0")/_/husky.sh"
 
-echo "🔍 Running Build Architecture Guard (pre-commit)..."
-bash ./scripts/build-arch-guard.sh --staged || {
+echo "🔍 Running pre-commit hooks..."
+
+# Run lint-fix first
+echo "📝 Running lint-fix..."
+
+# Capture git status before lint-fix to detect changes
+git_status_before=$(git status --porcelain)
+
+npm run lint-fix || {
     echo
+    echo "❌ Linting failed. Please fix the issues and try again."
     echo "💡 To bypass this check for emergency commits, use:"
     echo "   git commit --no-verify"
     echo
     exit 1
 }
+
+# Check if lint-fix made any changes
+git_status_after=$(git status --porcelain)
+
+if [ "$git_status_before" != "$git_status_after" ]; then
+    echo
+    echo "⚠️  lint-fix made changes to your files!"
+    echo "📋 Changes detected:"
+    git diff --name-only
+    echo
+    echo "❓ What would you like to do?"
+    echo "   [c] Continue commit without the new changes"
+    echo "   [a] Abort commit (recommended - review and stage the changes)"
+    echo
+    printf "Choose [c/a]: "
+    # The `< /dev/tty` is necessary to make read work in git's non-interactive shell
+    read choice < /dev/tty
+    
+    case $choice in
+        [Cc]* )
+            echo "✅ Continuing commit without lint-fix changes..."
+            sleep 3
+            ;;
+        [Aa]* | * )
+            echo "🛑 Commit aborted. Please review the changes made by lint-fix."
+            echo "💡 You can stage the changes with 'git add .' and commit again."
+            exit 1
+            ;;
+    esac
+fi
+
+# Then run Build Architecture Guard
+
+#echo "🏗️  Running Build Architecture Guard..."
+#bash ./scripts/build-arch-guard.sh --staged || {
+#    echo
+#    echo "❌ Build Architecture Guard failed. Please fix the issues and try again."
+#    echo "💡 To bypass this check for emergency commits, use:"
+#    echo "   git commit --no-verify"
+#    echo
+#    exit 1
+#}
+
+echo "✅ All pre-commit checks passed!"
+

.husky/pre-push

@@ -18,10 +18,10 @@ else
     RANGE="HEAD~1..HEAD"
 fi
 
-bash ./scripts/build-arch-guard.sh --range "$RANGE" || {
-    echo
-    echo "💡 To bypass this check for emergency pushes, use:"
-    echo "   git push --no-verify"
-    echo
-    exit 1
-}
+#bash ./scripts/build-arch-guard.sh --range "$RANGE" || {
+#    echo
+#    echo "💡 To bypass this check for emergency pushes, use:"
+#    echo "   git push --no-verify"
+#    echo
+#    exit 1
+#}

.markdownlint-cli2.jsonc

@@ -0,0 +1,53 @@
+{
+  // Markdownlint configuration for TimeSafari .cursor/rules
+  "config": {
+    // Core formatting rules that can be auto-fixed
+    "MD013": {
+      "line_length": 80,
+      "code_blocks": false,
+      "tables": false,
+      "headings": false
+    },
+    "MD012": true,  // No multiple consecutive blank lines
+    "MD022": true,  // Headings should be surrounded by blank lines
+    "MD031": true,  // Fenced code blocks should be surrounded by blank lines
+    "MD032": true,  // Lists should be surrounded by blank lines
+    "MD047": true,  // Files should end with a single newline
+    "MD009": true,  // No trailing spaces
+    "MD010": true,  // No hard tabs
+    "MD004": { "style": "dash" },  // Consistent list markers
+    "MD029": { "style": "ordered" },  // Ordered list item prefix
+    
+    // Disable rules that conflict with existing content structure
+    "MD041": false,  // First line heading requirement
+    "MD025": false,  // Multiple top-level headings
+    "MD024": false,  // Duplicate headings
+    "MD036": false,  // Emphasis as headings
+    "MD003": false,  // Heading style consistency
+    "MD040": false,  // Fenced code language
+    "MD055": false,  // Table pipe style
+    "MD056": false,  // Table column count
+    "MD034": false,  // Bare URLs
+    "MD023": false   // Heading indentation
+  },
+  
+  "globs": [
+    ".cursor/rules/**/*.mdc",
+    "*.md",
+    "*.markdown",
+    "scripts/**/*.md",
+    "src/**/*.md",
+    "test-playwright/**/*.md",
+    "resources/**/*.md",
+    "doc/**/*.md",
+    "ios/**/*.md",
+    "electron/**/*.md"
+  ],
+  "ignores": [
+    "node_modules/**",
+    ".git/**",
+    "**/node_modules/**",
+    "**/dist/**",
+    "**/build/**"
+  ]
+}

.markdownlint.json

@@ -1 +1,27 @@
-{"MD013": {"code_blocks": false}}
+{
+  "MD013": {
+    "line_length": 80,
+    "code_blocks": false,
+    "tables": false,
+    "headings": false
+  },
+  "MD012": true,
+  "MD022": true,
+  "MD031": true,
+  "MD032": true,
+  "MD047": true,
+  "MD009": true,
+  "MD010": true,
+  "MD004": { "style": "dash" },
+  "MD029": { "style": "ordered" },
+  "MD041": false,
+  "MD025": false,
+  "MD024": false,
+  "MD036": false,
+  "MD003": false,
+  "MD040": false,
+  "MD055": false,
+  "MD056": false,
+  "MD034": false,
+  "MD023": false
+}

.npmrc

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

BUILDING.md

@@ -78,6 +78,79 @@ npm run build:android:prod     # Android production build
 npm run build:electron:prod    # Electron production build
 ```
 
+### Build Architecture Guard
+
+The Build Architecture Guard protects your build system by enforcing documentation updates when build-critical files are modified. This ensures that all build changes are properly documented in `BUILDING.md`.
+
+#### How It Works
+
+- **Pre-commit Hook**: Automatically checks staged files before each commit
+- **Protected Files**: Build scripts, config files, and platform-specific code
+- **Documentation Requirement**: `BUILDING.md` must be updated alongside build changes
+- **Automatic Enforcement**: Git hooks prevent commits without proper documentation
+- **Feedback Collection**: Continuously improves through usage pattern analysis
+
+#### Protected File Patterns
+
+The guard monitors these sensitive paths:
+- `vite.config.*` - Build configuration
+- `scripts/**` - Build and utility scripts
+- `electron/**` - Desktop application code
+- `android/**` - Android platform code
+- `ios/**` - iOS platform code
+- `capacitor.config.ts` - Mobile configuration
+- `capacitor-assets.config.json` - Android asset configuration
+- `resources/**` - Source assets for Android resource generation
+- `package.json` - Dependencies and scripts
+
+#### Enhanced Android Protection
+
+The guard now provides enhanced protection for Android build system changes:
+
+- **Asset Validation**: Protects `validate_android_assets()` function and resource paths
+- **Resource Generation**: Monitors `capacitor-assets` integration and verification
+- **API Routing**: Protects platform-specific IP handling (emulator vs physical device)
+- **Build Modes**: Validates development/test/production mode handling
+- **Resource Fallback**: Protects automatic regeneration of missing Android resources
+
+#### Using the Guard
+
+```bash
+# Test the guard locally
+./scripts/build-arch-guard.sh --staged
+
+# Analyze guard effectiveness (for maintainers)
+./scripts/build-arch-guard.sh --feedback
+
+# Bypass for emergency commits (use sparingly)
+git commit --no-verify
+
+# Setup the guard
+npm run guard:setup
+```
+
+#### Troubleshooting
+
+If you encounter `mapfile: command not found` errors:
+```bash
+# Ensure script is executable
+chmod +x scripts/build-arch-guard.sh
+
+# Test the script
+./scripts/build-arch-guard.sh --help
+```
+
+#### Feedback and Continuous Improvement
+
+The guard system includes feedback mechanisms for continuous improvement:
+
+- **Automatic Logging**: All guard executions are logged for analysis
+- **Pattern Analysis**: Identifies false positives/negatives and missing patterns
+- **Maintainer Insights**: Use `--feedback` command to analyze guard effectiveness
+- **Continuous Updates**: Guard rules and patterns are updated based on feedback
+
+**Note**: The guard is active and will block commits that modify build files without updating `BUILDING.md`. Recent enhancements provide better Android build system protection and feedback collection for continuous improvement.
+
 ### Environment Configuration
 
 #### Quick Environment Setup
@@ -102,28 +175,11 @@ cp .env.example .env.development
 
 ### Troubleshooting Quick Fixes
 
-#### Common Issues
-
-```bash
-# Clean and rebuild
-npm run clean:all
-npm install
-npm run build:web:dev
-
-# Reset mobile projects
-npm run clean:ios
-npm run clean:android
-npm run build:ios              # Regenerates iOS project
-npm run build:android          # Regenerates Android project
-
-# Check environment
-npm run test:web               # Verifies web setup
-```
-
 #### Platform-Specific Issues
 
 - **iOS**: Ensure Xcode and Command Line Tools are installed
 - **Android**: Ensure Android Studio and SDK are configured
+  - If you encounter "resource drawable/splash not found" errors, run `npm run assets:validate:android`
 - **Electron**: Ensure platform-specific build tools are installed
 
 ### Next Steps
@@ -140,7 +196,7 @@ npm run test:web               # Verifies web setup
 
 - 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
@@ -174,7 +230,7 @@ npm run build:web:dev               # Start development server with hot reload
 npm run build:web                   # Development build (starts dev server with hot reload)
 npm run build:web:test              # Test environment build (optimized for testing)
 npm run build:web:prod              # Production build (optimized for production)
-npm run build:web:serve             # Build and serve locally (builds then serves)
+npm run build:web:serve             # Build and serve locally for production testing
 
 # Docker builds
 npm run build:web:docker            # Development build with Docker containerization
@@ -192,6 +248,12 @@ Start the development server using `npm run build:web:dev` or `npm run build:web
 2. The built files will be in the `dist` directory
 3. To test the production build locally, use `npm run build:web:serve` (builds then serves)
 
+**Why Use `serve`?**
+- **Production Testing**: Test your optimized production build locally before deployment
+- **SPA Routing Validation**: Verify deep linking and navigation work correctly (handles routes like `/discover`, `/account`)
+- **Performance Testing**: Test the minified and optimized build locally
+- **Deployment Validation**: Ensure built files work correctly when served by a real HTTP server
+
 You'll likely want to use test locations for the Endorser & image & partner servers; see "DEFAULT_ENDORSER_API_SERVER" & "DEFAULT_IMAGE_API_SERVER" & "DEFAULT_PARTNER_API_SERVER" below.
 
 ### Web Build Script Details
@@ -211,7 +273,7 @@ All web build commands use the `./scripts/build-web.sh` script, which provides:
 - **Clean Build**: Removes previous `dist/` directory
 - **Vite Build**: Executes `npx vite build --config vite.config.web.mts`
 - **Docker Support**: Optional Docker containerization
-- **Local Serving**: Built-in HTTP server for testing builds
+- **Local Serving**: Built-in HTTP server for testing builds with SPA routing support
 
 **Direct Script Usage:**
 
@@ -247,6 +309,25 @@ All web build commands use the `./scripts/build-web.sh` script, which provides:
 - `5` - Serve command failed
 - `6` - Invalid build mode
 
+### Local Serving with `serve`
+
+The `serve` functionality provides a local HTTP server for testing production builds:
+
+**What It Does:**
+1. **Builds** the application using Vite
+2. **Serves** the built files from the `dist/` directory
+3. **Handles SPA Routing** - serves `index.html` for all routes (fixes 404s on `/discover`, `/account`, etc.)
+
+**Server Options:**
+- **Primary**: `npx serve -s dist -l 8080` (recommended - full SPA support)
+- **Fallback**: Python HTTP server (limited SPA routing support)
+
+**Use Cases:**
+- Testing production builds before deployment
+- Validating SPA routing behavior
+- Performance testing of optimized builds
+- Debugging production build issues locally
+
 ### Compile and minify for test & production
 
 - If there are DB changes: before updating the test server, open browser(s) with
@@ -267,17 +348,10 @@ current version to test DB migrations.
 [online](https://gitea.anomalistdesign.com/trent_larson/crowd-funder-for-time-pwa/releases) or 
 `git tag 1.0.2 && git push origin 1.0.2`.
 
-- For test, build the app (because test server is not yet set up to build):
+- For test, build the app:
 
 ```bash
-TIME_SAFARI_APP_TITLE="TimeSafari_Test" \
-VITE_APP_SERVER=https://test.timesafari.app \
-VITE_BVC_MEETUPS_PROJECT_CLAIM_ID=https://endorser.ch/entity/01HWE8FWHQ1YGP7GFZYYPS272F \
-VITE_DEFAULT_ENDORSER_API_SERVER=https://test-api.endorser.ch \
-VITE_DEFAULT_IMAGE_API_SERVER=https://test-image-api.timesafari.app \
-VITE_DEFAULT_PARTNER_API_SERVER=https://test-partner-api.endorser.ch \
-VITE_DEFAULT_PUSH_SERVER=https://test.timesafari.app \
-VITE_PASSKEYS_ENABLED=true npm run build:web
+npm run build:web:test
 ```
 
 ... and transfer to the test server:
@@ -290,20 +364,19 @@ rsync -azvu -e "ssh -i ~/.ssh/..." dist ubuntutest@test.timesafari.app:time-safa
 
 (Note: The test BVC_MEETUPS_PROJECT_CLAIM_ID does not resolve as a URL because it's only in the test DB and the prod redirect won't redirect there.)
 
-- For prod, get on the server and run the correct build:
+- For prod, you can do the same with `build:web:prod` instead.
 
-... and log onto the server:
+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`
 
-- `cd crowd-funder-for-time-pwa && git checkout master && git pull && git checkout
-1.0.2 && npm install && npm run build:web:prod && cd -`
+- `cd crowd-funder-for-time-pwa && git checkout master && git pull && git checkout 1.0.2 && npm install && npm run build:web:prod && cd -`
 
 (The plain `npm run build:web:prod` uses the .env.production file.)
 
 - 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
@@ -522,7 +595,8 @@ The Electron build process follows a multi-stage approach:
 #### **Stage 2: Capacitor Sync**
 
 - Copies web assets to Electron app directory
-- Syncs Capacitor configuration and plugins
+- Uses Electron-specific Capacitor configuration (not copied from main config)
+- Syncs Capacitor plugins for Electron platform
 - Prepares native module bindings
 
 #### **Stage 3: TypeScript Compile**
@@ -973,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)
 
@@ -1046,37 +1120,38 @@ If you need to build manually or want to understand the individual steps:
 
 - Generate certificates inside XCode.
 - Right-click on App and under Signing & Capabilities set the Team.
+- In the App Developer setup (eg. https://developer.apple.com/account), under Identifiers and/or "Certificates, Identifiers & Profiles"
 
 #### Each Release
 
 ##### 0. First time (or if dependencies change)
 
-- `pkgx +rubygems.org sh`
+- `pkgx +rubygems.org zsh`
 
 - ... and you may have to fix these, especially with pkgx:
 
-   ```bash
-   gem_path=$(which gem)
-   shortened_path="${gem_path:h:h}"
-   export GEM_HOME=$shortened_path
-   export GEM_PATH=$shortened_path
-   ```
+```bash
+gem_path=$(which gem)
+shortened_path="${gem_path:h:h}"
+export GEM_HOME=$shortened_path
+export GEM_PATH=$shortened_path
+```
 
-##### 1. Bump the version in package.json, then here
+##### 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 40 && perl -p -i -e "s/MARKETING_VERSION = .*;/MARKETING_VERSION = 1.0.7;/g" App.xcodeproj/project.pbxproj && cd -
-   # Unfortunately this edits Info.plist directly.
-   #xcrun agvtool new-marketing-version 0.4.5
-   ```
+```bash
+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
+```
 
 ##### 2. Build
 
-  Here's prod. Also available: test, dev
+Here's prod. Also available: test, dev
 
-  ```bash
-  npm run build:ios:prod
-  ```
+```bash
+npm run build:ios:prod
+```
 
 3.1. Use Xcode to build and run on simulator or device.
 
@@ -1101,11 +1176,133 @@ If you need to build manually or want to understand the individual steps:
   - It can take 15 minutes for the build to show up in the list of builds.
   - You'll probably have to "Manage" something about encryption, disallowed in France.
   - Then "Save" and "Add to Review" and "Resubmit to App Review".
-- Eventually it'll be "Ready for Distribution" which means
+- Eventually it'll be "Ready for Distribution" which means it's live
+- When finished, bump package.json version
 
 ### 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
 
@@ -1136,6 +1333,69 @@ npm run build:android:assets         # Generate assets only
 npm run build:android:deploy         # Build and deploy to connected device
 ```
 
+#### Android Asset Validation
+
+The Android build system now includes automatic asset validation to prevent build failures caused by missing resources. This system:
+
+- **Validates Source Assets**: Checks that required source files exist in `resources/`
+- **Checks Android Resources**: Verifies that generated Android resources are present
+- **Auto-Regenerates**: Automatically regenerates missing resources when detected
+- **Provides Clear Errors**: Gives helpful guidance when issues occur
+
+##### Asset Validation Commands
+
+```bash
+# Validate and regenerate Android assets if needed
+npm run assets:validate:android
+
+# Alternative command for asset validation
+./scripts/build-android.sh --assets-only
+
+# Check asset configuration only (no regeneration)
+npm run assets:validate
+```
+
+##### What Gets Validated
+
+**Source Assets (Required):**
+- `resources/icon.png` - App icon source
+- `resources/splash.png` - Splash screen source  
+- `resources/splash_dark.png` - Dark mode splash source
+
+**Android Resources (Generated):**
+- `android/app/src/main/res/drawable/splash.png` - Splash screen drawable
+- `android/app/src/main/res/mipmap-*/ic_launcher.png` - App icons for all densities
+- `android/app/src/main/res/mipmap-*/ic_launcher_round.png` - Round app icons for all densities
+
+##### Automatic Validation
+
+Asset validation runs automatically during all Android builds:
+
+```bash
+# All these commands now include asset validation
+npm run build:android:studio
+npm run build:android:prod
+npm run build:android:debug
+```
+
+If validation fails, the build stops with clear error messages and guidance on how to fix the issues.
+
+##### Troubleshooting Asset Issues
+
+If you encounter asset-related build failures:
+
+```bash
+# Check what's missing
+npm run assets:validate:android
+
+# Clean and regenerate everything
+npm run clean:android
+npm run assets:validate:android
+npm run build:android:studio
+```
+
+For more detailed information, see [Android Asset Validation Documentation](doc/android-asset-validation.md).
+
 #### Android Automated Build Script
 
 The recommended way to build for Android is using the automated build script:
@@ -1144,8 +1404,8 @@ The recommended way to build for Android is using the automated build script:
 # Standard build and open Android Studio
 ./scripts/build-android.sh
 
-# Build with specific version numbers
-./scripts/build-android.sh --version 1.0.3 --build-number 35
+# Build with specific version numbers -- doesn't change source files
+#./scripts/build-android.sh --version 1.1.3 --build-number 48
 
 # Build without opening Android Studio (for CI/CD)
 ./scripts/build-android.sh --no-studio
@@ -1156,26 +1416,26 @@ The recommended way to build for Android is using the automated build script:
 
 #### Android Manual Build Process
 
-##### 1. Bump the version in package.json, then here: android/app/build.gradle
+##### 1. Bump the version in package.json, then update these versions & run:
 
-  ```bash
-  perl -p -i -e 's/versionCode .*/versionCode 40/g' android/app/build.gradle
-  perl -p -i -e 's/versionName .*/versionName "1.0.7"/g' android/app/build.gradle
-  ```
+```bash
+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
 
   Here's prod. Also available: test, dev
 
-  ```bash
-  npm run build:android:prod
-  ```
+```bash
+npm run build:android:prod
+```
 
 ##### 3. Open the project in Android Studio
 
-   ```bash
-   npx cap open android
-   ```
+```bash
+npx cap open android
+```
 
 ##### 4. Use Android Studio to build and run on emulator or device
 
@@ -1220,6 +1480,8 @@ At play.google.com/console:
 - Note that if you add testers, you have to go to "Publishing Overview" and send
   those changes or your (closed) testers won't see it.
 
+- When finished, bump package.json version
+
 ### Capacitor Operations
 
 ```bash
@@ -1547,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)
 
 ---
 
@@ -2174,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'),
@@ -2183,7 +2447,7 @@ export async function createBuildConfig(platform: string): Promise<UserConfig> {
     },
     optimizeDeps: {
       include: [
-        '@nostr/tools',
+        'nostr-tools',
         '@jlongster/sql.js',
         'absurd-sql',
         // ... additional dependencies
@@ -2208,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
@@ -2348,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"]
           }
         }
@@ -2539,3 +2803,116 @@ All scripts use consistent error handling:
 **Note**: This documentation is maintained alongside the build system. For the
 most up-to-date information, refer to the actual script files and Vite
 configuration files in the repository.
+
+---
+
+## Build Changes Changelog
+
+### 2025-08-21 - Cursor Rules Refactoring and Build System Updates
+
+#### Package Dependencies Updated
+- **Added**: `markdownlint-cli2` v0.18.1 - Modern markdown linting with improved performance
+- **Added**: `@commitlint/cli` v18.6.1 - Conventional commit message validation
+- **Added**: `@commitlint/config-conventional` v18.6.2 - Conventional commit standards
+- **Updated**: `husky` v9.0.11 - Git hooks management
+- **Updated**: `lint-staged` v15.2.2 - Pre-commit linting automation
+
+#### Build Script Improvements
+- **Markdown Linting**: Replaced custom markdown scripts with `markdownlint-cli2`
+  - **Before**: `./scripts/fix-markdown.sh` and `./scripts/validate-markdown.sh`
+  - **After**: `markdownlint-cli2 --fix` and `markdownlint-cli2`
+  - **Benefits**: Faster execution, better error reporting, modern markdown standards
+
+#### Lint-Staged Configuration Enhanced
+- **Added**: Markdown file linting to pre-commit hooks
+  - **Pattern**: `*.{md,markdown,mdc}` files now automatically formatted
+  - **Command**: `markdownlint-cli2 --fix` runs before each commit
+  - **Coverage**: All markdown files including `.mdc` cursor rules
+
+#### Commit Message Standards
+- **Added**: Conventional commit validation via commitlint
+- **Configuration**: Extends `@commitlint/config-conventional`
+- **Enforcement**: Ensures consistent commit message format across the project
+
+#### Node.js Version Requirements
+- **Updated**: Minimum Node.js version requirements for new dependencies
+- **markdownlint-cli2**: Requires Node.js >=20
+- **Various utilities**: Require Node.js >=18 for modern ES features
+
+#### Build Process Impact
+- **No Breaking Changes**: All existing build commands continue to work
+- **Improved Quality**: Better markdown formatting and commit message standards
+- **Enhanced Automation**: More comprehensive pre-commit validation
+- **Performance**: Faster markdown linting with modern tooling
+
+---
+
+### 2025-08-21 - Commitlint Configuration Refinement
+
+#### Commit Message Validation Improvements
+- **Modified**: Commitlint configuration moved from `package.json` to dedicated `commitlint.config.js`
+- **Enhanced**: Strict validation rules downgraded from errors to warnings
+  - **Before**: `subject-case` and `subject-full-stop` rules caused red error messages
+  - **After**: Same rules now show yellow warnings without blocking commits
+- **Benefit**: Eliminates confusing red error messages while maintaining commit quality guidance
+
+#### Configuration Structure
+- **File**: `commitlint.config.js` - Dedicated commitlint configuration
+- **Extends**: `@commitlint/config-conventional` - Standard conventional commit rules
+- **Custom Rules**: 
+  - `subject-case: [1, 'never', ['sentence-case', 'start-case', 'pascal-case', 'upper-case']]`
+  - `subject-full-stop: [1, 'never', '.']`
+- **Levels**: 
+  - `0` = Disabled, `1` = Warning, `2` = Error
+  - Current: Problematic rules set to warning level (1)
+
+#### User Experience Impact
+- **Before**: Red error messages on every push with strict commit rules
+- **After**: Yellow warning messages that provide guidance without disruption
+- **Workflow**: Commits and pushes continue to work while maintaining quality standards
+- **Feedback**: Developers still receive helpful commit message guidance
+
+---
+
+### 2025-08-26 - Capacitor Plugin Additions
+
+#### New Capacitor Plugins Added
+- **Added**: `@capacitor/clipboard` v6.0.2 - Clipboard functionality for mobile platforms
+  - **Purpose**: Enable copy/paste operations on mobile devices
+  - **Platforms**: iOS and Android
+  - **Features**: Read/write clipboard content, text handling
+  - **Integration**: Automatically included in mobile builds
+
+- **Added**: `@capacitor/status-bar` v6.0.2 - Status bar management for mobile platforms
+  - **Purpose**: Control mobile device status bar appearance and behavior
+  - **Platforms**: iOS and Android
+  - **Features**: Status bar styling, visibility control, color management
+  - **Integration**: Automatically included in mobile builds
+
+#### Android Build System Updates
+- **Modified**: `android/capacitor.settings.gradle` - Added new plugin project includes
+  - **Added**: `:capacitor-clipboard` project directory mapping
+  - **Added**: `:capacitor-status-bar` project directory mapping
+  - **Impact**: New plugins now properly integrated into Android build process
+
+#### Package Dependencies
+- **Updated**: `package.json` - Added new Capacitor plugin dependencies
+- **Updated**: `package-lock.json` - Locked dependency versions for consistency
+- **Version**: All new plugins use Capacitor 6.x compatible versions
+
+#### Build Process Impact
+- **No Breaking Changes**: Existing build commands continue to work unchanged
+- **Enhanced Mobile Features**: New clipboard and status bar capabilities available
+- **Automatic Integration**: Plugins automatically included in mobile builds
+- **Platform Support**: Both iOS and Android builds now include new functionality
+
+#### Testing Requirements
+- **Mobile Builds**: Verify new plugins integrate correctly in iOS and Android builds
+- **Functionality**: Test clipboard operations and status bar management on devices
+- **Fallback**: Ensure graceful degradation when plugins are unavailable
+
+---
+
+**Note**: This documentation is maintained alongside the build system. For the
+most up-to-date information, refer to the actual script files and Vite
+configuration files in the repository.

CHANGELOG.md

@@ -5,6 +5,84 @@ All notable changes to this project will be documented in this file.
 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
+
+
+## [1.1.4] - 2025.12.18
+### Fixed
+- Contact notes & contact methods preserved in export
+### Added
+- This is a target for sharing
+- Switch to a project or person in give-dialog pop-up
+- Starred projects onto project-choice in give-dialog pop-up
+### Changed
+- Front page: 1 green "Thank" button
+
+
+## [1.1.3] - 2025.11.19
+### Changed
+- Project selection in dialogs now reaches out to server when filtering
+- Project selection during onboarding meeting is a search (not an input box)
+- Improve the switching of agent when agent edits a project
+### Fixed
+- Reassignment of "you" as recipient when changing giver project
+- Bad counts for project-change notification on front page
+
+
+## [1.1.2] - 2025.11.06
+### Fixed
+- Bad page when user follows prompt to backup seed
+
+
+## [1.1.1] - 2025.11.03
+
+### Added
+- Meeting onboarding via prompts
+- Emojis on gift feed
+- Starred projects with notification
+
+
 ## [1.0.7] - 2025.08.18
 
 ### Fixed

CODE_QUALITY_DEEP_ANALYSIS.md

@@ -0,0 +1,852 @@
+# TimeSafari Code Quality: Comprehensive Deep Analysis
+
+**Author**: Matthew Raymer  
+**Date**: Tue Sep 16 05:22:10 AM UTC 2025  
+**Status**: 🎯 **COMPREHENSIVE ANALYSIS** - Complete code quality assessment with actionable recommendations
+
+## Executive Summary
+
+The TimeSafari codebase demonstrates **exceptional code quality** with mature patterns, minimal technical debt, and excellent separation of concerns. This comprehensive analysis covers **291 source files** totaling **104,527 lines** of code, including detailed examination of **94 Vue components and views**.
+
+**Key Quality Metrics:**
+- **Technical Debt**: Extremely low (6 TODO/FIXME comments across entire codebase)
+- **Database Migration**: 99.5% complete (1 remaining legacy import)
+- **File Complexity**: High variance (largest file: 2,215 lines)
+- **Type Safety**: Mixed patterns (41 "as any" assertions in Vue files, 62 total)
+- **Error Handling**: Comprehensive (367 catch blocks with good coverage)
+- **Architecture**: Consistent Vue 3 Composition API with TypeScript
+
+## Vue Components & Views Analysis (94 Files)
+
+### Component Analysis (40 Components)
+
+#### Component Size Distribution
+```
+Large Components (>500 lines): 5 components (12.5%)
+├── ImageMethodDialog.vue (947 lines) 🔴 CRITICAL
+├── GiftedDialog.vue (670 lines) ⚠️ HIGH PRIORITY  
+├── PhotoDialog.vue (669 lines) ⚠️ HIGH PRIORITY
+├── PushNotificationPermission.vue (660 lines) ⚠️ HIGH PRIORITY
+└── MeetingMembersList.vue (550 lines) ⚠️ MODERATE PRIORITY
+
+Medium Components (200-500 lines): 12 components (30%)
+├── GiftDetailsStep.vue (450 lines)
+├── EntityGrid.vue (348 lines)
+├── ActivityListItem.vue (334 lines)
+├── OfferDialog.vue (327 lines)
+├── OnboardingDialog.vue (314 lines)
+├── EntitySelectionStep.vue (313 lines)
+├── GiftedPrompts.vue (293 lines)
+├── ChoiceButtonDialog.vue (250 lines)
+├── DataExportSection.vue (251 lines)
+├── AmountInput.vue (224 lines)
+├── HiddenDidDialog.vue (220 lines)
+└── FeedFilters.vue (218 lines)
+
+Small Components (<200 lines): 23 components (57.5%)
+├── ContactListItem.vue (217 lines)
+├── EntitySummaryButton.vue (202 lines)
+├── IdentitySection.vue (186 lines)
+├── ContactInputForm.vue (173 lines)
+├── SpecialEntityCard.vue (156 lines)
+├── RegistrationNotice.vue (154 lines)
+├── ContactNameDialog.vue (154 lines)
+├── PersonCard.vue (153 lines)
+├── UserNameDialog.vue (147 lines)
+├── InfiniteScroll.vue (132 lines)
+├── LocationSearchSection.vue (124 lines)
+├── UsageLimitsSection.vue (123 lines)
+├── QuickNav.vue (118 lines)
+├── ProjectCard.vue (104 lines)
+├── ContactListHeader.vue (101 lines)
+├── TopMessage.vue (98 lines)
+├── InviteDialog.vue (95 lines)
+├── ImageViewer.vue (94 lines)
+├── EntityIcon.vue (86 lines)
+├── ShowAllCard.vue (66 lines)
+├── ContactBulkActions.vue (53 lines)
+├── ProjectIcon.vue (47 lines)
+└── LargeIdenticonModal.vue (44 lines)
+```
+
+#### Critical Component Analysis
+
+**1. `ImageMethodDialog.vue` (947 lines) 🔴 CRITICAL REFACTORING NEEDED**
+
+**Issues Identified:**
+- **Excessive Single Responsibility**: Handles camera preview, file upload, URL input, cropping, diagnostics, and error handling
+- **Complex State Management**: 20+ reactive properties with interdependencies
+- **Mixed Concerns**: Camera API, file handling, UI state, and business logic intertwined
+- **Template Complexity**: ~300 lines of template with deeply nested conditions
+
+**Refactoring Strategy:**
+```typescript
+// Current monolithic structure
+ImageMethodDialog.vue (947 lines) {
+  CameraPreview: ~200 lines
+  FileUpload: ~150 lines  
+  URLInput: ~100 lines
+  CroppingInterface: ~200 lines
+  DiagnosticsPanel: ~150 lines
+  ErrorHandling: ~100 lines
+  StateManagement: ~47 lines
+}
+
+// Proposed component decomposition
+ImageMethodDialog.vue (coordinator, ~200 lines)
+├── CameraPreviewComponent.vue (~250 lines)
+├── FileUploadComponent.vue (~150 lines)
+├── URLInputComponent.vue (~100 lines)
+├── ImageCropperComponent.vue (~200 lines)
+├── DiagnosticsPanelComponent.vue (~150 lines)
+└── ImageUploadErrorHandler.vue (~100 lines)
+```
+
+**2. `GiftedDialog.vue` (670 lines) ⚠️ HIGH PRIORITY**
+
+**Assessment**: **GOOD** - Already partially refactored with step components extracted.
+
+**3. `PhotoDialog.vue` (669 lines) ⚠️ HIGH PRIORITY**
+
+**Issues**: Similar to ImageMethodDialog with significant code duplication.
+
+**4. `PushNotificationPermission.vue` (660 lines) ⚠️ HIGH PRIORITY**
+
+**Issues**: Complex permission logic with platform-specific code mixed together.
+
+### View Analysis (54 Views)
+
+#### View Size Distribution
+```
+Large Views (>1000 lines): 9 views (16.7%)
+├── AccountViewView.vue (2,215 lines) 🔴 CRITICAL
+├── HomeView.vue (1,852 lines) ⚠️ HIGH PRIORITY
+├── ProjectViewView.vue (1,479 lines) ⚠️ HIGH PRIORITY
+├── DatabaseMigration.vue (1,438 lines) ⚠️ HIGH PRIORITY
+├── ContactsView.vue (1,382 lines) ⚠️ HIGH PRIORITY
+├── TestView.vue (1,259 lines) ⚠️ MODERATE PRIORITY
+├── ClaimView.vue (1,225 lines) ⚠️ MODERATE PRIORITY
+├── NewEditProjectView.vue (957 lines) ⚠️ MODERATE PRIORITY
+└── ContactQRScanShowView.vue (929 lines) ⚠️ MODERATE PRIORITY
+
+Medium Views (500-1000 lines): 8 views (14.8%)
+├── ConfirmGiftView.vue (898 lines)
+├── DiscoverView.vue (888 lines)
+├── DIDView.vue (848 lines)
+├── GiftedDetailsView.vue (840 lines)
+├── OfferDetailsView.vue (781 lines)
+├── HelpView.vue (780 lines)
+├── ProjectsView.vue (742 lines)
+└── ContactQRScanFullView.vue (701 lines)
+
+Small Views (<500 lines): 37 views (68.5%)
+├── OnboardMeetingSetupView.vue (687 lines)
+├── ContactImportView.vue (568 lines)
+├── HelpNotificationsView.vue (566 lines)
+├── OnboardMeetingListView.vue (507 lines)
+├── InviteOneView.vue (475 lines)
+├── QuickActionBvcEndView.vue (442 lines)
+├── ContactAmountsView.vue (416 lines)
+├── SearchAreaView.vue (384 lines)
+├── SharedPhotoView.vue (379 lines)
+├── ContactGiftingView.vue (373 lines)
+├── ContactEditView.vue (345 lines)
+├── IdentitySwitcherView.vue (324 lines)
+├── UserProfileView.vue (323 lines)
+├── NewActivityView.vue (323 lines)
+├── QuickActionBvcBeginView.vue (303 lines)
+├── SeedBackupView.vue (292 lines)
+├── InviteOneAcceptView.vue (292 lines)
+├── ClaimCertificateView.vue (279 lines)
+├── StartView.vue (271 lines)
+├── ImportAccountView.vue (265 lines)
+├── ClaimAddRawView.vue (249 lines)
+├── OnboardMeetingMembersView.vue (247 lines)
+├── DeepLinkErrorView.vue (239 lines)
+├── ClaimReportCertificateView.vue (236 lines)
+├── DeepLinkRedirectView.vue (219 lines)
+├── ImportDerivedAccountView.vue (207 lines)
+├── ShareMyContactInfoView.vue (196 lines)
+├── RecentOffersToUserProjectsView.vue (176 lines)
+├── RecentOffersToUserView.vue (166 lines)
+├── NewEditAccountView.vue (142 lines)
+├── StatisticsView.vue (133 lines)
+├── HelpOnboardingView.vue (118 lines)
+├── LogView.vue (104 lines)
+├── NewIdentifierView.vue (97 lines)
+├── HelpNotificationTypesView.vue (73 lines)
+├── ConfirmContactView.vue (57 lines)
+└── QuickActionBvcView.vue (54 lines)
+```
+
+#### Critical View Analysis
+
+**1. `AccountViewView.vue` (2,215 lines) 🔴 CRITICAL REFACTORING NEEDED**
+
+**Issues Identified:**
+- **Monolithic Architecture**: Handles 7 distinct concerns in single file
+- **Template Complexity**: ~750 lines of template with deeply nested conditions
+- **Method Proliferation**: 50+ methods handling disparate concerns
+- **State Management**: 25+ reactive properties without clear organization
+
+**Refactoring Strategy:**
+```typescript
+// Current monolithic structure
+AccountViewView.vue (2,215 lines) {
+  ProfileSection: ~400 lines
+  SettingsSection: ~300 lines  
+  NotificationSection: ~200 lines
+  ServerConfigSection: ~250 lines
+  ExportImportSection: ~300 lines
+  LimitsSection: ~150 lines
+  MapSection: ~200 lines
+  StateManagement: ~415 lines
+}
+
+// Proposed component extraction
+AccountViewView.vue (coordinator, ~400 lines)
+├── ProfileManagementSection.vue (~300 lines)
+├── ServerConfigurationSection.vue (~250 lines)
+├── NotificationSettingsSection.vue (~200 lines)
+├── DataExportImportSection.vue (~300 lines)
+├── UsageLimitsDisplay.vue (~150 lines)
+├── LocationProfileSection.vue (~200 lines)
+└── AccountViewStateManager.ts (~200 lines)
+```
+
+**2. `HomeView.vue` (1,852 lines) ⚠️ HIGH PRIORITY**
+
+**Issues Identified:**
+- **Multiple Concerns**: Activity feed, projects, contacts, notifications in one file
+- **Complex State Management**: 20+ reactive properties with interdependencies
+- **Mixed Lifecycle Logic**: Mount, update, and destroy logic intertwined
+
+**3. `ProjectViewView.vue` (1,479 lines) ⚠️ HIGH PRIORITY**
+
+**Issues Identified:**
+- **Project Management Complexity**: Handles project details, members, offers, and activities
+- **Mixed Concerns**: Project data, member management, and activity feed in single view
+
+### Vue Component Quality Patterns
+
+#### Excellent Patterns Found:
+
+**1. EntityIcon.vue (86 lines) ✅ EXCELLENT**
+```typescript
+// Clean, focused responsibility
+@Component({ name: "EntityIcon" })
+export default class EntityIcon extends Vue {
+  @Prop() contact?: Contact;
+  @Prop({ default: "" }) entityId!: string;
+  @Prop({ default: 0 }) iconSize!: number;
+  
+  generateIcon(): string {
+    // Clear priority order: profile image → avatar → fallback
+    const imageUrl = this.contact?.profileImageUrl || this.profileImageUrl;
+    if (imageUrl) return `<img src="${imageUrl}" ... />`;
+    
+    const identifier = this.contact?.did || this.entityId;
+    if (!identifier) return `<img src="${blankSquareSvg}" ... />`;
+    
+    return createAvatar(avataaars, { seed: identifier, size: this.iconSize }).toString();
+  }
+}
+```
+
+**2. QuickNav.vue (118 lines) ✅ EXCELLENT**
+```typescript
+// Simple, focused navigation component
+@Component({ name: "QuickNav" })
+export default class QuickNav extends Vue {
+  @Prop selected = "";
+  
+  // Clean template with consistent patterns
+  // Proper accessibility attributes
+  // Responsive design with safe area handling
+}
+```
+
+**3. Small Focused Views ✅ EXCELLENT**
+```typescript
+// QuickActionBvcView.vue (54 lines) - Perfect size
+// ConfirmContactView.vue (57 lines) - Focused responsibility
+// HelpNotificationTypesView.vue (73 lines) - Clear purpose
+// LogView.vue (104 lines) - Simple utility view
+```
+
+#### Problematic Patterns Found:
+
+**1. Excessive Props in Dialog Components**
+```typescript
+// GiftedDialog.vue - Too many props
+@Prop() fromProjectId = "";
+@Prop() toProjectId = "";
+@Prop() isFromProjectView = false;
+@Prop() hideShowAll = false;
+@Prop({ default: "person" }) giverEntityType = "person";
+@Prop({ default: "person" }) recipientEntityType = "person";
+// ... 10+ more props
+```
+
+**2. Complex State Machines**
+```typescript
+// ImageMethodDialog.vue - Complex state management
+cameraState: "off" | "initializing" | "active" | "error" | "retrying" | "stopped" = "off";
+showCameraPreview = false;
+isRetrying = false;
+showDiagnostics = false;
+// ... 15+ more state properties
+```
+
+**3. Excessive Reactive Properties**
+```typescript
+// AccountViewView.vue - Too many reactive properties
+downloadUrl: string = "";
+loadingLimits: boolean = false;
+loadingProfile: boolean = true;
+showAdvanced: boolean = false;
+showB64Copy: boolean = false;
+showContactGives: boolean = false;
+showDidCopy: boolean = false;
+showDerCopy: boolean = false;
+showGeneralAdvanced: boolean = false;
+showLargeIdenticonId?: string;
+showLargeIdenticonUrl?: string;
+showPubCopy: boolean = false;
+showShortcutBvc: boolean = false;
+warnIfProdServer: boolean = false;
+warnIfTestServer: boolean = false;
+zoom: number = 2;
+isMapReady: boolean = false;
+// ... 10+ more properties
+```
+
+## File Size and Complexity Analysis (All Files)
+
+### Problematic Large Files
+
+#### 1. `AccountViewView.vue` (2,215 lines) 🔴 **CRITICAL**
+**Issues Identified:**
+- **Excessive Single File Responsibility**: Handles profile, settings, notifications, server configuration, export/import, limits checking
+- **Template Complexity**: ~750 lines of template with deeply nested conditions
+- **Method Proliferation**: 50+ methods handling disparate concerns
+- **State Management**: 25+ reactive properties without clear organization
+
+#### 2. `PlatformServiceMixin.ts` (2,091 lines) ⚠️ **HIGH PRIORITY**
+**Issues Identified:**
+- **God Object Pattern**: Single file handling 80+ methods across multiple concerns
+- **Mixed Abstraction Levels**: Low-level SQL utilities mixed with high-level business logic
+- **Method Length Variance**: Some methods 100+ lines, others single-line wrappers
+
+**Refactoring Strategy:**
+```typescript
+// Current monolithic mixin
+PlatformServiceMixin.ts (2,091 lines)
+
+// Proposed separation of concerns
+├── CoreDatabaseMixin.ts          // $db, $exec, $query, $first (200 lines)
+├── SettingsManagementMixin.ts    // $settings, $saveSettings (400 lines)
+├── ContactManagementMixin.ts     // $contacts, $insertContact (300 lines)
+├── EntityOperationsMixin.ts      // $insertEntity, $updateEntity (400 lines)
+├── CachingMixin.ts              // Cache management (150 lines)
+├── ActiveIdentityMixin.ts       // Active DID management (200 lines)
+├── UtilityMixin.ts              // Mapping, JSON parsing (200 lines)
+└── LoggingMixin.ts              // $log, $logError (100 lines)
+```
+
+#### 3. `HomeView.vue` (1,852 lines) ⚠️ **MODERATE PRIORITY**
+**Issues Identified:**
+- **Multiple Concerns**: Activity feed, projects, contacts, notifications in one file
+- **Complex State Management**: 20+ reactive properties with interdependencies
+- **Mixed Lifecycle Logic**: Mount, update, and destroy logic intertwined
+
+### File Size Distribution Analysis
+```
+Files > 1000 lines: 9 files (4.6% of codebase)
+Files 500-1000 lines: 23 files (11.7% of codebase)  
+Files 200-500 lines: 45 files (22.8% of codebase)
+Files < 200 lines: 120 files (60.9% of codebase)
+```
+
+**Assessment**: Good distribution with most files reasonably sized, but critical outliers need attention.
+
+## Type Safety Analysis
+
+### Type Assertion Patterns
+
+#### "as any" Usage (62 total instances) ⚠️
+
+**Vue Components & Views (41 instances):**
+```typescript
+// ImageMethodDialog.vue:504
+const activeIdentity = await (this as any).$getActiveIdentity();
+
+// GiftedDialog.vue:228  
+const activeIdentity = await (this as any).$getActiveIdentity();
+
+// AccountViewView.vue: Multiple instances for:
+// - PlatformServiceMixin method access
+// - Vue refs with complex typing
+// - External library integration (Leaflet)
+```
+
+**Other Files (21 instances):**
+- **Vue Component References** (23 instances): `(this.$refs.dialog as any)`
+- **Platform Detection** (12 instances): `(navigator as any).standalone`
+- **External Library Integration** (15 instances): Leaflet, Axios extensions
+- **Legacy Code Compatibility** (8 instances): Temporary migration code
+- **Event Handler Workarounds** (4 instances): Vue event typing issues
+
+**Example Problematic Pattern:**
+```typescript
+// src/views/AccountViewView.vue:934
+const iconDefault = L.Icon.Default.prototype as unknown as Record<string, unknown>;
+
+// Better approach:
+interface LeafletIconPrototype {
+  _getIconUrl?: unknown;
+}
+const iconDefault = L.Icon.Default.prototype as LeafletIconPrototype;
+```
+
+#### "unknown" Type Usage (755 instances)
+**Analysis**: Generally good practice showing defensive programming, but some areas could benefit from more specific typing.
+
+### Recommended Type Safety Improvements
+
+1. **Create Interface Extensions**:
+```typescript
+// src/types/platform-service-mixin.ts
+interface VueWithPlatformServiceMixin extends Vue {
+  $getActiveIdentity(): Promise<{ activeDid: string }>;
+  $saveSettings(changes: Partial<Settings>): Promise<boolean>;
+  // ... other methods
+}
+
+// src/types/external.ts
+declare global {
+  interface Navigator {
+    standalone?: boolean;
+  }
+}
+
+interface VueRefWithOpen {
+  open: (callback: (result?: unknown) => void) => void;
+}
+```
+
+2. **Component Ref Typing**:
+```typescript
+// Instead of: (this.$refs.dialog as any).open()
+// Use: (this.$refs.dialog as VueRefWithOpen).open()
+```
+
+## Error Handling Consistency Analysis
+
+### Error Handling Patterns (367 catch blocks)
+
+#### Pattern Distribution:
+1. **Structured Logging** (85%): Uses logger.error with context
+2. **User Notification** (78%): Shows user-friendly error messages  
+3. **Graceful Degradation** (92%): Provides fallback behavior
+4. **Error Propagation** (45%): Re-throws when appropriate
+
+#### Excellent Pattern Example:
+```typescript
+// src/views/AccountViewView.vue:1617
+try {
+  const response = await this.axios.delete(url, { headers });
+  if (response.status === 204) {
+    this.profileImageUrl = "";
+    this.notify.success("Image deleted successfully.");
+  }
+} catch (error) {
+  if (isApiError(error) && error.response?.status === 404) {
+    // Graceful handling - image already gone
+    this.profileImageUrl = "";
+  } else {
+    this.notify.error("Failed to delete image", TIMEOUTS.STANDARD);
+  }
+}
+```
+
+#### Areas for Improvement:
+1. **Inconsistent Error Typing**: Some catch(error: any), others catch(error: unknown)
+2. **Missing Error Boundaries**: No Vue error boundary components
+3. **Silent Failures**: 15% of catch blocks don't notify users
+
+## Code Duplication Analysis
+
+### Significant Duplication Patterns
+
+#### 1. **Toggle Component Pattern** (12 occurrences)
+```html
+<!-- Repeated across multiple files -->
+<div class="relative ml-2 cursor-pointer" @click="toggleMethod()">
+  <input v-model="property" type="checkbox" class="sr-only" />
+  <div class="block bg-slate-500 w-14 h-8 rounded-full"></div>
+  <div class="dot absolute left-1 top-1 bg-slate-400 w-6 h-6 rounded-full transition"></div>
+</div>
+```
+
+**Solution**: Create `ToggleSwitch.vue` component with props for value, label, and change handler.
+
+#### 2. **API Error Handling Pattern** (25 occurrences)
+```typescript
+try {
+  const response = await this.axios.post(url, data, { headers });
+  if (response.status === 200) {
+    this.notify.success("Operation successful");
+  }
+} catch (error) {
+  if (isApiError(error)) {
+    this.notify.error(`Failed: ${error.message}`);
+  }
+}
+```
+
+**Solution**: Create `ApiRequestMixin.ts` with standardized request/response handling.
+
+#### 3. **Settings Update Pattern** (40+ occurrences)
+```typescript
+async methodName() {
+  await this.$saveSettings({ property: this.newValue });
+  this.property = this.newValue;
+}
+```
+
+**Solution**: Enhanced PlatformServiceMixin already provides `$saveSettings()` - migrate remaining manual patterns.
+
+## Dependency and Coupling Analysis
+
+### Import Dependency Patterns
+
+#### Legacy Database Coupling (EXCELLENT)
+- **Status**: 99.5% resolved (1 remaining databaseUtil import)
+- **Remaining**: `src/views/DeepLinkErrorView.vue:import { logConsoleAndDb }`
+- **Resolution**: Replace with PlatformServiceMixin `$logAndConsole()`
+
+#### Circular Dependency Status (EXCELLENT)
+- **Status**: 100% resolved, no active circular dependencies
+- **Previous Issues**: All resolved through PlatformServiceMixin architecture
+
+#### Component Coupling Analysis
+```typescript
+// High coupling components (>10 imports)
+AccountViewView.vue: 15 imports (understandable given scope)
+HomeView.vue: 12 imports 
+ProjectViewView.vue: 11 imports
+
+// Well-isolated components (<5 imports)  
+QuickActionViews: 3-4 imports each
+Component utilities: 2-3 imports each
+```
+
+**Assessment**: Reasonable coupling levels with clear architectural boundaries.
+
+## Console Logging Analysis (129 instances)
+
+### Logging Pattern Distribution:
+1. **console.log**: 89 instances (69%)
+2. **console.warn**: 24 instances (19%)  
+3. **console.error**: 16 instances (12%)
+
+### Vue Components & Views Logging (3 instances):
+- **Components**: 1 console.* call
+- **Views**: 2 console.* calls
+
+### Inconsistent Logging Approach:
+```typescript
+// Mixed patterns found:
+console.log("Direct console logging");           // 89 instances
+logger.debug("Structured logging");              // Preferred pattern
+this.$logAndConsole("Mixin logging");           // PlatformServiceMixin
+```
+
+### Recommended Standardization:
+1. **Migration Strategy**: Replace all console.* with logger.* calls
+2. **Structured Context**: Add consistent metadata to log entries
+3. **Log Levels**: Standardize debug/info/warn/error usage
+
+## Technical Debt Analysis (6 total)
+
+### Components (1 TODO):
+```typescript
+// PushNotificationPermission.vue
+// TODO: secretDB functionality needs to be migrated to PlatformServiceMixin
+```
+
+### Views (2 TODOs):
+```typescript
+// AccountViewView.vue
+// TODO: Implement this for SQLite
+// TODO: implement this for SQLite
+```
+
+### Other Files (3 TODOs):
+```typescript
+// src/db/tables/accounts.ts
+// TODO: When finished with migration, move these fields to Account and move identity and mnemonic here.
+
+// src/util.d.ts
+// TODO: , inspect: inspect
+
+// src/libs/crypto/vc/passkeyHelpers.ts
+// TODO: If it's after February 2025 when you read this then consider whether it still makes sense
+```
+
+**Assessment**: **EXCELLENT** - Only 6 TODO comments across 291 files.
+
+## Performance Anti-Patterns
+
+### Identified Issues:
+
+#### 1. **Excessive Reactive Properties**
+```typescript
+// AccountViewView.vue has 25+ reactive properties
+// Many could be computed or moved to component state
+```
+
+#### 2. **Inline Method Calls in Templates**
+```html
+<!-- Anti-pattern: -->
+<span>{{ readableDate(timeStr) }}</span>
+
+<!-- Better: -->
+<span>{{ readableTime }}</span>
+<!-- With computed property -->
+```
+
+#### 3. **Missing Key Attributes in Lists**
+```html
+<!-- Several v-for loops missing :key attributes -->
+<li v-for="item in items">
+```
+
+#### 4. **Complex Template Logic**
+```html
+<!-- AccountViewView.vue - Complex nested conditions -->
+<div v-if="!activeDid" id="noticeBeforeShare" class="bg-amber-200...">
+  <p class="mb-4">
+    <b>Note:</b> Before you can share with others or take any action, you need an identifier.
+  </p>
+  <router-link :to="{ name: 'new-identifier' }" class="inline-block...">
+    Create An Identifier
+  </router-link>
+</div>
+
+<!-- Identity Details -->
+<IdentitySection
+  :given-name="givenName"
+  :profile-image-url="profileImageUrl"
+  :active-did="activeDid"
+  :is-registered="isRegistered"
+  :show-large-identicon-id="showLargeIdenticonId"
+  :show-large-identicon-url="showLargeIdenticonUrl"
+  :show-did-copy="showDidCopy"
+  @edit-name="onEditName"
+  @show-qr-code="onShowQrCode"
+  @add-image="onAddImage"
+  @delete-image="onDeleteImage"
+  @show-large-identicon-id="onShowLargeIdenticonId"
+  @show-large-identicon-url="onShowLargeIdenticonUrl"
+/>
+```
+
+## Specific Actionable Recommendations
+
+### Priority 1: Critical File Refactoring
+
+1. **Split AccountViewView.vue**:
+   - **Timeline**: 2-3 sprints
+   - **Strategy**: Extract 6 major sections into focused components
+   - **Risk**: Medium (requires careful state management coordination)
+   - **Benefit**: Massive maintainability improvement, easier testing
+
+2. **Decompose ImageMethodDialog.vue**:
+   - **Timeline**: 2-3 sprints
+   - **Strategy**: Extract 6 focused components (camera, file upload, cropping, etc.)
+   - **Risk**: Medium (complex camera state management)
+   - **Benefit**: Massive maintainability improvement
+
+3. **Decompose PlatformServiceMixin.ts**:
+   - **Timeline**: 1-2 sprints  
+   - **Strategy**: Create focused mixins by concern area
+   - **Risk**: Low (well-defined interfaces already exist)
+   - **Benefit**: Better code organization, reduced cognitive load
+
+### Priority 2: Component Extraction
+
+1. **HomeView.vue** → 4 focused sections
+   - **Timeline**: 1-2 sprints
+   - **Risk**: Low (clear separation of concerns)
+   - **Benefit**: Better code organization
+
+2. **ProjectViewView.vue** → 4 focused sections
+   - **Timeline**: 1-2 sprints
+   - **Risk**: Low (well-defined boundaries)
+   - **Benefit**: Improved maintainability
+
+### Priority 3: Shared Component Creation
+
+1. **CameraPreviewComponent.vue**
+   - Extract from ImageMethodDialog.vue and PhotoDialog.vue
+   - **Benefit**: Eliminate code duplication
+
+2. **FileUploadComponent.vue**
+   - Extract from ImageMethodDialog.vue and PhotoDialog.vue
+   - **Benefit**: Consistent file handling
+
+3. **ToggleSwitch.vue**
+   - Replace 12 duplicate toggle patterns
+   - **Benefit**: Consistent UI components
+
+4. **DiagnosticsPanelComponent.vue**
+   - Extract from ImageMethodDialog.vue
+   - **Benefit**: Reusable debugging component
+
+### Priority 4: Type Safety Enhancement
+
+1. **Eliminate "as any" Assertions**:
+   - **Timeline**: 1 sprint
+   - **Strategy**: Create proper interface extensions
+   - **Risk**: Low
+   - **Benefit**: Better compile-time error detection
+
+2. **Standardize Error Typing**:
+   - **Timeline**: 0.5 sprint
+   - **Strategy**: Use consistent `catch (error: unknown)` pattern
+   - **Risk**: None
+   - **Benefit**: Better error handling consistency
+
+### Priority 5: State Management Optimization
+
+1. **Create Composables for Complex State**:
+```typescript
+// src/composables/useCameraState.ts
+export function useCameraState() {
+  const cameraState = ref<CameraState>("off");
+  const showPreview = ref(false);
+  const isRetrying = ref(false);
+  
+  const startCamera = async () => { /* ... */ };
+  const stopCamera = () => { /* ... */ };
+  
+  return { cameraState, showPreview, isRetrying, startCamera, stopCamera };
+}
+```
+
+2. **Group Related Reactive Properties**:
+```typescript
+// Instead of:
+showB64Copy: boolean = false;
+showDidCopy: boolean = false;
+showDerCopy: boolean = false;
+showPubCopy: boolean = false;
+
+// Use:
+copyStates = {
+  b64: false,
+  did: false,
+  der: false,
+  pub: false
+};
+```
+
+### Priority 6: Code Standardization
+
+1. **Logging Standardization**:
+   - **Timeline**: 1 sprint
+   - **Strategy**: Replace all console.* with logger.*
+   - **Risk**: None
+   - **Benefit**: Consistent logging, better debugging
+
+2. **Template Optimization**:
+   - Add missing `:key` attributes
+   - Convert inline method calls to computed properties
+   - Implement virtual scrolling for large lists
+
+## Quality Metrics Summary
+
+### Vue Component Quality Distribution:
+| Size Category | Count | Percentage | Quality Assessment |
+|---------------|-------|------------|-------------------|
+| Large (>500 lines) | 5 | 12.5% | 🔴 Needs Refactoring |
+| Medium (200-500 lines) | 12 | 30% | 🟡 Good with Minor Issues |
+| Small (<200 lines) | 23 | 57.5% | 🟢 Excellent |
+
+### Vue View Quality Distribution:
+| Size Category | Count | Percentage | Quality Assessment |
+|---------------|-------|------------|-------------------|
+| Large (>1000 lines) | 9 | 16.7% | 🔴 Needs Refactoring |
+| Medium (500-1000 lines) | 8 | 14.8% | 🟡 Good with Minor Issues |
+| Small (<500 lines) | 37 | 68.5% | 🟢 Excellent |
+
+### Overall Quality Metrics:
+| Metric | Components | Views | Overall Assessment |
+|--------|------------|-------|-------------------|
+| Technical Debt | 1 TODO | 2 TODOs | 🟢 Excellent |
+| Type Safety | 6 "as any" | 35 "as any" | 🟡 Good |
+| Console Logging | 1 instance | 2 instances | 🟢 Excellent |
+| Architecture Consistency | 100% | 100% | 🟢 Excellent |
+| Component Reuse | High | High | 🟢 Excellent |
+
+### Before vs. Target State:
+| Metric | Current | Target | Status |
+|--------|---------|---------|---------|
+| Files >1000 lines | 9 files | 3 files | 🟡 Needs Work |
+| "as any" assertions | 62 | 15 | 🟡 Moderate |
+| Console.* calls | 129 | 0 | 🔴 Needs Work |
+| Component reuse | 40% | 75% | 🟡 Moderate |
+| Error consistency | 85% | 95% | 🟢 Good |
+| Type coverage | 88% | 95% | 🟢 Good |
+
+## Risk Assessment
+
+### Low Risk Improvements (High Impact):
+- Logging standardization
+- Type assertion cleanup  
+- Missing key attributes
+- Component extraction from AccountViewView.vue
+- Shared component creation (ToggleSwitch, CameraPreview)
+
+### Medium Risk Improvements:
+- PlatformServiceMixin decomposition
+- State management optimization
+- ImageMethodDialog decomposition
+
+### High Risk Items:
+- None identified - project demonstrates excellent architectural discipline
+
+## Conclusion
+
+The TimeSafari codebase demonstrates **exceptional code quality** with:
+
+**Key Strengths:**
+- **Consistent Architecture**: 100% Vue 3 Composition API with TypeScript
+- **Minimal Technical Debt**: Only 6 TODO comments across 291 files
+- **Excellent Small Components**: 68.5% of views and 57.5% of components are well-sized
+- **Strong Type Safety**: Minimal "as any" usage, mostly justified
+- **Clean Logging**: Minimal console.* usage, structured logging preferred
+- **Excellent Database Migration**: 99.5% complete
+- **Comprehensive Error Handling**: 367 catch blocks with good coverage
+- **No Circular Dependencies**: 100% resolved
+
+**Primary Focus Areas:**
+1. **Decompose Large Files**: 5 components and 9 views need refactoring
+2. **Extract Shared Components**: Camera, file upload, and diagnostics components
+3. **Optimize State Management**: Group related properties and create composables
+4. **Improve Type Safety**: Create proper interface extensions for mixin methods
+5. **Logging Standardization**: Replace 129 console.* calls with structured logger.*
+
+**The component architecture is production-ready** with these improvements representing **strategic optimization** rather than critical fixes. The codebase demonstrates **mature Vue.js development practices** with excellent separation of concerns and consistent patterns.
+
+---
+
+**Investigation Methodology:**
+- Static analysis of 291 source files (197 general + 94 Vue components/views)
+- Pattern recognition across 104,527 lines of code
+- Manual review of large files and complexity patterns
+- Dependency analysis and coupling assessment
+- Performance anti-pattern identification
+- Architecture consistency evaluation

README.md

@@ -1,8 +1,47 @@
-# Time Safari Application
+# TimeSafari.app - Crowd-Funder for Time - PWA
 
-**Author**: Matthew Raymer
-**Version**: 1.0.8-beta
-**Description**: Time Safari Application
+[Time Safari](https://timesafari.org/) allows people to ease into collaboration: start with expressions of gratitude
+and expand to crowd-fund with time & money, then record and see the impact of contributions.
+
+## Roadmap
+
+See [ClickUp](https://sharing.clickup.com/9014278710/l/h/8cmnyhp-174/10573fec74e2ba0) for current priorities.
+
+## Setup & Building
+
+Quick start:
+
+* For setup, we recommend [pkgx](https://pkgx.dev), which installs what you need (either automatically or with the `dev` command). Core dependencies are typescript & npm; when building for other platforms, you'll need other things such as those in the pkgx.yaml & BUILDING.md files.
+
+```bash
+npm install
+```
+
+### 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).
 
 ## 🛡️ Build Architecture Guard
 
@@ -36,39 +75,239 @@ git commit --no-verify
 git push --no-verify
 ```
 
-**📚 Full documentation**: See `README-BUILD-GUARD.md`
+**📚 Full documentation**: See `doc/README-BUILD-GUARD.md`
 
-## 🚀 Quick Start
+## Development Database Clearing
 
-### Prerequisites
+TimeSafari provides a simple script-based approach to clear the local database (not the claim server) for development purposes.
 
-- Node.js 18+
-- npm, yarn, or pnpm
-- Git
+## Logging Configuration
 
-### Installation
+TimeSafari supports configurable logging levels via the `VITE_LOG_LEVEL` environment variable. This allows developers to control console output verbosity without modifying code.
+
+### Quick Usage
 
 ```bash
+# Show only errors
+VITE_LOG_LEVEL=error npm run build:web:dev
+
+# Show warnings and errors
+VITE_LOG_LEVEL=warn npm run build:web:dev
+
+# Show info, warnings, and errors (default)
+VITE_LOG_LEVEL=info npm run build:web:dev
+
+# Show all log levels including debug
+VITE_LOG_LEVEL=debug npm run build:web:dev
+```
+
+### Available Levels
+
+- **`error`**: Critical errors only
+- **`warn`**: Warnings and errors (default for production web)
+- **`info`**: Info, warnings, and errors (default for development/capacitor)
+- **`debug`**: All log levels including verbose debugging
+
+See [Logging Configuration Guide](doc/logging-configuration.md) for complete details.
+
+### Quick Usage
+```bash
+# Run the database clearing script
+./scripts/clear-database.sh
+
+# Then restart your development server
+npm run build:electron:dev  # For Electron
+npm run build:web:dev       # For Web
+```
+
+### What It Does
+
+#### **Electron (Desktop App)**
+- Automatically finds and clears the SQLite database files
+- Works on Linux, macOS, and Windows
+- Clears all data and forces fresh migrations on next startup
+
+#### **Web Browser**
+- Provides instructions for using custom browser data directories
+- Shows manual clearing via browser DevTools
+- Ensures reliable database clearing without browser complications
+
+### Safety Features
+- ✅ **Interactive Script**: Guides you through the process
+- ✅ **Platform Detection**: Automatically detects your OS
+- ✅ **Clear Instructions**: Step-by-step guidance for each platform
+- ✅ **Safe Paths**: Only clears TimeSafari-specific data
+
+### Manual Commands (if needed)
+
+#### **Electron Database Location**
+```bash
+# Linux
+rm -rf ~/.config/TimeSafari/*
+
+# macOS  
+rm -rf ~/Library/Application\ Support/TimeSafari/*
+
+# Windows
+rmdir /s /q %APPDATA%\TimeSafari
+```
+
+#### **Web Browser (Custom Data Directory)**
+```bash
+# Create isolated browser profile
+mkdir ~/timesafari-dev-data
+```
+
+## Domain Configuration
+
+TimeSafari uses a centralized domain configuration system to ensure consistent
+URL generation across all environments. This prevents localhost URLs from
+appearing in shared links during development.
+
+### Key Features
+- ✅ **Production URLs for Sharing**: All copy link buttons use production domain
+- ✅ **Environment-Specific Internal URLs**: Internal operations use appropriate
+  environment URLs
+- ✅ **Single Point of Control**: Change domain in one place for entire app
+- ✅ **Type-Safe Configuration**: Full TypeScript support
+
+### Quick Reference
+
+```typescript
+// For sharing functionality (environment-specific)
+import { APP_SERVER } from "@/constants/app";
+const shareLink = `${APP_SERVER}/deep-link/claim/123`;
+
+// For internal operations (environment-specific)
+import { APP_SERVER } from "@/constants/app";
+const apiUrl = `${APP_SERVER}/api/claim/123`;
+```
+
+### Documentation
+
+- [Constants and Configuration](src/constants/app.ts) - Core constants
+
+## Tests
+
+See [TESTING.md](test-playwright/TESTING.md) for detailed test instructions.
+
+## Asset Management
+
+TimeSafari uses a standardized asset configuration system for consistent
+icon and splash screen generation across all platforms.
+
+### Asset Sources
+
+- **Single source of truth**: `resources/` directory (Capacitor default)
+- **Source files**: `icon.png`, `splash.png`, `splash_dark.png`
+- **Format**: PNG or SVG files for optimal quality
+
+### Asset Generation
+
+- **Configuration**: `config/assets/capacitor-assets.config.json`
+- **Schema validation**: `config/assets/schema.json`
+- **Build-time generation**: Platform assets generated via `capacitor-assets`
+- **No VCS commits**: Generated assets are never committed to version control
+
+### Development Commands
+
+```bash
+# Generate/update asset configurations
+npm run assets:config
+
+# Validate asset configurations
+npm run assets:validate
+
+# Clean generated platform assets (local dev only)
+npm run assets:clean
+
+# Build with asset generation
+npm run build:native
+```
+
+### Environment Setup & Dependencies
+
+Before building the application, ensure your development environment is properly
+configured:
+
+```bash
+# Install all dependencies (required first time and after updates)
 npm install
-npm run guard:setup  # Sets up Build Architecture Guard
+
+# Validate your development environment
+npm run check:dependencies
+
+# Check prerequisites for testing
+npm run test:prerequisites
 ```
 
-### Development
+**Common Issues & Solutions**:
 
-```bash
-npm run build:web:dev    # Build web version
-npm run build:ios:test   # Build iOS test version
-npm run build:android:test # Build Android test version
-npm run build:electron:dev # Build Electron dev version
-```
+- **"tsx: command not found"**: Run `npm install` to install devDependencies
+- **"capacitor-assets: command not found"**: Ensure `@capacitor/assets` is installed
+- **Build failures**: Run `npm run check:dependencies` to diagnose environment issues
 
-### Testing
+**Required Versions**:
+- Node.js: 18+ (LTS recommended)
+- npm: 8+ (comes with Node.js)
+- Platform-specific tools: Android Studio, Xcode (for mobile builds)
 
-```bash
-npm run test:web         # Run web tests
-npm run test:mobile      # Run mobile tests
-npm run test:all         # Run all tests
-```
+### Platform Support
+
+- **Android**: Adaptive icons with foreground/background, monochrome support
+- **iOS**: LaunchScreen storyboard preferred, splash assets when needed
+- **Web**: PWA icons generated during build to `dist/` (not committed)
+
+### Font Awesome Icons
+
+To add a Font Awesome icon, add to `fontawesome.ts` and reference with
+`font-awesome` element and `icon` attribute with the hyphenated name.
+
+## Other
+
+### Reference Material
+
+* Notifications can be type of `toast` (self-dismiss), `info`, `success`, `warning`, and `danger`.
+  They are done via [notiwind](https://www.npmjs.com/package/notiwind) and set up in App.vue.
+
+* [Customize Vue configuration](https://cli.vuejs.org/config/).
+
+* If you are deploying in a subdirectory, add it to `publicPath` in vue.config.js, eg: `publicPath: "/app/time-tracker/",`
+
+### Code Organization
+
+The project uses a centralized approach to type definitions and interfaces:
+
+* `src/interfaces/` - Contains all TypeScript interfaces and type definitions
+  * `deepLinks.ts` - Deep linking type system and Zod validation schemas
+  * `give.ts` - Give-related interfaces and type definitions
+  * `claims.ts` - Claim-related interfaces and verifiable credentials
+  * `common.ts` - Shared interfaces and utility types
+  * Other domain-specific interface files
+
+Key principles:
+- All interfaces and types are defined in the interfaces folder
+- Zod schemas are used for runtime validation and type generation
+- Domain-specific interfaces are separated into their own files
+- Common interfaces are shared through `common.ts`
+- Type definitions are generated from Zod schemas where possible
+
+### Database Architecture
+
+The application uses a platform-agnostic database layer with Vue mixins for service access:
+
+* `src/services/PlatformService.ts` - Database interface definition
+* `src/services/PlatformServiceFactory.ts` - Platform-specific service factory
+* `src/services/AbsurdSqlDatabaseService.ts` - SQLite implementation
+* `src/utils/PlatformServiceMixin.ts` - Vue mixin for database access with caching
+
+**Development Guidelines**:
+
+- Always use `PlatformServiceMixin` for database operations in components
+- Test with PlatformServiceMixin for new features
+- Leverage mixin's ultra-concise methods: `$db()`, `$exec()`, `$one()`, `$contacts()`, `$settings()`
+
+**Architecture Decision**: The project uses Vue mixins over Composition API composables for platform service access. See [Architecture Decisions](doc/architecture-decisions.md) for detailed rationale.
 
 ## 📁 Project Structure
 
@@ -82,37 +321,24 @@ timesafari/
 ├── 📁 .husky/           # Git hooks (Build Architecture Guard)
 ├── 📄 BUILDING.md       # Build system documentation
 ├── 📄 pull_request_template.md # PR template
-└── 📄 README-BUILD-GUARD.md # Guard system documentation
+└── 📄 doc/README-BUILD-GUARD.md # Guard system documentation
 ```
 
-## 🔧 Build System
-
-This project supports multiple platforms:
-
-- **Web**: Vite-based build with service worker support
-- **Mobile**: Capacitor-based iOS and Android builds
-- **Desktop**: Electron-based cross-platform desktop app
-- **Docker**: Containerized deployment options
-
-## 📚 Documentation
-
-- **`BUILDING.md`** - Complete build system guide
-- **`README-BUILD-GUARD.md`** - Build Architecture Guard documentation
-- **`pull_request_template.md`** - PR template for build changes
-
 ## 🤝 Contributing
 
 1. **Follow the Build Architecture Guard** - Update BUILDING.md when modifying build files
-2. **Use the PR template** - Complete the checklist for build-related changes
 3. **Test your changes** - Ensure builds work on affected platforms
 4. **Document updates** - Keep BUILDING.md current and accurate
 
-## 📄 License
+## Kudos
 
-[Add your license information here]
+Gifts make the world go 'round!
 
----
-
-**Note**: The Build Architecture Guard is active and will block
-commits/pushes that modify build files without proper documentation
-updates. See `README-BUILD-GUARD.md` for complete details.
+* [WebStorm by JetBrains](https://www.jetbrains.com/webstorm/) for the free open-source license
+* [Máximo Fernández](https://medium.com/@maxfarenas) for the 3D [code](https://github.com/maxfer03/vue-three-ns) and [explanatory post](https://medium.com/nicasource/building-an-interactive-web-portfolio-with-vue-three-js-part-three-implementing-three-js-452cb375ef80)
+* [Many tools & libraries](https://gitea.anomalistdesign.com/trent_larson/crowd-funder-for-time-pwa/src/branch/master/package.json#L10) such as Nodejs.org, IntelliJ Idea, Veramo.io, Vuejs.org, threejs.org
+* [Bush 3D model](https://sketchfab.com/3d-models/lupine-plant-bf30f1110c174d4baedda0ed63778439)
+* [Forest floor image](https://www.goodfreephotos.com/albums/textures/leafy-autumn-forest-floor.jpg)
+* Time Safari logo assisted by [DALL-E in ChatGPT](https://chat.openai.com/g/g-2fkFE8rbu-dall-e)
+* [DiceBear](https://www.dicebear.com/licenses/) and [Avataaars](https://www.dicebear.com/styles/avataaars/#details) for human-looking identicons
+* Some gratitude prompts thanks to [Develop Good Habits](https://www.developgoodhabits.com/gratitude-journal-prompts/)

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 40
-        versionName "1.0.7"
+        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

@@ -13,9 +13,12 @@ dependencies {
     implementation project(':capacitor-mlkit-barcode-scanning')
     implementation project(':capacitor-app')
     implementation project(':capacitor-camera')
+    implementation project(':capacitor-clipboard')
     implementation project(':capacitor-filesystem')
     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
@@ -14,6 +16,7 @@
             android:label="@string/title_activity_main"
             android:launchMode="singleTask"
             android:screenOrientation="portrait"
+            android:windowSoftInputMode="adjustResize"
             android:theme="@style/AppTheme.NoActionBarLaunch">
             <intent-filter>
                 <action android:name="android.intent.action.MAIN" />
@@ -26,8 +29,59 @@
                 <category android:name="android.intent.category.BROWSABLE" />
                 <data android:scheme="timesafari" />
             </intent-filter>
+
+            <!-- Share Target Intent Filter - Single Image -->
+            <intent-filter>
+                <action android:name="android.intent.action.SEND" />
+                <category android:name="android.intent.category.DEFAULT" />
+                <data android:mimeType="image/*" />
+            </intent-filter>
+
+            <!-- Share Target Intent Filter - Multiple Images (optional, we'll handle first image) -->
+            <intent-filter>
+                <action android:name="android.intent.action.SEND_MULTIPLE" />
+                <category android:name="android.intent.category.DEFAULT" />
+                <data android:mimeType="image/*" />
+            </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"
@@ -44,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

@@ -15,6 +15,10 @@
 		"pkg": "@capacitor/camera",
 		"classpath": "com.capacitorjs.plugins.camera.CameraPlugin"
 	},
+	{
+		"pkg": "@capacitor/clipboard",
+		"classpath": "com.capacitorjs.plugins.clipboard.ClipboardPlugin"
+	},
 	{
 		"pkg": "@capacitor/filesystem",
 		"classpath": "com.capacitorjs.plugins.filesystem.FilesystemPlugin"
@@ -23,8 +27,24 @@
 		"pkg": "@capacitor/share",
 		"classpath": "com.capacitorjs.plugins.share.SharePlugin"
 	},
+	{
+		"pkg": "@capacitor/status-bar",
+		"classpath": "com.capacitorjs.plugins.statusbar.StatusBarPlugin"
+	},
 	{
 		"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"
+	},
+	{
+		"pkg": "SharedImage",
+		"classpath": "app.timesafari.sharedimage.SharedImagePlugin"
 	}
 ]

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

@@ -1,15 +1,227 @@
 package app.timesafari;
 
+import android.content.Intent;
+import android.net.Uri;
 import android.os.Bundle;
+import android.util.Base64;
+import android.util.Log;
+import android.view.View;
+import android.view.WindowManager;
+import android.view.WindowInsetsController;
+import android.view.WindowInsets;
+import android.os.Build;
+import android.webkit.WebView;
+import android.webkit.WebSettings;
+import android.webkit.WebViewClient;
 import com.getcapacitor.BridgeActivity;
+import app.timesafari.safearea.SafeAreaPlugin;
+import app.timesafari.sharedimage.SharedImagePlugin;
 //import com.getcapacitor.community.sqlite.SQLite;
 
+import android.content.SharedPreferences;
+import java.io.InputStream;
+import java.io.ByteArrayOutputStream;
+import java.io.IOException;
+
 public class MainActivity extends BridgeActivity {
+    private static final String TAG = "MainActivity";
+    private static final String SHARED_PREFS_NAME = "shared_image";
+    private static final String KEY_BASE64 = "shared_image_base64";
+    private static final String KEY_FILE_NAME = "shared_image_file_name";
+    private static final String KEY_READY = "shared_image_ready";
+    
     @Override
     public void onCreate(Bundle savedInstanceState) {
         super.onCreate(savedInstanceState);
         
+        // Enable edge-to-edge display for modern Android
+        if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.R) {
+            // Android 11+ (API 30+)
+            getWindow().setDecorFitsSystemWindows(false);
+            
+            // Set up system UI visibility for edge-to-edge
+            WindowInsetsController controller = getWindow().getInsetsController();
+            if (controller != null) {
+                controller.setSystemBarsAppearance(
+                    WindowInsetsController.APPEARANCE_LIGHT_STATUS_BARS | 
+                    WindowInsetsController.APPEARANCE_LIGHT_NAVIGATION_BARS,
+                    WindowInsetsController.APPEARANCE_LIGHT_STATUS_BARS | 
+                    WindowInsetsController.APPEARANCE_LIGHT_NAVIGATION_BARS
+                );
+                controller.setSystemBarsBehavior(WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE);
+            }
+        } else {
+            // Legacy Android (API 21-29)
+            getWindow().getDecorView().setSystemUiVisibility(
+                View.SYSTEM_UI_FLAG_LAYOUT_STABLE |
+                View.SYSTEM_UI_FLAG_LAYOUT_HIDE_NAVIGATION |
+                View.SYSTEM_UI_FLAG_LAYOUT_FULLSCREEN |
+                View.SYSTEM_UI_FLAG_LIGHT_STATUS_BAR |
+                View.SYSTEM_UI_FLAG_LIGHT_NAVIGATION_BAR
+            );
+        }
+        
+        // Register SafeArea plugin
+        registerPlugin(SafeAreaPlugin.class);
+        
+        // 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);
+        
+        // Handle share intent if app was launched from share sheet
+        handleShareIntent(getIntent());
     }
+    
+    @Override
+    protected void onNewIntent(Intent intent) {
+        super.onNewIntent(intent);
+        setIntent(intent);
+        handleShareIntent(intent);
+    }
+    
+    /**
+     * Handle share intents (ACTION_SEND or ACTION_SEND_MULTIPLE)
+     * Processes shared images and stores them in SharedPreferences for plugin to read
+     */
+    private void handleShareIntent(Intent intent) {
+        if (intent == null) {
+            return;
+        }
+        
+        String action = intent.getAction();
+        String type = intent.getType();
+        
+        boolean handled = false;
+        
+        // Handle single image share
+        if (Intent.ACTION_SEND.equals(action) && type != null && type.startsWith("image/")) {
+            Uri imageUri;
+            // Use new API for API 33+ (Android 13+), fall back to deprecated API for older versions
+            if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.TIRAMISU) {
+                imageUri = intent.getParcelableExtra(Intent.EXTRA_STREAM, Uri.class);
+            } else {
+                // Deprecated but still works on older versions
+                @SuppressWarnings("deprecation")
+                Uri uri = intent.getParcelableExtra(Intent.EXTRA_STREAM);
+                imageUri = uri;
+            }
+            if (imageUri != null) {
+                String fileName = intent.getStringExtra(Intent.EXTRA_TEXT);
+                processSharedImage(imageUri, fileName);
+                handled = true;
+            }
+        }
+        // Handle multiple images share (we'll just process the first one)
+        else if (Intent.ACTION_SEND_MULTIPLE.equals(action) && type != null && type.startsWith("image/")) {
+            java.util.ArrayList<Uri> imageUris;
+            // Use new API for API 33+ (Android 13+), fall back to deprecated API for older versions
+            if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.TIRAMISU) {
+                imageUris = intent.getParcelableArrayListExtra(Intent.EXTRA_STREAM, Uri.class);
+            } else {
+                // Deprecated but still works on older versions
+                @SuppressWarnings("deprecation")
+                java.util.ArrayList<Uri> uris = intent.getParcelableArrayListExtra(Intent.EXTRA_STREAM);
+                imageUris = uris;
+            }
+            if (imageUris != null && !imageUris.isEmpty()) {
+                processSharedImage(imageUris.get(0), null);
+                handled = true;
+            }
+        }
+        
+        // Clear the intent after handling to release URI permissions and prevent
+        // network issues in WebView. This is critical for preventing the WebView
+        // from losing network connectivity after processing shared content.
+        if (handled) {
+            intent.setAction(null);
+            intent.setData(null);
+            intent.removeExtra(Intent.EXTRA_STREAM);
+            intent.setType(null);
+            setIntent(new Intent());
+            Log.d(TAG, "Cleared share intent after processing");
+        }
+    }
+    
+    /**
+     * Process a shared image: read it, convert to base64, and write to temp file
+     * Uses try-with-resources to ensure proper stream cleanup and prevent network issues
+     */
+    private void processSharedImage(Uri imageUri, String fileName) {
+        // Extract filename from URI or use default (do this before opening streams)
+        String actualFileName = fileName;
+        if (actualFileName == null || actualFileName.isEmpty()) {
+            String path = imageUri.getPath();
+            if (path != null) {
+                int lastSlash = path.lastIndexOf('/');
+                if (lastSlash >= 0 && lastSlash < path.length() - 1) {
+                    actualFileName = path.substring(lastSlash + 1);
+                }
+            }
+            if (actualFileName == null || actualFileName.isEmpty()) {
+                actualFileName = "shared-image.jpg";
+            }
+        }
+        
+        // Use try-with-resources to ensure streams are properly closed
+        // This is critical to prevent resource leaks that can affect WebView networking
+        try (InputStream inputStream = getContentResolver().openInputStream(imageUri);
+             ByteArrayOutputStream buffer = new ByteArrayOutputStream()) {
+            
+            if (inputStream == null) {
+                Log.e(TAG, "Failed to open input stream for shared image");
+                return;
+            }
+            
+            // Read image bytes
+            byte[] data = new byte[8192];
+            int nRead;
+            while ((nRead = inputStream.read(data, 0, data.length)) != -1) {
+                buffer.write(data, 0, nRead);
+            }
+            buffer.flush();
+            byte[] imageBytes = buffer.toByteArray();
+            
+            // Convert to base64
+            String base64String = Base64.encodeToString(imageBytes, Base64.NO_WRAP);
+            
+            // Store in SharedPreferences for plugin to read
+            storeSharedImageInPreferences(base64String, actualFileName);
+            
+            Log.d(TAG, "Successfully processed shared image: " + actualFileName);
+        } catch (IOException e) {
+            Log.e(TAG, "Error processing shared image", e);
+        } catch (Exception e) {
+            Log.e(TAG, "Unexpected error processing shared image", e);
+        }
+    }
+    
+    /**
+     * Store shared image data in SharedPreferences for plugin to read
+     * Plugin will read and clear the data when called
+     */
+    private void storeSharedImageInPreferences(String base64, String fileName) {
+        try {
+            SharedPreferences prefs = getSharedPreferences(SHARED_PREFS_NAME, MODE_PRIVATE);
+            SharedPreferences.Editor editor = prefs.edit();
+            editor.putString(KEY_BASE64, base64);
+            editor.putString(KEY_FILE_NAME, fileName);
+            editor.putBoolean(KEY_READY, true);
+            editor.apply();
+            
+            Log.d(TAG, "Stored shared image data in SharedPreferences");
+        } catch (Exception e) {
+            Log.e(TAG, "Error storing shared image in SharedPreferences", e);
+        }
+    }
+
 } 

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/java/app/timesafari/safearea/SafeAreaPlugin.java

@@ -0,0 +1,44 @@
+package app.timesafari.safearea;
+
+import android.os.Build;
+import android.view.WindowInsets;
+import com.getcapacitor.JSObject;
+import com.getcapacitor.Plugin;
+import com.getcapacitor.PluginCall;
+import com.getcapacitor.PluginMethod;
+import com.getcapacitor.annotation.CapacitorPlugin;
+
+@CapacitorPlugin(name = "SafeArea")
+public class SafeAreaPlugin extends Plugin {
+
+    @PluginMethod
+    public void getSafeAreaInsets(PluginCall call) {
+        JSObject result = new JSObject();
+        
+        if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.R) {
+            WindowInsets insets = getActivity().getWindow().getDecorView().getRootWindowInsets();
+            if (insets != null) {
+                int top = insets.getInsets(WindowInsets.Type.statusBars()).top;
+                int bottom = insets.getInsets(WindowInsets.Type.navigationBars()).bottom;
+                int left = insets.getInsets(WindowInsets.Type.systemBars()).left;
+                int right = insets.getInsets(WindowInsets.Type.systemBars()).right;
+                
+                result.put("top", top);
+                result.put("bottom", bottom);
+                result.put("left", left);
+                result.put("right", right);
+                
+                call.resolve(result);
+                return;
+            }
+        }
+        
+        // Fallback values
+        result.put("top", 0);
+        result.put("bottom", 0);
+        result.put("left", 0);
+        result.put("right", 0);
+        
+        call.resolve(result);
+    }
+}

android/app/src/main/java/app/timesafari/sharedimage/SharedImagePlugin.java

@@ -0,0 +1,84 @@
+package app.timesafari.sharedimage;
+
+import android.content.Context;
+import android.content.SharedPreferences;
+import com.getcapacitor.JSObject;
+import com.getcapacitor.Plugin;
+import com.getcapacitor.PluginCall;
+import com.getcapacitor.PluginMethod;
+import com.getcapacitor.annotation.CapacitorPlugin;
+
+@CapacitorPlugin(name = "SharedImage")
+public class SharedImagePlugin extends Plugin {
+    
+    private static final String SHARED_PREFS_NAME = "shared_image";
+    private static final String KEY_BASE64 = "shared_image_base64";
+    private static final String KEY_FILE_NAME = "shared_image_file_name";
+    private static final String KEY_READY = "shared_image_ready";
+    
+    /**
+     * Get shared image data from SharedPreferences
+     * Returns base64 string and fileName, or null if no image exists
+     * Clears the data after reading to prevent re-reading
+     */
+    @PluginMethod
+    public void getSharedImage(PluginCall call) {
+        try {
+            SharedPreferences prefs = getSharedPreferences();
+            
+            String base64 = prefs.getString(KEY_BASE64, null);
+            String fileName = prefs.getString(KEY_FILE_NAME, null);
+            
+            if (base64 == null || fileName == null) {
+                // No shared image exists - return null values (not an error)
+                JSObject result = new JSObject();
+                result.put("base64", (String) null);
+                result.put("fileName", (String) null);
+                call.resolve(result);
+                return;
+            }
+            
+            // Clear the shared data after reading
+            SharedPreferences.Editor editor = prefs.edit();
+            editor.remove(KEY_BASE64);
+            editor.remove(KEY_FILE_NAME);
+            editor.remove(KEY_READY);
+            editor.apply();
+            
+            // Return the shared image data
+            JSObject result = new JSObject();
+            result.put("base64", base64);
+            result.put("fileName", fileName);
+            call.resolve(result);
+        } catch (Exception e) {
+            android.util.Log.e("SharedImagePlugin", "Error in getSharedImage()", e);
+            call.reject("Error getting shared image: " + e.getMessage());
+        }
+    }
+    
+    /**
+     * Check if shared image exists without reading it
+     * Useful for quick checks before calling getSharedImage()
+     */
+    @PluginMethod
+    public void hasSharedImage(PluginCall call) {
+        SharedPreferences prefs = getSharedPreferences();
+        boolean hasImage = prefs.contains(KEY_BASE64) && prefs.contains(KEY_FILE_NAME);
+        
+        JSObject result = new JSObject();
+        result.put("hasImage", hasImage);
+        call.resolve(result);
+    }
+    
+    /**
+     * Get SharedPreferences instance for shared image data
+     */
+    private SharedPreferences getSharedPreferences() {
+        Context context = getContext();
+        if (context == null) {
+            throw new IllegalStateException("Plugin context is null");
+        }
+        return context.getSharedPreferences(SHARED_PREFS_NAME, Context.MODE_PRIVATE);
+    }
+}
+

android/app/src/main/res/values/styles.xml

@@ -18,5 +18,14 @@
 
     <style name="AppTheme.NoActionBarLaunch" parent="Theme.SplashScreen">
         <item name="android:background">@drawable/splash</item>
+        <item name="android:windowTranslucentStatus">false</item>
+        <item name="android:windowTranslucentNavigation">false</item>
+        <item name="android:windowDrawsSystemBarBackgrounds">true</item>
+        <item name="android:statusBarColor">@android:color/transparent</item>
+        <item name="android:navigationBarColor">@android:color/transparent</item>
+        <item name="android:windowLightStatusBar">true</item>
+        <item name="android:windowLightNavigationBar">true</item>
+        <item name="android:enforceStatusBarContrast">false</item>
+        <item name="android:enforceNavigationBarContrast">false</item>
     </style>
 </resources>

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

@@ -14,11 +14,20 @@ project(':capacitor-app').projectDir = new File('../node_modules/@capacitor/app/
 include ':capacitor-camera'
 project(':capacitor-camera').projectDir = new File('../node_modules/@capacitor/camera/android')
 
+include ':capacitor-clipboard'
+project(':capacitor-clipboard').projectDir = new File('../node_modules/@capacitor/clipboard/android')
+
 include ':capacitor-filesystem'
 project(':capacitor-filesystem').projectDir = new File('../node_modules/@capacitor/filesystem/android')
 
 include ':capacitor-share'
 project(':capacitor-share').projectDir = new File('../node_modules/@capacitor/share/android')
 
+include ':capacitor-status-bar'
+project(':capacitor-status-bar').projectDir = new File('../node_modules/@capacitor/status-bar/android')
+
 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

android/variables.gradle

@@ -1,5 +1,5 @@
 ext {
-    minSdkVersion = 22
+    minSdkVersion = 23
     compileSdkVersion = 36
     targetSdkVersion = 36
     androidxActivityVersion = '1.8.0'

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: {

commitlint.config.js

@@ -0,0 +1,9 @@
+module.exports = {
+  extends: ['@commitlint/config-conventional'],
+  rules: {
+    // Downgrade strict case rules to warnings (level 1) instead of errors (level 2)
+    // This eliminates red error messages while maintaining helpful guidance
+    'subject-case': [1, 'never', ['sentence-case', 'start-case', 'pascal-case', 'upper-case']],
+    'subject-full-stop': [1, 'never', '.'],
+  }
+};

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/README-BUILD-GUARD.md

@@ -230,6 +230,44 @@ git diff --name-only --cached
 3. **Team training** - Help developers understand the system
 4. **Continuous improvement** - Refine patterns and error messages
 
+## 🚨 **Troubleshooting**
+
+### Common Issues
+
+#### mapfile Command Not Found
+
+**Problem**: Pre-commit hook fails with `mapfile: command not found`
+
+**Cause**: The `mapfile` command is bash-specific and not available in all shell environments
+
+**Solution**: The script has been updated to use portable alternatives. If you encounter this issue:
+
+```bash
+# Verify the script is executable
+chmod +x scripts/build-arch-guard.sh
+
+# Test the script directly
+./scripts/build-arch-guard.sh --help
+
+# Check your shell environment
+echo $SHELL
+bash --version
+```
+
+**Prevention**: Ensure your development environment uses bash and the script has proper permissions
+
+### False Positives
+
+```bash
+# If guard blocks legitimate changes, check:
+# 1. Are you modifying a protected file pattern?
+# 2. Did you update BUILDING.md?
+# 3. Is BUILDING.md staged for commit?
+
+# View what the guard sees
+git diff --name-only --cached
+```
+
 ## 🔄 **Customization**
 
 ### Adding New Protected Paths
@@ -288,3 +326,11 @@ Track the effectiveness of your Build Architecture Guard:
 **Dependencies**: Husky, Git, Bash
 **Maintainer**: Development team
 **Related**: `pull_request_template.md`, `scripts/build-arch-guard.sh`
+
+## 📝 **Changelog**
+
+### 2025-08-22 - Shell Compatibility Fix
+- **Fixed**: Replaced `mapfile` command with portable alternative for cross-shell compatibility
+- **Impact**: Resolves "mapfile: command not found" errors in pre-commit hooks
+- **Files**: `scripts/build-arch-guard.sh`
+- **Testing**: Script now works across different shell environments

doc/android-api-23-upgrade-impact-analysis.md

@@ -0,0 +1,259 @@
+# Android API 23 Upgrade Impact Analysis
+
+**Date:** 2025-12-03  
+**Current minSdkVersion:** 22 (Android 5.1 Lollipop)  
+**Proposed minSdkVersion:** 23 (Android 6.0 Marshmallow)  
+**Impact Assessment:** Low to Moderate
+
+## Executive Summary
+
+Upgrading from API 22 to API 23 will have **minimal code impact** but may affect device compatibility. The main change is that API 23 introduced runtime permissions, but since the app uses Capacitor plugins which handle permissions, the impact is minimal.
+
+## Code Impact Analysis
+
+### ✅ No Breaking Changes in Existing Code
+
+#### 1. API Level Checks in Code
+All existing API level checks are for **much higher APIs** than 23, so they won't be affected:
+
+**MainActivity.java:**
+- `Build.VERSION_CODES.R` (API 30+) - Edge-to-edge display
+- `Build.VERSION_CODES.TIRAMISU` (API 33+) - Intent extras handling
+- Legacy path (API 21-29) - Will still work, but API 22 devices won't be supported
+
+**SafeAreaPlugin.java:**
+- `Build.VERSION_CODES.R` (API 30+) - Safe area insets
+
+**Conclusion:** No code changes needed for API level checks.
+
+#### 2. Permissions Handling
+
+**Current Permissions in AndroidManifest.xml:**
+- `INTERNET` - Normal permission (no runtime needed)
+- `READ_EXTERNAL_STORAGE` - Dangerous permission (runtime required on API 23+)
+- `WRITE_EXTERNAL_STORAGE` - Dangerous permission (runtime required on API 23+)
+- `CAMERA` - Dangerous permission (runtime required on API 23+)
+
+**Current Implementation:**
+- ✅ App uses **Capacitor plugins** for camera and file access
+- ✅ Capacitor plugins **already handle runtime permissions** automatically
+- ✅ No manual permission request code found in the codebase
+- ✅ QR Scanner uses Capacitor's BarcodeScanner plugin which handles permissions
+
+**Conclusion:** No code changes needed - Capacitor handles runtime permissions automatically.
+
+#### 3. Dependencies Compatibility
+
+**AndroidX Libraries:**
+- `androidx.appcompat:appcompat:1.6.1` - ✅ Supports API 23+
+- `androidx.core:core:1.12.0` - ✅ Supports API 23+
+- `androidx.fragment:fragment:1.6.2` - ✅ Supports API 23+
+- `androidx.coordinatorlayout:coordinatorlayout:1.2.0` - ✅ Supports API 23+
+- `androidx.core:core-splashscreen:1.0.1` - ✅ Supports API 23+
+
+**Capacitor Plugins:**
+- `@capacitor/core:6.2.0` - ✅ Requires API 23+ (official requirement)
+- `@capacitor/camera:6.0.0` - ✅ Handles runtime permissions
+- `@capacitor/filesystem:6.0.0` - ✅ Handles runtime permissions
+- `@capacitor-community/sqlite:6.0.2` - ✅ Supports API 23+
+- `@capacitor-mlkit/barcode-scanning:6.0.0` - ✅ Supports API 23+
+
+**Third-Party Libraries:**
+- No Firebase or other libraries with API 22-specific requirements found
+- All dependencies appear compatible with API 23+
+
+**Conclusion:** All dependencies are compatible with API 23.
+
+#### 4. Build Configuration
+
+**Current Configuration:**
+- `compileSdkVersion = 36` (Android 14)
+- `targetSdkVersion = 36` (Android 14)
+- `minSdkVersion = 22` (Android 5.1) ← **Only this needs to change**
+
+**Required Change:**
+```gradle
+// android/variables.gradle
+ext {
+    minSdkVersion = 23  // Change from 22 to 23
+    // ... rest stays the same
+}
+```
+
+**Conclusion:** Only one line needs to be changed.
+
+## Device Compatibility Impact
+
+### Device Coverage Loss
+
+**API 22 (Android 5.1 Lollipop):**
+- Released: March 2015
+- Market share: ~0.1% of active devices (as of 2024)
+- Devices affected: Very old devices from 2015-2016
+
+**API 23 (Android 6.0 Marshmallow):**
+- Released: October 2015
+- Market share: ~0.3% of active devices (as of 2024)
+- Still very low, but slightly higher than API 22
+
+**Impact:** Losing support for ~0.1% of devices (essentially negligible)
+
+### User Base Impact
+
+**Recommendation:** Check your analytics to see actual usage:
+- If you have analytics, check percentage of users on API 22
+- If < 0.5%, upgrade is safe
+- If > 1%, consider the business impact
+
+## Runtime Permissions (API 23 Feature)
+
+### What Changed in API 23
+
+**Before API 23 (API 22 and below):**
+- Permissions granted at install time
+- User sees all permissions during installation
+- No runtime permission dialogs
+
+**API 23+ (Runtime Permissions):**
+- Dangerous permissions must be requested at runtime
+- User sees permission dialogs when app needs them
+- Better user experience and privacy
+
+### Current App Status
+
+**✅ Already Compatible:**
+- App uses Capacitor plugins which **automatically handle runtime permissions**
+- Camera plugin requests permissions when needed
+- Filesystem plugin requests permissions when needed
+- No manual permission code needed
+
+**Conclusion:** App is already designed for runtime permissions via Capacitor.
+
+## Potential Issues to Watch
+
+### 1. APK Size
+- Some developers report APK size increases after raising minSdkVersion
+- **Action:** Monitor APK size after upgrade
+- **Expected Impact:** Minimal (API 22 → 23 is a small jump)
+
+### 2. Testing Requirements
+- Need to test on API 23+ devices
+- **Action:** Test on Android 6.0+ devices/emulators
+- **Current:** App likely already tested on API 23+ devices
+
+### 3. Legacy Code Path
+- MainActivity has legacy code for API 21-29
+- **Impact:** This code will still work, but API 22 devices won't be supported
+- **Action:** No code changes needed, but legacy path becomes API 23-29
+
+### 4. Capacitor Compatibility
+- Capacitor 6.2.0 officially requires API 23+
+- **Current Situation:** App runs on API 22 (may be working due to leniency)
+- **After Upgrade:** Officially compliant with Capacitor requirements
+- **Benefit:** Better compatibility guarantees
+
+## Files That Need Changes
+
+### 1. Build Configuration
+**File:** `android/variables.gradle`
+```gradle
+ext {
+    minSdkVersion = 23  // Change from 22
+    // ... rest unchanged
+}
+```
+
+### 2. Documentation
+**Files to Update:**
+- `doc/shared-image-plugin-implementation-plan.md` - Update version notes
+- Any README files mentioning API 22
+- Build documentation
+
+### 3. No Code Changes Required
+- ✅ No Java/Kotlin code changes needed
+- ✅ No AndroidManifest.xml changes needed
+- ✅ No permission handling code changes needed
+
+## Testing Checklist
+
+After upgrading to API 23, test:
+
+- [ ] App builds successfully
+- [ ] App installs on API 23 device/emulator
+- [ ] Camera functionality works (permissions requested)
+- [ ] File access works (permissions requested)
+- [ ] Share functionality works
+- [ ] QR code scanning works
+- [ ] Deep linking works
+- [ ] All Capacitor plugins work correctly
+- [ ] No crashes or permission-related errors
+- [ ] APK size is acceptable
+
+## Rollback Plan
+
+If issues arise:
+
+1. Revert `android/variables.gradle` to `minSdkVersion = 22`
+2. Rebuild and test
+3. Document issues encountered
+4. Address issues before retrying upgrade
+
+## Recommendation
+
+### ✅ **Proceed with Upgrade**
+
+**Reasons:**
+1. **Minimal Code Impact:** Only one line needs to change
+2. **Already Compatible:** App uses Capacitor which handles runtime permissions
+3. **Device Impact:** Negligible (~0.1% of devices)
+4. **Capacitor Compliance:** Officially meets Capacitor 6 requirements
+5. **Future-Proofing:** Better alignment with modern Android development
+
+**Timeline:**
+- **Low Risk:** Can be done anytime
+- **Recommended:** Before implementing SharedImagePlugin (cleaner baseline)
+- **Testing:** 1-2 hours of testing on API 23+ devices
+
+## Migration Steps
+
+1. **Update Build Configuration:**
+   ```bash
+   # Edit android/variables.gradle
+   minSdkVersion = 23
+   ```
+
+2. **Sync Gradle:**
+   ```bash
+   cd android
+   ./gradlew clean
+   ```
+
+3. **Build and Test:**
+   ```bash
+   npm run build:android:test
+   # Test on API 23+ device/emulator
+   ```
+
+4. **Verify Permissions:**
+   - Test camera access
+   - Test file access
+   - Verify permission dialogs appear
+
+5. **Update Documentation:**
+   - Update any docs mentioning API 22
+   - Update implementation plan
+
+## Summary
+
+| Aspect | Impact | Status |
+|--------|--------|--------|
+| **Code Changes** | None required | ✅ Safe |
+| **Dependencies** | All compatible | ✅ Safe |
+| **Permissions** | Already handled | ✅ Safe |
+| **Device Coverage** | ~0.1% loss | ⚠️ Minimal |
+| **Build Config** | 1 line change | ✅ Simple |
+| **Testing** | Standard testing | ✅ Required |
+| **Risk Level** | Low | ✅ Low Risk |
+
+**Final Recommendation:** Proceed with upgrade. The benefits (Capacitor compliance, future-proofing) outweigh the minimal risks (negligible device loss, no code changes needed).
+

doc/android-asset-validation.md

@@ -0,0 +1,238 @@
+# Android Asset Validation System
+
+**Author**: Matthew Raymer  
+**Date**: 2025-08-22  
+**Status**: 🎯 **ACTIVE** - Production Ready
+
+## Overview
+
+The Android Asset Validation System automatically detects and fixes missing Android resources before building, preventing common build failures related to missing splash screens and app icons.
+
+## Problem Solved
+
+Previously, Android builds would fail with errors like:
+```
+error: resource drawable/splash (aka app.timesafari.app:drawable/splash) not found.
+error: resource mipmap/ic_launcher (aka app.timesafari.app:mipmap/ic_launcher) not found.
+```
+
+This happened when:
+- Source assets existed but weren't generated into Android resources
+- Android resource directories were missing
+- Asset generation tools weren't run before building
+
+## Solution
+
+### Enhanced Build Script Validation
+
+The `scripts/build-android.sh` script now includes comprehensive asset validation that:
+
+1. **Checks Source Assets**: Validates that required source files exist in `resources/`
+2. **Checks Android Resources**: Verifies that generated Android resources exist
+3. **Auto-Regenerates**: Automatically regenerates missing resources when detected
+4. **Verifies Results**: Confirms that regeneration was successful
+
+### Validation Process
+
+```bash
+# Validates and regenerates if needed
+npm run assets:validate:android
+
+# Full build with validation
+npm run build:android:studio
+```
+
+### What Gets Validated
+
+#### Source Assets (Required)
+- `resources/icon.png` - App icon source
+- `resources/splash.png` - Splash screen source  
+- `resources/splash_dark.png` - Dark mode splash source
+
+#### Android Resources (Generated)
+- `android/app/src/main/res/drawable/splash.png` - Splash screen drawable
+- `android/app/src/main/res/mipmap-*/ic_launcher.png` - App icons for all densities
+- `android/app/src/main/res/mipmap-*/ic_launcher_round.png` - Round app icons for all densities
+
+### Density Levels Checked
+- `mipmap-mdpi` (1x)
+- `mipmap-hdpi` (1.5x)  
+- `mipmap-xhdpi` (2x)
+- `mipmap-xxhdpi` (3x)
+- `mipmap-xxxhdpi` (4x)
+
+## Usage
+
+### Automatic Validation (Recommended)
+The validation runs automatically during all Android builds:
+
+```bash
+# Development build with validation
+npm run build:android:studio
+
+# Production build with validation  
+npm run build:android:prod
+
+# Debug build with validation
+npm run build:android:debug
+```
+
+### Manual Validation
+Run validation only to check/fix assets:
+
+```bash
+# Validate and regenerate if needed
+npm run assets:validate:android
+
+# Alternative command
+./scripts/build-android.sh --assets-only
+```
+
+### Validation Only (No Regeneration)
+Check configuration without fixing:
+
+```bash
+npm run assets:validate
+```
+
+## Error Handling
+
+### Missing Source Assets
+If source assets are missing, the build fails with clear error messages:
+
+```
+[ERROR] Missing source assets:
+[ERROR]   - resources/icon.png
+[ERROR]   - resources/splash.png
+[ERROR] Please ensure all required assets are present in the resources/ directory.
+```
+
+### Missing Generated Resources
+If generated resources are missing, they're automatically regenerated:
+
+```
+[WARN] Missing Android resources detected:
+[WARN]   - drawable/splash.png
+[WARN]   - mipmap-mdpi/ic_launcher.png
+[INFO] Regenerating Android assets...
+[SUCCESS] Android assets regenerated successfully
+```
+
+### Generation Failure
+If regeneration fails, helpful guidance is provided:
+
+```
+[ERROR] Failed to generate Android assets
+[INFO] You may need to manually create the missing resources:
+[INFO]   - android/app/src/main/res/drawable/splash.png
+[INFO]   - android/app/src/main/res/mipmap-mdpi/ic_launcher.png
+```
+
+## Integration Points
+
+### Build Script Integration
+The validation is integrated into the main build process:
+
+```bash
+# In scripts/build-android.sh
+validate_dependencies
+validate_android_assets || {
+    log_error "Android asset validation failed. Please fix the issues above and try again."
+    exit 9
+}
+```
+
+### NPM Scripts
+New npm scripts for asset management:
+
+```json
+{
+  "assets:validate": "npx tsx scripts/assets-validator.ts",
+  "assets:validate:android": "./scripts/build-android.sh --assets-only",
+  "assets:clean": "rimraf android/app/src/main/res/mipmap-* ios/App/App/Assets.xcassets/**/AppIcon*.png ios/App/App/Assets.xcassets/**/Splash*.png || true"
+}
+```
+
+## Benefits
+
+### For Developers
+- **No More Build Failures**: Automatic detection and fixing of missing resources
+- **Faster Development**: No need to manually run asset generation tools
+- **Clear Error Messages**: Helpful guidance when issues occur
+- **Consistent Results**: Same validation on all development machines
+
+### For CI/CD
+- **Reliable Builds**: Consistent asset validation across environments
+- **Early Detection**: Catches issues before they reach production
+- **Automated Fixes**: Self-healing builds when possible
+
+### For Project Maintenance
+- **Reduced Support**: Fewer "build doesn't work" issues
+- **Documentation**: Clear requirements for required assets
+- **Standardization**: Consistent asset structure across the project
+
+## Troubleshooting
+
+### Common Issues
+
+#### "No assets found in the asset path"
+This occurs when the `assets/` directory is empty. The validation system automatically copies source assets and regenerates them.
+
+#### "Failed to generate Android assets"
+Check that:
+- Source assets exist in `resources/`
+- `@capacitor/assets` is installed
+- You have write permissions to the Android directories
+
+#### "Asset generation completed but some resources are still missing"
+This indicates a problem with the asset generation tool. Try:
+1. Running `npm install` to ensure dependencies are up to date
+2. Manually running `npx @capacitor/assets generate`
+3. Checking the asset generation logs for specific errors
+
+### Manual Recovery
+If automatic regeneration fails, you can manually create the missing resources:
+
+```bash
+# Create missing directories
+mkdir -p android/app/src/main/res/drawable
+mkdir -p android/app/src/main/res/mipmap-{mdpi,hdpi,xhdpi,xxhdpi,xxxhdpi}
+
+# Copy source assets to assets directory
+cp resources/icon.png assets/
+cp resources/splash.png assets/
+cp resources/splash_dark.png assets/
+
+# Generate assets manually
+npx @capacitor/assets generate
+
+# Clean up
+rm assets/icon.png assets/splash.png assets/splash_dark.png
+```
+
+## Future Enhancements
+
+### Planned Improvements
+- **iOS Asset Validation**: Extend validation to iOS assets
+- **Asset Quality Checks**: Validate image dimensions and formats
+- **Performance Optimization**: Cache validation results
+- **CI/CD Integration**: Add validation to GitHub Actions
+
+### Configuration Options
+- **Custom Asset Paths**: Support for different asset directory structures
+- **Validation Rules**: Configurable validation requirements
+- **Skip Options**: Ability to skip validation for specific scenarios
+
+## References
+
+- [Capacitor Assets Documentation](https://github.com/ionic-team/capacitor-assets)
+- [Android Resource System](https://developer.android.com/guide/topics/resources/providing-resources)
+- [Build Script Documentation](./build-android.sh)
+- [Asset Configuration](./capacitor-assets.config.json)
+
+---
+
+**Status**: Active validation system  
+**Priority**: High  
+**Maintainer**: Development team  
+**Next Review**: 2025-09-22

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-emulator-deployment-guide.md

@@ -0,0 +1,655 @@
+# Android Emulator Deployment Guide (No Android Studio)
+
+**Author**: Matthew Raymer  
+**Date**: 2025-01-27  
+**Status**: 🎯 **ACTIVE** - Complete guide for deploying TimeSafari to Android emulator using command-line tools
+
+## Overview
+
+This guide provides comprehensive instructions for building and deploying TimeSafari to Android emulators using only command-line tools, without requiring Android Studio. It leverages the existing build system and adds emulator-specific deployment workflows.
+
+## Prerequisites
+
+### Required Tools
+
+1. **Android SDK Command Line Tools**
+   ```bash
+   # Install via package manager (Arch Linux)
+   sudo pacman -S android-sdk-cmdline-tools-latest
+   
+   # Or download from Google
+   # https://developer.android.com/studio/command-line
+   ```
+
+2. **Android SDK Platform Tools**
+   ```bash
+   # Install via package manager
+   sudo pacman -S android-sdk-platform-tools
+   
+   # Or via Android SDK Manager
+   sdkmanager "platform-tools"
+   ```
+
+3. **Android SDK Build Tools**
+   ```bash
+   sdkmanager "build-tools;34.0.0"
+   ```
+
+4. **Android Platform**
+   ```bash
+   sdkmanager "platforms;android-34"
+   ```
+
+5. **Android Emulator**
+   ```bash
+   sdkmanager "emulator"
+   ```
+
+6. **System Images**
+   ```bash
+   # For API 34 (Android 14)
+   sdkmanager "system-images;android-34;google_apis;x86_64"
+   
+   # For API 33 (Android 13) - alternative
+   sdkmanager "system-images;android-33;google_apis;x86_64"
+   ```
+
+### Environment Setup
+
+```bash
+# Add to ~/.bashrc or ~/.zshrc
+export ANDROID_HOME=$HOME/Android/Sdk
+export ANDROID_AVD_HOME=$HOME/.android/avd  # Important for AVD location
+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 shell
+source ~/.bashrc
+```
+
+### Verify Installation
+
+```bash
+# Check all tools are available
+adb version
+emulator -version
+avdmanager list
+```
+
+## Resource-Aware Emulator Setup
+
+### ⚡ **Quick Start Recommendation**
+
+**For best results, always start with resource analysis:**
+
+```bash
+# 1. Check your system capabilities
+./scripts/avd-resource-checker.sh
+
+# 2. Use the generated optimal startup script
+/tmp/start-avd-TimeSafari_Emulator.sh
+
+# 3. Deploy your app
+npm run build:android:dev
+adb install -r android/app/build/outputs/apk/debug/app-debug.apk
+```
+
+This prevents system lockups and ensures optimal performance.
+
+### AVD Resource Checker Script
+
+**New Feature**: TimeSafari includes an intelligent resource checker that automatically detects your system capabilities and recommends optimal AVD configurations.
+
+```bash
+# Check system resources and get recommendations
+./scripts/avd-resource-checker.sh
+
+# Check resources for specific AVD
+./scripts/avd-resource-checker.sh TimeSafari_Emulator
+
+# Test AVD startup performance
+./scripts/avd-resource-checker.sh TimeSafari_Emulator --test
+
+# Create optimized AVD with recommended settings
+./scripts/avd-resource-checker.sh TimeSafari_Emulator --create
+```
+
+**What the script analyzes:**
+- **System Memory**: Total and available RAM
+- **CPU Cores**: Available processing power
+- **GPU Capabilities**: NVIDIA, AMD, Intel, or software rendering
+- **Hardware Acceleration**: Optimal graphics settings
+
+**What it generates:**
+- **Optimal configuration**: Memory, cores, and GPU settings
+- **Startup command**: Ready-to-use emulator command
+- **Startup script**: Saved to `/tmp/start-avd-{name}.sh` for reuse
+
+## Emulator Management
+
+### Create Android Virtual Device (AVD)
+
+```bash
+# List available system images
+avdmanager list target
+
+# Create AVD for API 34
+avdmanager create avd \
+  --name "TimeSafari_Emulator" \
+  --package "system-images;android-34;google_apis;x86_64" \
+  --device "pixel_7"
+
+# List created AVDs
+avdmanager list avd
+```
+
+### Start Emulator
+
+```bash
+# Start emulator with hardware acceleration (recommended)
+emulator -avd TimeSafari_Emulator -gpu host -no-audio &
+
+# Start with reduced resources (if system has limited RAM)
+emulator -avd TimeSafari_Emulator \
+  -no-audio \
+  -memory 2048 \
+  -cores 2 \
+  -gpu swiftshader_indirect &
+
+# Start with minimal resources (safest for low-end systems)
+emulator -avd TimeSafari_Emulator \
+  -no-audio \
+  -memory 1536 \
+  -cores 1 \
+  -gpu swiftshader_indirect &
+
+# Check if emulator is running
+adb devices
+```
+
+### Resource Management
+
+**Important**: Android emulators can consume significant system resources. Choose the appropriate configuration based on your system:
+
+- **High-end systems** (16GB+ RAM, dedicated GPU): Use `-gpu host`
+- **Mid-range systems** (8-16GB RAM): Use `-memory 2048 -cores 2`
+- **Low-end systems** (4-8GB RAM): Use `-memory 1536 -cores 1 -gpu swiftshader_indirect`
+
+### Emulator Control
+
+```bash
+# Stop emulator
+adb emu kill
+
+# Restart emulator
+adb reboot
+
+# Check emulator status
+adb get-state
+```
+
+## Build and Deploy Workflow
+
+### Method 1: Using Existing Build Scripts
+
+The TimeSafari project already has comprehensive Android build scripts that can be adapted for emulator deployment:
+
+```bash
+# Development build with auto-run
+npm run build:android:dev:run
+
+# Test build with auto-run  
+npm run build:android:test:run
+
+# Production build with auto-run
+npm run build:android:prod:run
+```
+
+### Method 2: Custom Emulator Deployment Script
+
+Create a new script specifically for emulator deployment:
+
+```bash
+# Create emulator deployment script
+cat > scripts/deploy-android-emulator.sh << 'EOF'
+#!/bin/bash
+# deploy-android-emulator.sh
+# Author: Matthew Raymer
+# Date: 2025-01-27
+# Description: Deploy TimeSafari to Android emulator without Android Studio
+
+set -e
+
+# Source common utilities
+source "$(dirname "$0")/common.sh"
+
+# Default values
+BUILD_MODE="development"
+AVD_NAME="TimeSafari_Emulator"
+START_EMULATOR=true
+CLEAN_BUILD=true
+
+# Parse command line arguments
+while [[ $# -gt 0 ]]; do
+    case $1 in
+        --dev|--development)
+            BUILD_MODE="development"
+            shift
+            ;;
+        --test)
+            BUILD_MODE="test"
+            shift
+            ;;
+        --prod|--production)
+            BUILD_MODE="production"
+            shift
+            ;;
+        --avd)
+            AVD_NAME="$2"
+            shift 2
+            ;;
+        --no-start-emulator)
+            START_EMULATOR=false
+            shift
+            ;;
+        --no-clean)
+            CLEAN_BUILD=false
+            shift
+            ;;
+        -h|--help)
+            echo "Usage: $0 [options]"
+            echo "Options:"
+            echo "  --dev, --development    Build for development"
+            echo "  --test                  Build for testing"
+            echo "  --prod, --production    Build for production"
+            echo "  --avd NAME              Use specific AVD name"
+            echo "  --no-start-emulator     Don't start emulator"
+            echo "  --no-clean              Skip clean build"
+            echo "  -h, --help             Show this help"
+            exit 0
+            ;;
+        *)
+            log_error "Unknown option: $1"
+            exit 1
+            ;;
+    esac
+done
+
+# Function to check if emulator is running
+check_emulator_running() {
+    if adb devices | grep -q "emulator.*device"; then
+        return 0
+    else
+        return 1
+    fi
+}
+
+# Function to start emulator
+start_emulator() {
+    log_info "Starting Android emulator: $AVD_NAME"
+    
+    # Check if AVD exists
+    if ! avdmanager list avd | grep -q "$AVD_NAME"; then
+        log_error "AVD '$AVD_NAME' not found. Please create it first."
+        log_info "Create AVD with: avdmanager create avd --name $AVD_NAME --package system-images;android-34;google_apis;x86_64"
+        exit 1
+    fi
+    
+    # Start emulator in background
+    emulator -avd "$AVD_NAME" -no-audio -no-snapshot &
+    EMULATOR_PID=$!
+    
+    # Wait for emulator to boot
+    log_info "Waiting for emulator to boot..."
+    adb wait-for-device
+    
+    # Wait for boot to complete
+    log_info "Waiting for boot to complete..."
+    while [ "$(adb shell getprop sys.boot_completed)" != "1" ]; do
+        sleep 2
+    done
+    
+    log_success "Emulator is ready!"
+}
+
+# Function to build and deploy
+build_and_deploy() {
+    log_info "Building TimeSafari for $BUILD_MODE mode..."
+    
+    # Clean build if requested
+    if [ "$CLEAN_BUILD" = true ]; then
+        log_info "Cleaning previous build..."
+        npm run clean:android
+    fi
+    
+    # Build based on mode
+    case $BUILD_MODE in
+        "development")
+            npm run build:android:dev
+            ;;
+        "test")
+            npm run build:android:test
+            ;;
+        "production")
+            npm run build:android:prod
+            ;;
+    esac
+    
+    # Deploy to emulator
+    log_info "Deploying to emulator..."
+    adb install -r android/app/build/outputs/apk/debug/app-debug.apk
+    
+    # Launch app
+    log_info "Launching TimeSafari..."
+    adb shell am start -n app.timesafari/.MainActivity
+    
+    log_success "TimeSafari deployed and launched successfully!"
+}
+
+# Main execution
+main() {
+    log_info "TimeSafari Android Emulator Deployment"
+    log_info "Build Mode: $BUILD_MODE"
+    log_info "AVD Name: $AVD_NAME"
+    
+    # Start emulator if requested and not running
+    if [ "$START_EMULATOR" = true ]; then
+        if ! check_emulator_running; then
+            start_emulator
+        else
+            log_info "Emulator already running"
+        fi
+    fi
+    
+    # Build and deploy
+    build_and_deploy
+    
+    log_success "Deployment completed successfully!"
+}
+
+# Run main function
+main "$@"
+EOF
+
+# Make script executable
+chmod +x scripts/deploy-android-emulator.sh
+```
+
+### Method 3: Direct Command Line Deployment
+
+For quick deployments without scripts:
+
+```bash
+# 1. Ensure emulator is running
+adb devices
+
+# 2. Build the app
+npm run build:android:dev
+
+# 3. Install APK
+adb install -r android/app/build/outputs/apk/debug/app-debug.apk
+
+# 4. Launch app
+adb shell am start -n app.timesafari/.MainActivity
+
+# 5. View logs
+adb logcat | grep -E "(TimeSafari|Capacitor|MainActivity)"
+```
+
+## Advanced Deployment Options
+
+### Custom API Server Configuration
+
+For development with custom API endpoints:
+
+```bash
+# Build with custom API IP
+npm run build:android:dev:custom
+
+# Or modify capacitor.config.ts for specific IP
+# Then build normally
+npm run build:android:dev
+```
+
+### Debug vs Release Builds
+
+```bash
+# Debug build (default)
+npm run build:android:debug
+
+# Release build
+npm run build:android:release
+
+# Install specific build
+adb install -r android/app/build/outputs/apk/release/app-release.apk
+```
+
+### Asset Management
+
+```bash
+# Validate Android assets
+npm run assets:validate:android
+
+# Generate assets only
+npm run build:android:assets
+
+# Clean assets
+npm run assets:clean
+```
+
+## Troubleshooting
+
+### Common Issues
+
+1. **Emulator Not Starting / AVD Not Found**
+   ```bash
+   # Check available AVDs
+   avdmanager list avd
+   
+   # If AVD exists but emulator can't find it, check AVD location
+   echo $ANDROID_AVD_HOME
+   ls -la ~/.android/avd/
+   
+   # Fix AVD path issue (common on Arch Linux)
+   export ANDROID_AVD_HOME=/home/$USER/.config/.android/avd
+   
+   # Or create symlinks if AVDs are in different location
+   mkdir -p ~/.android/avd
+   ln -s /home/$USER/.config/.android/avd/* ~/.android/avd/
+   
+   # Create new AVD if needed
+   avdmanager create avd --name "TimeSafari_Emulator" --package "system-images;android-34;google_apis;x86_64"
+   
+   # Check emulator logs
+   emulator -avd TimeSafari_Emulator -verbose
+   ```
+
+2. **System Lockup / High Resource Usage**
+   ```bash
+   # Kill any stuck emulator processes
+   pkill -f emulator
+   
+   # Check system resources
+   free -h
+   nvidia-smi  # if using NVIDIA GPU
+   
+   # Start with minimal resources
+   emulator -avd TimeSafari_Emulator \
+     -no-audio \
+     -memory 1536 \
+     -cores 1 \
+     -gpu swiftshader_indirect &
+   
+   # Monitor resource usage
+   htop
+   
+   # If still having issues, try software rendering only
+   emulator -avd TimeSafari_Emulator \
+     -no-audio \
+     -no-snapshot \
+     -memory 1024 \
+     -cores 1 \
+     -gpu off &
+   ```
+
+3. **ADB Device Not Found**
+   ```bash
+   # Restart ADB server
+   adb kill-server
+   adb start-server
+   
+   # Check devices
+   adb devices
+   
+   # Check emulator status
+   adb get-state
+   ```
+
+3. **Build Failures**
+   ```bash
+   # Clean everything
+   npm run clean:android
+   
+   # Rebuild
+   npm run build:android:dev
+   
+   # Check Gradle logs
+   cd android && ./gradlew clean --stacktrace
+   ```
+
+4. **Installation Failures**
+   ```bash
+   # Uninstall existing app
+   adb uninstall app.timesafari
+   
+   # Reinstall
+   adb install android/app/build/outputs/apk/debug/app-debug.apk
+   
+   # Check package info
+   adb shell pm list packages | grep timesafari
+   ```
+
+### Performance Optimization
+
+1. **Emulator Performance**
+   ```bash
+   # Start with hardware acceleration
+   emulator -avd TimeSafari_Emulator -gpu host
+   
+   # Use snapshot for faster startup
+   emulator -avd TimeSafari_Emulator -snapshot default
+   
+   # Allocate more RAM
+   emulator -avd TimeSafari_Emulator -memory 4096
+   ```
+
+2. **Build Performance**
+   ```bash
+   # Use Gradle daemon
+   echo "org.gradle.daemon=true" >> android/gradle.properties
+   
+   # Increase heap size
+   echo "org.gradle.jvmargs=-Xmx4g" >> android/gradle.properties
+   
+   # Enable parallel builds
+   echo "org.gradle.parallel=true" >> android/gradle.properties
+   ```
+
+## Integration with Existing Build System
+
+### NPM Scripts Integration
+
+Add emulator-specific scripts to `package.json`:
+
+```json
+{
+  "scripts": {
+    "emulator:check": "./scripts/avd-resource-checker.sh",
+    "emulator:check:test": "./scripts/avd-resource-checker.sh TimeSafari_Emulator --test",
+    "emulator:check:create": "./scripts/avd-resource-checker.sh TimeSafari_Emulator --create",
+    "emulator:start": "emulator -avd TimeSafari_Emulator -no-audio &",
+    "emulator:start:optimized": "/tmp/start-avd-TimeSafari_Emulator.sh",
+    "emulator:stop": "adb emu kill",
+    "emulator:deploy": "./scripts/deploy-android-emulator.sh",
+    "emulator:deploy:dev": "./scripts/deploy-android-emulator.sh --dev",
+    "emulator:deploy:test": "./scripts/deploy-android-emulator.sh --test",
+    "emulator:deploy:prod": "./scripts/deploy-android-emulator.sh --prod",
+    "emulator:logs": "adb logcat | grep -E '(TimeSafari|Capacitor|MainActivity)'",
+    "emulator:shell": "adb shell"
+  }
+}
+```
+
+### CI/CD Integration
+
+For automated testing and deployment:
+
+```bash
+# GitHub Actions example
+- name: Start Android Emulator
+  run: |
+    emulator -avd TimeSafari_Emulator -no-audio -no-snapshot &
+    adb wait-for-device
+    adb shell getprop sys.boot_completed
+
+- name: Build and Deploy
+  run: |
+    npm run build:android:test
+    adb install -r android/app/build/outputs/apk/debug/app-debug.apk
+    adb shell am start -n app.timesafari/.MainActivity
+
+- name: Run Tests
+  run: |
+    npm run test:android
+```
+
+## Best Practices
+
+### Development Workflow
+
+1. **Start emulator once per session**
+   ```bash
+   emulator -avd TimeSafari_Emulator -no-audio &
+   ```
+
+2. **Use incremental builds**
+   ```bash
+   # For rapid iteration
+   npm run build:android:sync
+   adb install -r android/app/build/outputs/apk/debug/app-debug.apk
+   ```
+
+3. **Monitor logs continuously**
+   ```bash
+   adb logcat | grep -E "(TimeSafari|Capacitor|MainActivity)" --color=always
+   ```
+
+### Performance Tips
+
+1. **Use snapshots for faster startup**
+2. **Enable hardware acceleration**
+3. **Allocate sufficient RAM (4GB+)**
+4. **Use SSD storage for AVDs**
+5. **Close unnecessary applications**
+
+### Security Considerations
+
+1. **Use debug builds for development only**
+2. **Never commit debug keystores**
+3. **Use release builds for testing**
+4. **Validate API endpoints in production builds**
+
+## Conclusion
+
+This guide provides a complete solution for deploying TimeSafari to Android emulators without Android Studio. The approach leverages the existing build system while adding emulator-specific deployment capabilities.
+
+The key benefits:
+- ✅ **No Android Studio required**
+- ✅ **Command-line only workflow**
+- ✅ **Integration with existing build scripts**
+- ✅ **Automated deployment options**
+- ✅ **Comprehensive troubleshooting guide**
+
+For questions or issues, refer to the troubleshooting section or check the existing build documentation in `BUILDING.md`.

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`).