doc: Fix merge conflict.

- Apply markdown.mdc formatting to all ruleset files (80-char line length, proper spacing)
- Update timesafari.mdc to reflect completed migration (remove triple migration pattern references)
- Clean up corrupted logging_standards.mdc and restore proper content
- Streamline architectural_decision_record.mdc for better readability
- Update all file dates to 2025-08-19 for consistency
- Add proper document headers and metadata to all ruleset files
- Remove duplicate content and improve file organization
- Maintain alwaysApply settings and glob patterns appropriately

Files affected: 15 ruleset files across app/, database/, development/, features/, workflow/ directories

.cursor/rules/adr_template.mdc

@@ -2,14 +2,16 @@
 
 ## ADR-XXXX-YY-ZZ: [Short Title]
 
-**Date:** YYYY-MM-DD  
-**Status:** [PROPOSED | ACCEPTED | REJECTED | DEPRECATED | SUPERSEDED]  
-**Deciders:** [List of decision makers]  
+**Date:** YYYY-MM-DD
+**Status:** [PROPOSED | ACCEPTED | REJECTED | DEPRECATED | SUPERSEDED]
+**Deciders:** [List of decision makers]
 **Technical Story:** [Link to issue/PR if applicable]
 
 ## Context
 
-[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.]
+[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.]
 
 ## Decision
 

.cursor/rules/app/architectural_decision_record.mdc

@@ -1,10 +1,13 @@
 ---
-description: 
-globs: 
-alwaysApply: true
+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
+**Date**: 2025-08-19
+**Status**: 🎯 **ACTIVE** - Architecture guidelines
+
 ## 1. Platform Support Matrix
 
 | Feature | Web (PWA) | Capacitor (Mobile) | Electron (Desktop) |
@@ -15,11 +18,10 @@ alwaysApply: true
 | 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
@@ -38,14 +40,13 @@ src/
 ```
 
 ### 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
@@ -64,28 +65,30 @@ services/
 ```
 
 ### Factory Pattern
-Use a **singleton factory** to select platform services via `process.env.VITE_PLATFORM`.
 
----
+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).
+- 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", …)`
 
----
+- 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`  
+- `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
@@ -94,78 +97,255 @@ 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.  
+- **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.
-
----
+> 🔗 **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).  
+- 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/`.  
+- 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).  
-
----
+- 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.  
-
----
+- 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.  
-
----
+- **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.  
+- 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.
-
----
+> 🔗 **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.  
+- **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?
 
 ---
 
-# Self-Check
+**Status**: Active architecture guidelines
+**Priority**: High
+**Estimated Effort**: Ongoing reference
+**Dependencies**: Vue 3, Capacitor, Electron, Vite
+**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?
+
+---
+
+**Status**: Active architecture guidelines
+**Priority**: High
+**Estimated Effort**: Ongoing reference
+**Dependencies**: Vue 3, Capacitor, Electron, Vite
+**Stakeholders**: Development team, Architecture team
 
-- [ ] 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?  

.cursor/rules/app/timesafari.mdc

@@ -1,316 +1,181 @@
----
-description:
-globs:
-alwaysApply: true
----
 # Time Safari Context
 
+**Author**: Matthew Raymer
+**Date**: 2025-08-19
+**Status**: 🎯 **ACTIVE** - Core application context
+
 ## Project Overview
 
-Time Safari is an application designed to foster community building through gifts,
-gratitude, and collaborative projects. The app should make it extremely easy and
-intuitive for users of any age and capability to recognize contributions, build
-trust networks, and organize collective action. It is built on services that
-preserve privacy and data sovereignty.
+Time Safari is an application designed to foster community building through
+gifts, gratitude, and collaborative projects. The app makes it easy and
+intuitive for users of any age and capability to recognize contributions,
+build trust networks, and organize collective action. It is built on services
+that preserve privacy and data sovereignty.
 
-The ultimate goals of Time Safari are two-fold:
+## 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. This helps people accomplish and learn from other individuals in
-less-structured environments; moreover, it helps them discover who they want
-to continue to support and with whom they want to maintain relationships.
-
-2. **Reveal** Widely advertise the great support and rewards that are being
-given and accepted freely, especially non-monetary ones. Using visuals and text,
-display the kind of impact that gifts are making in the lives of others. Also
-show useful and engaging reports of project statistics and personal accomplishments.
-
-
-## Core Approaches
-
-Time Safari should help everyday users build meaningful connections and organize
-collective efforts by:
-
-1. **Recognizing Contributions**: Creating permanent, verifiable records of gifts
-and contributions people give to each other and their communities.
-
-2. **Facilitating Collaboration**: Making it ridiculously easy for people to ask
-for or propose help on projects and interests that matter to them.
-
-3. **Building Trust Networks**: Enabling users to maintain their network and activity
-visibility. Developing reputation through verified contributions and references,
-which can be selectively shown to others outside the network.
-
-4. **Preserving Privacy**: Ensuring personal identifiers are only shared with
-explicitly authorized contacts, allowing private individuals including children
-to participate safely.
-
-5. **Engaging Content**: Displaying people's records in compelling stories, and
-highlighting those projects that are lifting people's lives long-term, both in
-physical support and in emotional-spiritual-creative thriving.
+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.
 
 ## Technical Foundation
 
-This application is built on a privacy-preserving claims architecture (via
-endorser.ch) with these key characteristics:
+### Architecture
 
-- **Decentralized Identifiers (DIDs)**: User identities are based on public/private
-key pairs stored on their devices
+- **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
+  cryptographically signed
 - **User-Controlled Visibility**: Users explicitly control who can see their
-identifiers and data
-- **Merkle-Chained Claims**: Claims are cryptographically chained for verification
-and integrity
-- **Native and Web App**: Works on Capacitor (iOS, Android), Desktop (Electron
-and CEFPython), and web browsers
+  identifiers and data
+- **Cross-Platform**: Web (PWA), Mobile (Capacitor), Desktop (Electron)
 
-## User Journey
+### Current Database State
 
-The typical progression of usage follows these stages:
+- **Database**: SQLite via Absurd SQL (browser) and native SQLite
+  (mobile/desktop)
+- **Legacy Support**: IndexedDB (Dexie) for backward compatibility
+- **Status**: Modern database architecture fully implemented
 
-1. **Gratitude & Recognition**: Users begin by expressing and recording gratitude
-for gifts received, building a foundation of acknowledgment.
+### Core Technologies
 
-2. **Project Proposals**: Users propose projects and ideas, reaching out to connect
-with others who share similar interests.
+- **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
 
-3. **Action Triggers**: Offers of help serve as triggers and motivations to execute
-proposed projects, moving from ideas to action.
+## Development Principles
 
-## Context for LLM Development
+### Code Organization
 
-When developing new functionality for Time Safari, consider these design principles:
+- **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
 
-1. **Accessibility First**: Features should be usable by non-technical users with
-minimal learning curve.
+### Architecture Patterns
 
-2. **Privacy by Design**: All features must respect user privacy and data sovereignty.
+- **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
 
-3. **Progressive Enhancement**: Core functionality should work across all devices,
-with richer experiences where supported.
+### Testing Strategy
 
-4. **Voluntary Collaboration**: The system should enable but never coerce participation.
+- **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
 
-5. **Trust Building**: Features should help build verifiable trust between users.
+## Current Development Focus
 
-6. **Network Effects**: Consider how features scale as more users join the platform.
+### Active Development
 
-7. **Low Resource Requirements**: The system should be lightweight enough to run
-on inexpensive devices users already own.
+- **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
 
-LLM development should focus on enhancing these key use cases:
+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
 
-1. **Community Building**: Tools that help people find others with shared
-interests and values.
+## Resources
 
-2. **Project Coordination**: Features that make it easy to propose collaborative
-projects and to submit suggestions and offers to existing ones.
+- **Testing**: `docs/migration-testing/`
+- **Architecture**: `docs/architecture-decisions.md`
+- **Build Context**: `docs/build-modernization-context.md`
 
-3. **Reputation Building**: Methods for users to showcase their contributions
-and reliability, in contexts where they explicitly reveal that information.
+---
 
-4. **Governance Experimentation**: Features that facilitate decision-making and
-collective governance.
+## Status: Active application context
 
-## Constraints
-
-When developing new features, be mindful of these constraints:
-
-1. **Privacy Preservation**: User identifiers must remain private except when
-explicitly shared.
-
-2. **Platform Limitations**: Features must work within the constraints of the target
-app platforms, while aiming to leverage the best platform technology available.
-
-3. **Endorser API Limitations**: Backend features are constrained by the endorser.ch
-API capabilities.
-
-4. **Performance on Low-End Devices**: The application should remain performant
-on older/simpler devices.
-
-5. **Offline-First When Possible**: Key functionality should work offline when feasible.
-
-## Project Technologies
-
-- Typescript using ES6 classes using vue-facing-decorator
-- TailwindCSS
-- Vite Build Tool
-- Playwright E2E testing
-- IndexDB
-- Camera, Image uploads, QR Code reader, ...
-
-## Mobile Features
-
-- Deep Linking
-- Local Notifications via a custom Capacitor plugin
-
-## Project Architecture
-
-- The application must work on web browser, PWA (Progressive Web Application),
-  desktop via Electron, and mobile via Capacitor
-- Building for each platform is managed via Vite
-
-## Core Development Principles
-
-### DRY development
-
-- **Code Reuse**
-  - Extract common functionality into utility functions
-  - Create reusable components for UI patterns
-  - Implement service classes for shared business logic
-  - Use mixins for cross-cutting concerns
-  - Leverage TypeScript interfaces for shared type definitions
-
-- **Component Patterns**
-  - Create base components for common UI elements
-  - Implement higher-order components for shared behavior
-  - Use slot patterns for flexible component composition
-  - Create composable services for business logic
-  - Implement factory patterns for component creation
-
-- **State Management**
-  - Centralize state in Pinia stores
-  - Use computed properties for derived state
-  - Implement shared state selectors
-  - Create reusable state mutations
-  - Use action creators for common operations
-
-- **Error Handling**
-  - Implement centralized error handling
-  - Create reusable error components
-  - Use error boundary components
-  - Implement consistent error logging
-  - Create error type definitions
-
-- **Type Definitions**
-  - Create shared interfaces for common data structures
-  - Use type aliases for complex types
-  - Implement generic types for reusable components
-  - Create utility types for common patterns
-  - Use discriminated unions for state management
-
-- **API Integration**
-  - Create reusable API client classes
-  - Implement request/response interceptors
-  - Use consistent error handling patterns
-  - Create type-safe API endpoints
-  - Implement caching strategies
-
-- **Platform Services**
-  - Abstract platform-specific code behind interfaces
-  - Create platform-agnostic service layers
-  - Implement feature detection
-  - Use dependency injection for services
-  - Create service factories
-
-- **Testing**
-  - Create reusable test utilities
-  - Implement test factories
-  - Use shared test configurations
-  - Create reusable test helpers
-  - Implement consistent test patterns
-  - F.I.R.S.T. (for Unit Tests)
-    F – Fast
-    I – Independent
-    R – Repeatable
-    S – Self-validating
-    T – Timely
-
-### SOLID Principles
-
-- **Single Responsibility**: Each class/component should have only one reason to
-  change
-  - Components should focus on one specific feature (e.g., QR scanning, DID management)
-  - Services should handle one type of functionality (e.g., platform services,
-    crypto services)
-  - Utilities should provide focused helper functions
-
-- **Open/Closed**: Software entities should be open for extension but closed for
-  modification
-  - Use interfaces for service definitions
-  - Implement plugin architecture for platform-specific features
-  - Allow component behavior extension through props and events
-
-- **Liskov Substitution**: Objects should be replaceable with their subtypes
-  - Platform services should work consistently across web/mobile
-  - Authentication providers should be interchangeable
-  - Storage implementations should be swappable
-
-- **Interface Segregation**: Clients shouldn't depend on interfaces they don't use
-  - Break down large service interfaces into smaller, focused ones
-  - Component props should be minimal and purposeful
-  - Event emissions should be specific and targeted
-
-- **Dependency Inversion**: High-level modules shouldn't depend on low-level modules
-  - Use dependency injection for services
-  - Abstract platform-specific code behind interfaces
-  - Implement factory patterns for component creation
-
-### Law of Demeter
-
-- Components should only communicate with immediate dependencies
-- Avoid chaining method calls (e.g., `this.service.getUser().getProfile().getName()`)
-- Use mediator patterns for complex component interactions
-- Implement facade patterns for subsystem access
-- Keep component communication through defined events and props
-
-### Composition over Inheritance
-
-- Prefer building components through composition
-- Use mixins for shared functionality
-- Implement feature toggles through props
-- Create higher-order components for common patterns
-- Use service composition for complex features
-
-### Interface Segregation
-
-- Define clear interfaces for services
-- Keep component APIs minimal and focused
-- Split large interfaces into smaller, specific ones
-- Use TypeScript interfaces for type definitions
-- Implement role-based interfaces for different use cases
-
-### Fail Fast
-
-- Validate inputs early in the process
-- Use TypeScript strict mode
-- Implement comprehensive error handling
-- Add runtime checks for critical operations
-- Use assertions for development-time validation
-
-### Principle of Least Astonishment
-
-- Follow Vue.js conventions consistently
-- Use familiar naming patterns
-- Implement predictable component behaviors
-- Maintain consistent error handling
-- Keep UI interactions intuitive
-
-### Information Hiding
-
-- Encapsulate implementation details
-- Use private class members
-- Implement proper access modifiers
-- Hide complex logic behind simple interfaces
-- Use TypeScript's access modifiers effectively
-
-### Single Source of Truth
-
-- Use Pinia for state management
-- Maintain one source for user data
-- Centralize configuration management
-- Use computed properties for derived state
-- Implement proper state synchronization
-
-### Principle of Least Privilege
-
-- Implement proper access control
-- Use minimal required permissions
-- Follow privacy-by-design principles
-- Restrict component access to necessary data
-- Implement proper authentication/authorization
+- **Priority**: Critical
+- **Estimated Effort**: Ongoing reference
+- **Dependencies**: Vue 3, TypeScript, SQLite, Capacitor, Electron
+- **Stakeholders**: Development team, Product team

.cursor/rules/asset_configuration.mdc

@@ -1,32 +1,61 @@
 ---
-alwaysApply: true
+description: when doing anything with capacitor assets
+alwaysApply: false
 ---
 # Asset Configuration Directive
-*Scope: Assets Only (icons, splashes, image pipelines) — not overall build orchestration*
+
+**Author**: Matthew Raymer
+**Date**: 2025-08-19
+**Status**: 🎯 **ACTIVE** - Asset management guidelines
+
+*Scope: Assets Only (icons, splashes, image pipelines) — not overall build
+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.
+- **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.
+- **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/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**.
+- **Dev-time generation allowed** for these configs; **build-time
+  generation is forbidden**.
 
 ## Build-Time Behavior
+
 - Build generates platform assets (not configs) using the standard chain:
-  ```bash
-  npm run build:capacitor        # web build via Vite (.mts)
-  npx cap sync
+
+```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
+```
+
+---
+
+**Status**: Active asset management directive
+**Priority**: Medium
+**Estimated Effort**: Ongoing reference
+**Dependencies**: capacitor-assets toolchain
+**Stakeholders**: Development team, Build team
+
   npx capacitor-assets generate  # produces platform assets; not committed
   # then platform-specific build steps

.cursor/rules/base_context.mdc

@@ -1,7 +1,6 @@
 ---
 alwaysApply: true
 ---
-
 ```json
 {
   "coaching_level": "standard",
@@ -14,7 +13,12 @@ alwaysApply: true
 
 # Base Context — Human Competence First
 
+**Author**: Matthew Raymer
+**Date**: 2025-08-19
+**Status**: 🎯 **ACTIVE** - Core interaction guidelines
+
 ## Purpose
+
 All interactions must *increase the human's competence over time* while
 completing the task efficiently. The model may handle menial work and memory
 extension, but must also promote learning, autonomy, and healthy work habits.
@@ -25,57 +29,79 @@ machine-driven steps.
 
 ## Principles
 
-1) Competence over convenience: finish the task *and* leave the human more
+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
+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 repurposed.
-8) **Collaborative Bias**: Favor solutions that invite human review, discussion,
-   and iteration. When in doubt, ask "Who should this be shown to?" or "Which human
-   input would improve this?"
+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
+   repurposed.
+8. **Collaborative Bias**: Favor solutions that invite human review,
+   discussion, and iteration. When in doubt, ask "Who should this be shown
+   to?" or "Which human input would improve this?"
 
 ## Toggle Definitions
 
 ### coaching_level
 
-Determines the depth of learning support: `light` (short hooks), `standard` 
-(balanced), `deep` (detailed).
+Determines the depth of learning support: `light` (short hooks),
+`standard` (balanced), `deep` (detailed).
 
 ### socratic_max_questions
 
 The number of clarifying questions the model may ask before proceeding.
-If >0, questions should be targeted, minimal, and followed by reasonable assumptions if unanswered.
+If >0, questions should be targeted, minimal, and followed by reasonable
+assumptions if unanswered.
 
 ### verbosity
-'terse' (just a sentence), `concise` (minimum commentary), `normal` (balanced explanation), or other project-defined levels.
+
+'terse' (just a sentence), `concise` (minimum commentary), `normal`
+(balanced explanation), or other project-defined levels.
 
 ### timebox_minutes
-*integer or null* — When set to a positive integer (e.g., `5`), this acts as a **time budget** guiding the model to prioritize delivering the most essential parts of the task within that constraint.
+
+*integer or null* — When set to a positive integer (e.g., `5`), this acts
+as a **time budget** guiding the model to prioritize delivering the most
+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 responses.
+
+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
+responses.
 
 ### format_enforcement
-`strict` (reject outputs with format drift) or `relaxed` (minor deviations acceptable).
+
+`strict` (reject outputs with format drift) or `relaxed` (minor deviations
+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.
+- **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.
+- **Facilitator**: structure output to be reviewable, commentable, and
+  ready for group discussion.
 
 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)
@@ -83,6 +109,7 @@ Default: Doer + short Mentor notes.
 - "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)
@@ -92,8 +119,10 @@ Default: Doer + short Mentor notes.
 - **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 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.
@@ -104,121 +133,22 @@ Default: Doer + short Mentor notes.
 - **research_diagnostic.mdc**: For investigation and research workflows
 
 ## 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.
-- [ ] Uncertainties/assumptions surfaced.
-- [ ] No disallowed content.
-- [ ] Uncertainties/assumptions surfaced.
-- [ ] No disallowed content.
-```json
-{
-  "coaching_level": "standard",
-  "socratic_max_questions": 7,
-  "verbosity": "normal",
-  "timebox_minutes": null,
-  "format_enforcement": "strict"
-}
-```
-
-# Base Context — Human Competence First
-
-## Purpose
-All interactions must *increase the human's competence over time* while
-completing the task efficiently. The model may handle menial work and memory
-extension, but must also promote learning, autonomy, and healthy work habits.
-The model should also **encourage human interaction and collaboration** rather
-than replacing it — outputs should be designed to **facilitate human discussion,
-decision-making, and creativity**, not to atomize tasks into isolated, purely
-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 repurposed.
-8) **Collaborative Bias**: Favor solutions that invite human review, discussion,
-   and iteration. When in doubt, ask "Who should this be shown to?" or "Which human
-   input would improve this?"
-
-## Toggle Definitions
-
-### coaching_level
-
-Determines the depth of learning support: `light` (short hooks), `standard` 
-(balanced), `deep` (detailed).
-
-### socratic_max_questions
-
-The number of clarifying questions the model may ask before proceeding.
-If >0, questions should be targeted, minimal, and followed by reasonable assumptions if unanswered.
-
-### verbosity
-'terse' (just a sentence), `concise` (minimum commentary), `normal` (balanced explanation), or other project-defined levels.
-
-### timebox_minutes
-*integer or null* — When set to a positive integer (e.g., `5`), this acts as a **time budget** guiding the model to prioritize delivering the most 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 responses.
-
-### format_enforcement
-`strict` (reject outputs with format drift) or `relaxed` (minor deviations 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.
-
-## 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
-
-## Self-Check (model, before responding)
-- [ ] Task done *and* at least one competence lever included (≤120 words total).
+
+- [ ] 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.
 - [ ] Uncertainties/assumptions surfaced.
 - [ ] No disallowed content.
+
+---
+
+**Status**: Active core guidelines
+**Priority**: Critical
+**Estimated Effort**: Ongoing reference
+**Dependencies**: None (base ruleset)
+**Stakeholders**: All AI interactions
+
 - [ ] Uncertainties/assumptions surfaced.
 - [ ] No disallowed content.

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

@@ -1,13 +1,23 @@
 ---
-globs: **/db/databaseUtil.ts, **/interfaces/absurd-sql.d.ts, **/src/registerSQLWorker.js, **/services/AbsurdSqlDatabaseService.ts
+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
+**Date**: 2025-08-19
+**Status**: 🎯 **ACTIVE** - Database development guidelines
+
 ## Project Overview
-Absurd SQL is a backend implementation for sql.js that enables persistent SQLite databases in the browser by using IndexedDB as a block storage system. This guide provides rules and best practices for developing with this project in Cursor.
+
+Absurd SQL is a backend implementation for sql.js that enables persistent
+SQLite databases in the browser by using IndexedDB as a block storage system.
+This guide provides rules and best practices for developing with this project
+in Cursor.
 
 ## Project Structure
+
 ```
 absurd-sql/
 ├── src/               # Source code
@@ -20,36 +30,45 @@ absurd-sql/
 ## Development Rules
 
 ### 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
+
 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
+
 Recommended database settings:
+
 ```sql
 PRAGMA journal_mode=MEMORY;
 PRAGMA page_size=8192;  -- Optional, but recommended
 ```
 
 ### 6. Development Workflow
+
 1. Install dependencies:
+
    ```bash
    yarn add @jlongster/sql.js absurd-sql
    ```
@@ -60,17 +79,20 @@ PRAGMA page_size=8192;  -- Optional, but recommended
    - `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
@@ -78,18 +100,21 @@ PRAGMA page_size=8192;  -- Optional, but recommended
   - 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
@@ -98,6 +123,7 @@ PRAGMA page_size=8192;  -- Optional, but recommended
 ## Common Patterns
 
 ### Worker Initialization
+
 ```javascript
 // Main thread
 import { initBackend } from 'absurd-sql/dist/indexeddb-main-thread';
@@ -109,6 +135,7 @@ function init() {
 ```
 
 ### Database Setup
+
 ```javascript
 // Worker thread
 import initSqlJs from '@jlongster/sql.js';
@@ -130,6 +157,7 @@ async function setupDatabase() {
 ## Troubleshooting
 
 ### Common Issues
+
 1. SharedArrayBuffer not available
    - Check COOP/COEP headers
    - Verify browser support
@@ -146,7 +174,20 @@ async function setupDatabase() {
    - 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/) 
+- [SQL.js Documentation](https://github.com/sql-js/sql.js/)
+
+---
+
+**Status**: Active database development guidelines
+**Priority**: High
+**Estimated Effort**: Ongoing reference
+**Dependencies**: Absurd SQL, SQL.js, IndexedDB
+**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/)

.cursor/rules/database/legacy_dexie.mdc

@@ -2,4 +2,7 @@
 globs: **/databaseUtil.ts,**/AccountViewView.vue,**/ContactsView.vue,**/DatabaseMigration.vue,**/NewIdentifierView.vue
 alwaysApply: false
 ---
-All references in the codebase to Dexie apply only to migration from IndexedDb to Sqlite and will be deprecated in future versions.
+# What to do with Dexie
+
+All references in the codebase to Dexie apply only to migration from IndexedDb to
+Sqlite and will be deprecated in future versions.

.cursor/rules/development/type_safety_guide.mdc

@@ -1,5 +1,5 @@
 ---
-globs: **/src/**/*,**/scripts/**/*,**/electron/**/*
+description: when dealing with types and Typesript
 alwaysApply: false
 ---
 ```json
@@ -15,8 +15,8 @@ alwaysApply: false
 # TypeScript Type Safety Guidelines
 
 **Author**: Matthew Raymer
-**Date**: 2025-08-16
-**Status**: 🎯 **ACTIVE**
+**Date**: 2025-08-19
+**Status**: 🎯 **ACTIVE** - Type safety enforcement
 
 ## Overview
 
@@ -28,7 +28,8 @@ Practical rules to keep TypeScript strict and predictable. Minimize exceptions.
    - 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`).
+   - Reuse guards from `src/interfaces/**` (e.g., `isDatabaseError`,
+     `isApiError`).
    - Catch with `unknown`; never cast to `any`.
 
 3. **Dynamic property access is type‑safe**
@@ -43,6 +44,7 @@ Practical rules to keep TypeScript strict and predictable. Minimize exceptions.
 ## Type Safety Enforcement
 
 ### 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
@@ -59,10 +61,10 @@ Practical rules to keep TypeScript strict and predictable. Minimize exceptions.
 
 ## 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.
+- **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)
 
@@ -123,3 +125,15 @@ const keys = Object.keys(newSettings).filter(
 - TS Handbook — https://www.typescriptlang.org/docs/
 - TS‑ESLint — https://typescript-eslint.io/rules/
 - Vue 3 + TS — https://vuejs.org/guide/typescript/
+
+---
+
+**Status**: Active type safety guidelines
+**Priority**: High
+**Estimated Effort**: Ongoing reference
+**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/

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

@@ -1,13 +1,13 @@
 ---
-description: 
-globs: 
+description: when dealing with cameras in the application
 alwaysApply: false
 ---
 # Camera Implementation Documentation
 
 ## Overview
 
-This document describes how camera functionality is implemented across the TimeSafari application. The application uses cameras for two main purposes:
+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
@@ -219,4 +219,4 @@ Desktop implementation (currently unimplemented).
 - Multiple browsers
 - iOS and Android devices
 - Desktop platforms
-- Various network conditions 
+- Various network conditions

.cursor/rules/investigation_report_example.mdc

@@ -1,76 +1,117 @@
 # Investigation Report Example
 
+**Author**: Matthew Raymer
+**Date**: 2025-08-19
+**Status**: 🎯 **ACTIVE** - Investigation methodology example
+
 ## Investigation — Registration Dialog Test Flakiness
 
 ## Objective
-Identify root cause of flaky tests related to registration dialogs in contact import scenarios.
+
+Identify root cause of flaky tests related to registration dialogs in contact
+import scenarios.
 
 ## System Map
-- User action → ContactInputForm → ContactsView.addContact() → handleRegistrationPrompt()
+
+- 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
+- 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
+
+- **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
+
+- 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"
+
+- 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
+
+- 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
+- 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?"
 
----
+- 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
 
 ### Evidence-First Approach
+
 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
+
 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
+
 The investigation prevented:
+
 - Unnecessary database schema changes
 - Complex batch registration systems
 - Migration scripts for non-existent problems
 - Architectural changes based on assumptions
-description:
-globs:
-alwaysApply: false
+
 ---
+
+**Status**: Active investigation methodology
+**Priority**: High
+**Estimated Effort**: Ongoing reference
+**Dependencies**: software_development.mdc
+**Stakeholders**: Development team, QA team

.cursor/rules/logging_standards.mdc

@@ -1,11 +1,7 @@
----
-globs: *.vue,*.ts,*.tsx
-alwaysApply: false
----
 # Agent Contract — TimeSafari Logging (Unified, MANDATORY)
 
 **Author**: Matthew Raymer
-**Date**: 2025-08-15
+**Date**: 2025-08-19
 **Status**: 🎯 **ACTIVE** - Mandatory logging standards
 
 ## Overview
@@ -220,6 +216,7 @@ logger.debug('[FeedFilters] Filter toggled', this.hasVisibleDid);
 ---
 
 **Status**: Active and enforced
-**Last Updated**: 2025-08-15 08:11:46Z
-**Version**: 1.0
-**Maintainer**: Matthew Raymer
+**Priority**: Critical
+**Estimated Effort**: Ongoing reference
+**Dependencies**: TimeSafari logger utility
+**Stakeholders**: Development team, Code review team

.cursor/rules/research_diagnostic.mdc

@@ -31,6 +31,7 @@ steps—**not** code changes.
 ## Enhanced with Software Development Ruleset
 
 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
@@ -117,6 +118,7 @@ Copy/paste and fill:
 ## Code Path Tracing (Required for Software Investigations)
 
 Before proposing solutions, trace the actual execution path:
+
 - [ ] **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
@@ -136,11 +138,13 @@ Before proposing solutions, trace the actual execution path:
 ## Integration with Other Rulesets
 
 ### With software_development.mdc
+
 - **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
 

.cursor/rules/software_development.mdc

@@ -1,66 +1,144 @@
 
 # Software Development Ruleset
 
+**Author**: Matthew Raymer
+**Date**: 2025-08-19
+**Status**: 🎯 **ACTIVE** - Core development guidelines
+
 ## Purpose
-Specialized guidelines for software development tasks including code review, debugging, architecture decisions, and testing.
+
+Specialized guidelines for software development tasks including code review,
+debugging, architecture decisions, and testing.
 
 ## Core Principles
 
 ### 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
+
+- **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
+
+- **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
+- **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
+  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
 
 ### 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
 
 ### 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
@@ -68,6 +146,7 @@ Specialized guidelines for software development tasks including code review, deb
 ## Usage Guidelines
 
 ### When to Use This Ruleset
+
 - Code reviews and architectural decisions
 - Bug investigation and debugging
 - Performance optimization
@@ -75,11 +154,13 @@ Specialized guidelines for software development tasks including code review, deb
 - 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

.cursor/rules/time.mdc

@@ -0,0 +1,329 @@
+---
+alwaysApply: true
+---
+# 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?
+
+## 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
+
+**CRITICAL**: The LLM must actively query the system for current time rather
+than assuming or inventing times.
+
+### How to Check Current Time
+
+#### 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**
+
+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**
+
+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
+
+#### 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 Best Practices
+
+#### 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
+
+#### 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**.
+
+**Technical Rule of Thumb**: **Store in UTC, display in local time, always
+include timezone context.**
+
+---
+
+**Status**: Active
+**Version**: 1.0
+**Maintainer**: Matthew Raymer
+**Next Review**: 2025-09-17

.cursor/rules/workflow/version_control.mdc

@@ -1,133 +1,143 @@
 ---
-alwaysApply: true
+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
 
-* **MUST NOT** run `git add`, `git commit`, or any write action.
-* **MUST** leave staging/committing to the developer.
+- **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
 
-* **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.
+- **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
 
-* **ALWAYS** present, before any real commit:
-
-  * file list + brief per-file notes,
-  * a **draft commit message** (copy-paste ready),
-  * nothing auto-applied.
+- **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
+- **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])
+- [ ] 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
+- [ ] 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
+- **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
+- **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)
 
-# Commit Message Format (Normative)
-
-## A. Subject Line (required)
+### 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
+- **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`
+- `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)
+### 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**.
+- 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)
+- [ ] Problem/symptom being addressed
+- [ ] High-level approach or rationale
+- [ ] Risks, tradeoffs, or follow-ups (if any)
 
-## C. Footer (optional)
+### C. Footer (optional)
 
-* Issue refs: `Closes #123`, `Refs #456`
-* Breaking change (alternative to `!`):
+- 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)
-
----
+- 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
+- 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
+- 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.
+**Guiding Principle:** Let code and inline docs speak. Use commits to
+highlight what isn't obvious.
 
----
+## Copy-Paste Templates
 
-# Copy-Paste Templates
-
-## Minimal (no body)
+### Minimal (no body)
 
 ```text
 <type>(<scope>): <summary>
 ```
 
-## Standard (with body & footer)
+### Standard (with body & footer)
 
 ```text
 <type>(<scope>)<!>: <summary>
@@ -141,13 +151,185 @@ 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
+
 ---
 
-# Assistant Output Checklist (before showing the draft)
+**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
+
+## 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
+
+- **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
+
+- **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
 
-* [ ] 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

BUILDING.md

@@ -1017,47 +1017,27 @@ If you need to build manually or want to understand the individual steps:
    export GEM_PATH=$shortened_path
    ```
 
-1. Build the web assets & update ios:
-
-   ```bash
-   rm -rf dist
-   npm run build:web
-   npm run build:capacitor
-   npx cap sync ios
-   ```
-
-  - If that fails with "Could not find..." then look at the "gem_path" instructions above.
-
-3. Copy the assets:
-
-   ```bash
-   # It makes no sense why capacitor-assets will not run without these but it actually changes the contents.
-   mkdir -p ios/App/App/Assets.xcassets/AppIcon.appiconset
-   echo '{"images":[]}' > ios/App/App/Assets.xcassets/AppIcon.appiconset/Contents.json
-   mkdir -p ios/App/App/Assets.xcassets/Splash.imageset
-   echo '{"images":[]}' > ios/App/App/Assets.xcassets/Splash.imageset/Contents.json
-   npx capacitor-assets generate --ios
-   ```
-
-4. Bump the version to match Android & package.json:
+1. Bump the version in package.json, then here.
 
    ```
-   cd ios/App && xcrun agvtool new-version 39 && perl -p -i -e "s/MARKETING_VERSION = .*;/MARKETING_VERSION = 1.0.6;/g" App.xcodeproj/project.pbxproj && cd -
+   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
    ```
 
-5. Open the project in Xcode:
+2. Build.
 
-   ```bash
-   npx cap open ios
-   ```
+  Here's prod. Also available: test, dev
 
-6. Use Xcode to build and run on simulator or device.
+  ```bash
+  npm run build:ios:prod
+  ```
+
+3.1. Use Xcode to build and run on simulator or device.
 
   * Select Product -> Destination with some Simulator version. Then click the run arrow.
 
-7. Release
+3.2. Use Xcode to release.
 
   * Someday: Under "General" we want to rename a bunch of things to "Time Safari"
   * Choose Product -> Destination -> Any iOS Device
@@ -1125,35 +1105,28 @@ The recommended way to build for Android is using the automated build script:
 
 #### Manual Build Process
 
-1. Build the web assets:
+1. Bump the version in package.json, then here: android/app/build.gradle
 
-   ```bash
-   rm -rf dist
-   npm run build:web
-   npm run build:capacitor
-   ```
+  ```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
+  ```
 
-2. Update Android project with latest build:
+2. Build.
 
-   ```bash
-   npx cap sync android
-   ```
+  Here's prod. Also available: test, dev
 
-3. Copy the assets
+  ```bash
+  npm run build:android:prod
+  ```
 
-   ```bash
-   npx capacitor-assets generate --android
-   ```
-
-4. Bump version to match iOS & package.json: android/app/build.gradle
-
-5. Open the project in Android Studio:
+3. Open the project in Android Studio:
 
    ```bash
    npx cap open android
    ```
 
-6. Use Android Studio to build and run on emulator or device.
+4. Use Android Studio to build and run on emulator or device.
 
 ## Android Build from the console
 
@@ -1186,9 +1159,9 @@ cd -
 
 At play.google.com/console:
 
-- Go to the Testing Track (eg. Closed).
+- Go to Production or the Closed Testing and either Create Track or Manage Track.
 - Click "Create new release".
-- Upload the `aab` file.
+- Upload the `aab` file from: app/build/outputs/bundle/release/app-release.aab
 - Hit "Next".
 - Save, go to "Publishing Overview" as prompted, and click "Send changes for review".
 

CHANGELOG.md

@@ -5,12 +5,10 @@ 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.0.3] - 2025.07.12
-### Changed
-- Photo is pinned to profile mode
+## [1.0.7] - 2025.08.18
 ### Fixed
-- Deep link URLs (and other prod settings)
-- Error in BVC begin view
+- Deep link for onboard-meeting-members
+
 
 ## [1.0.6] - 2025.08.09
 ### Fixed

README.md

@@ -170,6 +170,33 @@ npm run assets:clean
 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
+
+# Validate your development environment
+npm run check:dependencies
+
+# Check prerequisites for testing
+npm run test:prerequisites
+```
+
+**Common Issues & Solutions**:
+
+- **"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
+
+**Required Versions**:
+- Node.js: 18+ (LTS recommended)
+- npm: 8+ (comes with Node.js)
+- Platform-specific tools: Android Studio, Xcode (for mobile builds)
+
 ### Platform Support
 
 - **Android**: Adaptive icons with foreground/background, monochrome support

android/app/build.gradle

@@ -31,8 +31,8 @@ android {
         applicationId "app.timesafari.app"
         minSdkVersion rootProject.ext.minSdkVersion
         targetSdkVersion rootProject.ext.targetSdkVersion
-        versionCode 39
-        versionName "1.0.6"
+        versionCode 40
+        versionName "1.0.7"
         testInstrumentationRunner "androidx.test.runner.AndroidJUnitRunner"
         aaptOptions {
              // Files and dirs to omit from the packaged assets dir, modified to accommodate modern web apps.

ios/App/App.xcodeproj/project.pbxproj

@@ -403,7 +403,7 @@
 			buildSettings = {
 				ASSETCATALOG_COMPILER_APPICON_NAME = AppIcon;
 				CODE_SIGN_STYLE = Automatic;
-				CURRENT_PROJECT_VERSION = 39;
+				CURRENT_PROJECT_VERSION = 40;
 				DEVELOPMENT_TEAM = GM3FS5JQPH;
 				ENABLE_APP_SANDBOX = NO;
 				ENABLE_USER_SCRIPT_SANDBOXING = NO;
@@ -413,7 +413,7 @@
 					"$(inherited)",
 					"@executable_path/Frameworks",
 				);
-				MARKETING_VERSION = 1.0.6;
+				MARKETING_VERSION = 1.0.7;
 				OTHER_SWIFT_FLAGS = "$(inherited) \"-D\" \"COCOAPODS\" \"-DDEBUG\"";
 				PRODUCT_BUNDLE_IDENTIFIER = app.timesafari;
 				PRODUCT_NAME = "$(TARGET_NAME)";
@@ -430,7 +430,7 @@
 			buildSettings = {
 				ASSETCATALOG_COMPILER_APPICON_NAME = AppIcon;
 				CODE_SIGN_STYLE = Automatic;
-				CURRENT_PROJECT_VERSION = 39;
+				CURRENT_PROJECT_VERSION = 40;
 				DEVELOPMENT_TEAM = GM3FS5JQPH;
 				ENABLE_APP_SANDBOX = NO;
 				ENABLE_USER_SCRIPT_SANDBOXING = NO;
@@ -440,7 +440,7 @@
 					"$(inherited)",
 					"@executable_path/Frameworks",
 				);
-				MARKETING_VERSION = 1.0.6;
+				MARKETING_VERSION = 1.0.7;
 				PRODUCT_BUNDLE_IDENTIFIER = app.timesafari;
 				PRODUCT_NAME = "$(TARGET_NAME)";
 				SWIFT_ACTIVE_COMPILATION_CONDITIONS = "";

package-lock.json

@@ -1,12 +1,12 @@
 {
   "name": "timesafari",
-  "version": "1.0.7-beta",
+  "version": "1.0.8-beta",
   "lockfileVersion": 3,
   "requires": true,
   "packages": {
     "": {
       "name": "timesafari",
-      "version": "1.0.7-beta",
+      "version": "1.0.8-beta",
       "dependencies": {
         "@capacitor-community/electron": "^5.0.1",
         "@capacitor-community/sqlite": "6.0.2",

package.json

@@ -1,6 +1,6 @@
 {
   "name": "timesafari",
-  "version": "1.0.7-beta",
+  "version": "1.0.8-beta",
   "description": "Time Safari Application",
   "author": {
     "name": "Time Safari Team"
@@ -12,6 +12,8 @@
     "type-check": "tsc --noEmit",
     "prebuild": "eslint --ext .js,.ts,.vue --ignore-path .gitignore src && node sw_combine.js && node scripts/copy-wasm.js",
     "test:prerequisites": "node scripts/check-prerequisites.js",
+    "check:dependencies": "./scripts/check-dependencies.sh",
+    "test:all": "npm run lint && tsc && npm run test:web && npm run test:mobile && ./scripts/test-safety-check.sh && echo '\n\n\nGotta add the performance tests'",
     "test:web": "npx playwright test -c playwright.config-local.ts --trace on",
     "test:mobile": "./scripts/test-mobile.sh",
     "test:android": "node scripts/test-android.js",
@@ -27,8 +29,8 @@
     "build:capacitor": "VITE_GIT_HASH=`git log -1 --pretty=format:%h` vite build --mode capacitor --config vite.config.capacitor.mts",
     "build:capacitor:sync": "npm run build:capacitor && npx cap sync",
     "build:native": "vite build && npx cap sync && npx capacitor-assets generate",
-    "assets:config": "tsx scripts/assets-config.ts",
-    "assets:validate": "tsx scripts/assets-validator.ts",
+    "assets:config": "npx tsx scripts/assets-config.ts",
+    "assets:validate": "npx tsx scripts/assets-validator.ts",
     "assets:clean": "rimraf android/app/src/main/res/mipmap-* ios/App/App/Assets.xcassets/**/AppIcon*.png ios/App/App/Assets.xcassets/**/Splash*.png || true",
     "build:ios": "./scripts/build-ios.sh",
     "build:ios:dev": "./scripts/build-ios.sh --dev",
@@ -96,7 +98,7 @@
     "build:electron:dmg:dev": "./scripts/build-electron.sh --dev --dmg",
     "build:electron:dmg:test": "./scripts/build-electron.sh --test --dmg",
     "build:electron:dmg:prod": "./scripts/build-electron.sh --prod --dmg",
-    "clean:android": "adb uninstall app.timesafari.app || true",
+    "clean:android": "./scripts/clean-android.sh",
     "clean:ios": "rm -rf ios/App/build ios/App/Pods ios/App/output ios/App/App/public ios/DerivedData ios/capacitor-cordova-ios-plugins ios/App/App/capacitor.config.json ios/App/App/config.xml || true",
     "clean:electron": "./scripts/build-electron.sh --clean",
     "clean:all": "npm run clean:ios && npm run clean:android && npm run clean:electron",

scripts/build-android.sh

@@ -49,6 +49,31 @@ set -e
 # Source common utilities
 source "$(dirname "$0")/common.sh"
 
+# Function to validate critical dependencies
+validate_dependencies() {
+    log_info "Validating critical dependencies..."
+    
+    # Check if node_modules exists
+    if [ ! -d "node_modules" ]; then
+        log_error "node_modules directory not found. Please run 'npm install' first."
+        exit 1
+    fi
+    
+    # Check if tsx is available
+    if [ ! -f "node_modules/.bin/tsx" ]; then
+        log_error "tsx dependency not found. Please run 'npm install' first."
+        exit 1
+    fi
+    
+    # Check if capacitor-assets is available
+    if [ ! -f "node_modules/.bin/capacitor-assets" ]; then
+        log_error "capacitor-assets dependency not found. Please run 'npm install' first."
+        exit 1
+    fi
+    
+    log_success "All critical dependencies validated successfully"
+}
+
 # Default values
 BUILD_MODE="development"
 BUILD_TYPE="debug"
@@ -179,6 +204,11 @@ parse_android_args "$@"
 
 # Print build header
 print_header "TimeSafari Android Build Process"
+
+# Validate dependencies before proceeding
+validate_dependencies
+
+# Log build start
 log_info "Starting Android build process at $(date)"
 log_info "Build mode: $BUILD_MODE"
 log_info "Build type: $BUILD_TYPE"
@@ -257,6 +287,7 @@ fi
 # Step 1: Validate asset configuration
 safe_execute "Validating asset configuration" "npm run assets:validate" || {
     log_warn "Asset validation found issues, but continuing with build..."
+    log_info "If you encounter build failures, please run 'npm install' first to ensure all dependencies are available."
 }
 
 # Step 2: Clean Android app
@@ -337,6 +368,9 @@ if [ "$OPEN_STUDIO" = true ]; then
     log_info "Android Studio: opened"
 fi
 
+# Reminder about dependency management
+log_info "💡 Tip: If you encounter dependency issues, run 'npm install' to ensure all packages are up to date."
+
 print_footer "Android Build"
 
 # Exit with success

scripts/build-ios.sh

@@ -173,20 +173,20 @@ check_ios_resources() {
     
     # Check for required assets
     if [ ! -f "assets/icon.png" ]; then
-        log_warning "App icon not found at assets/icon.png"
+        log_warn "App icon not found at assets/icon.png"
     fi
     
     if [ ! -f "assets/splash.png" ]; then
-        log_warning "Splash screen not found at assets/splash.png"
+        log_warn "Splash screen not found at assets/splash.png"
     fi
     
     # Check for iOS-specific files
     if [ ! -f "ios/App/App/Info.plist" ]; then
-        log_warning "Info.plist not found"
+        log_warn "Info.plist not found"
     fi
     
     if [ ! -f "ios/App/App/AppDelegate.swift" ]; then
-        log_warning "AppDelegate.swift not found"
+        log_warn "AppDelegate.swift not found"
     fi
     
     log_success "iOS resource check completed"

scripts/check-dependencies.sh

@@ -0,0 +1,110 @@
+#!/bin/bash
+# check-dependencies.sh
+# Author: Matthew Raymer
+# Date: 2025-08-19
+# Description: Dependency validation script for TimeSafari development environment
+# This script checks for critical dependencies required for building the application.
+
+# Exit on any error
+set -e
+
+# Source common utilities
+source "$(dirname "$0")/common.sh"
+
+print_header "TimeSafari Dependency Validation"
+
+log_info "Checking development environment dependencies..."
+
+# Check Node.js version
+if command -v node &> /dev/null; then
+    NODE_VERSION=$(node --version)
+    log_info "Node.js version: $NODE_VERSION"
+    
+    # Extract major version number
+    MAJOR_VERSION=$(echo $NODE_VERSION | sed 's/v\([0-9]*\)\..*/\1/')
+    if [ "$MAJOR_VERSION" -lt 18 ]; then
+        log_error "Node.js version $NODE_VERSION is too old. Please upgrade to Node.js 18 or later."
+        exit 1
+    fi
+else
+    log_error "Node.js is not installed. Please install Node.js 18 or later."
+    exit 1
+fi
+
+# Check npm version
+if command -v npm &> /dev/null; then
+    NPM_VERSION=$(npm --version)
+    log_info "npm version: $NPM_VERSION"
+else
+    log_error "npm is not installed. Please install npm."
+    exit 1
+fi
+
+# Check if node_modules exists
+if [ ! -d "node_modules" ]; then
+    log_error "node_modules directory not found."
+    log_info "Please run: npm install"
+    exit 1
+fi
+
+# Check critical dependencies
+log_info "Validating critical packages..."
+
+CRITICAL_DEPS=("tsx" "capacitor-assets" "vite")
+
+for dep in "${CRITICAL_DEPS[@]}"; do
+    if [ -f "node_modules/.bin/$dep" ]; then
+        log_success "✓ $dep found"
+    else
+        log_error "✗ $dep not found in node_modules/.bin"
+        log_info "This usually means the package wasn't installed properly."
+        log_info "Try running: npm install"
+        exit 1
+    fi
+done
+
+# Check TypeScript via npx
+if npx tsc --version &> /dev/null; then
+    TSC_VERSION=$(npx tsc --version)
+    log_success "✓ TypeScript found: $TSC_VERSION"
+else
+    log_error "✗ TypeScript not accessible via npx"
+    log_info "Try running: npm install"
+    exit 1
+fi
+
+# Check Capacitor CLI
+if command -v npx &> /dev/null; then
+    if npx cap --version &> /dev/null; then
+        CAP_VERSION=$(npx cap --version)
+        log_success "✓ Capacitor CLI version: $CAP_VERSION"
+    else
+        log_error "✗ Capacitor CLI not accessible via npx"
+        log_info "Try running: npm install @capacitor/cli"
+        exit 1
+    fi
+else
+    log_error "npx is not available. Please ensure npm is properly installed."
+    exit 1
+fi
+
+# Check Android development tools
+if command -v adb &> /dev/null; then
+    log_success "✓ Android Debug Bridge (adb) found"
+else
+    log_warn "⚠ Android Debug Bridge (adb) not found"
+    log_info "This is only needed for Android development and testing."
+fi
+
+if command -v gradle &> /dev/null; then
+    GRADLE_VERSION=$(gradle --version | head -n 1)
+    log_success "✓ Gradle found: $GRADLE_VERSION"
+else
+    log_warn "⚠ Gradle not found in PATH"
+    log_info "This is only needed if building outside of Android Studio."
+fi
+
+log_success "Dependency validation completed successfully!"
+log_info "Your development environment is ready for TimeSafari development."
+
+print_footer "Dependency Validation"

scripts/clean-android.sh

@@ -0,0 +1,62 @@
+#!/bin/bash
+# clean-android.sh
+# Author: Matthew Raymer
+# Date: 2025-08-19
+# Description: Clean Android app with timeout protection to prevent hanging
+# This script safely uninstalls the TimeSafari app from connected Android devices
+# with a 30-second timeout to prevent indefinite hanging.
+
+# Exit on any error
+set -e
+
+# Source common utilities
+source "$(dirname "$0")/common.sh"
+
+# Function to implement timeout for systems without timeout command
+timeout_command() {
+    local timeout_seconds="$1"
+    shift
+    
+    # Check if timeout command exists
+    if command -v timeout &> /dev/null; then
+        timeout "$timeout_seconds" "$@"
+    else
+        # Fallback for systems without timeout (like macOS)
+        # Use perl to implement timeout
+        perl -e '
+            eval {
+                local $SIG{ALRM} = sub { die "timeout" };
+                alarm shift;
+                system @ARGV;
+                alarm 0;
+            };
+            if ($@) { exit 1; }
+        ' "$timeout_seconds" "$@"
+    fi
+}
+
+log_info "Starting Android cleanup process..."
+
+# Check if adb is available
+if ! command -v adb &> /dev/null; then
+    log_error "adb command not found. Please install Android SDK Platform Tools."
+    exit 1
+fi
+
+# Check for connected devices
+log_info "Checking for connected Android devices..."
+if adb devices | grep -q 'device$'; then
+    log_info "Android device(s) found. Attempting to uninstall app..."
+    
+    # Try to uninstall with timeout
+    if timeout_command 30 adb uninstall app.timesafari.app; then
+        log_success "Successfully uninstalled TimeSafari app"
+    else
+        log_warn "Uninstall failed or timed out after 30 seconds"
+        log_info "This is normal if the app wasn't installed or device is unresponsive"
+    fi
+else
+    log_info "No Android devices connected. Skipping uninstall."
+fi
+
+log_success "Android cleanup process completed"

src/interfaces/deepLinks.ts

@@ -28,7 +28,7 @@
 import { z } from "zod";
 
 // Parameter validation schemas for each route type
-export const deepLinkSchemas = {
+export const deepLinkPathSchemas = {
   claim: z.object({
     id: z.string(),
   }),
@@ -60,7 +60,7 @@ export const deepLinkSchemas = {
     jwt: z.string().optional(),
   }),
   "onboard-meeting-members": z.object({
-    id: z.string(),
+    groupId: z.string(),
   }),
   project: z.object({
     id: z.string(),
@@ -70,6 +70,17 @@ export const deepLinkSchemas = {
   }),
 };
 
+export const deepLinkQuerySchemas = {
+  "onboard-meeting-members": z.object({
+    password: z.string(),
+  }),
+};
+
+// Add a union type of all valid route paths
+export const VALID_DEEP_LINK_ROUTES = Object.keys(
+  deepLinkPathSchemas,
+) as readonly (keyof typeof deepLinkPathSchemas)[];
+
 // Create a type from the array
 export type DeepLinkRoute = (typeof VALID_DEEP_LINK_ROUTES)[number];
 
@@ -80,14 +91,13 @@ export const baseUrlSchema = z.object({
   queryParams: z.record(z.string()).optional(),
 });
 
-// Add a union type of all valid route paths
-export const VALID_DEEP_LINK_ROUTES = Object.keys(
-  deepLinkSchemas,
-) as readonly (keyof typeof deepLinkSchemas)[];
+// export type DeepLinkPathParams = {
+//   [K in keyof typeof deepLinkPathSchemas]: z.infer<(typeof deepLinkPathSchemas)[K]>;
+// };
 
-export type DeepLinkParams = {
-  [K in keyof typeof deepLinkSchemas]: z.infer<(typeof deepLinkSchemas)[K]>;
-};
+// export type DeepLinkQueryParams = {
+//   [K in keyof typeof deepLinkQuerySchemas]: z.infer<(typeof deepLinkQuerySchemas)[K]>;
+// };
 
 export interface DeepLinkError extends Error {
   code: string;

src/services/ProfileService.ts

@@ -10,7 +10,6 @@ import { getHeaders, errorStringForLog } from "@/libs/endorserServer";
 import { handleApiError } from "./api";
 import { logger } from "@/utils/logger";
 import { ACCOUNT_VIEW_CONSTANTS } from "@/constants/accountView";
-import { AxiosErrorResponse } from "@/interfaces/common";
 
 /**
  * Profile data interface
@@ -125,15 +124,18 @@ export class ProfileService {
   async deleteProfile(activeDid: string): Promise<boolean> {
     try {
       const headers = await getHeaders(activeDid);
-      const response = await this.axios.delete(
-        `${this.partnerApiServer}/api/partner/userProfile`,
-        { headers },
-      );
+      const url = `${this.partnerApiServer}/api/partner/userProfile`;
+      const response = await this.axios.delete(url, { headers });
 
       if (response.status === 204 || response.status === 200) {
         logger.info("Profile deleted successfully");
         return true;
       } else {
+        logger.error("Unexpected response status when deleting profile:", {
+          status: response.status,
+          statusText: response.statusText,
+          data: response.data,
+        });
         throw new Error(
           `Profile not deleted - HTTP ${response.status}: ${response.statusText}`,
         );
@@ -157,9 +159,11 @@ export class ProfileService {
           return true; // Consider this a success if profile doesn't exist
         } else if (response.status === 400) {
           logger.error("Bad request when deleting profile:", response.data);
-          throw new Error(
-            `Profile deletion failed: ${response.data?.error?.message || "Bad request"}`,
-          );
+          const errorMessage =
+            typeof response.data === "string"
+              ? response.data
+              : response.data?.message || "Bad request";
+          throw new Error(`Profile deletion failed: ${errorMessage}`);
         } else if (response.status === 401) {
           logger.error("Unauthorized to delete profile");
           throw new Error("You are not authorized to delete this profile");
@@ -240,10 +244,33 @@ export class ProfileService {
   /**
    * Type guard for API errors with proper typing
    */
-  private isApiError(error: unknown): error is AxiosErrorResponse {
+  private isApiError(error: unknown): error is {
+    response?: {
+      status?: number;
+      statusText?: string;
+      data?: { message?: string } | string;
+    };
+  } {
     return typeof error === "object" && error !== null && "response" in error;
   }
 
+  /**
+   * Extract URL from AxiosError without type casting
+   */
+  private getErrorUrl(error: unknown): string | undefined {
+    if (this.isAxiosError(error)) {
+      return error.config?.url;
+    }
+    return undefined;
+  }
+
+  /**
+   * Type guard for AxiosError
+   */
+  private isAxiosError(error: unknown): error is AxiosError {
+    return error instanceof AxiosError;
+  }
+
   /**
    * Extract error URL safely from error object
    */

src/services/deepLinks.ts

@@ -47,10 +47,11 @@ import { Router } from "vue-router";
 import { z } from "zod";
 
 import {
-  deepLinkSchemas,
+  deepLinkPathSchemas,
   baseUrlSchema,
   routeSchema,
   DeepLinkRoute,
+  deepLinkQuerySchemas,
 } from "../interfaces/deepLinks";
 import type { DeepLinkError } from "../interfaces/deepLinks";
 import { logger } from "../utils/logger";
@@ -74,7 +75,7 @@ function getFirstKeyFromZodObject(
  * because "router.replace" expects the right parameter name for the route.
  */
 export const ROUTE_MAP: Record<string, { name: string; paramKey?: string }> =
-  Object.entries(deepLinkSchemas).reduce(
+  Object.entries(deepLinkPathSchemas).reduce(
     (acc, [routeName, schema]) => {
       // eslint-disable-next-line @typescript-eslint/no-explicit-any
       const paramKey = getFirstKeyFromZodObject(schema as z.ZodObject<any>);
@@ -198,15 +199,24 @@ export class DeepLinkHandler {
     }
 
     // Continue with parameter validation as before...
-    const schema = deepLinkSchemas[path as keyof typeof deepLinkSchemas];
+    const pathSchema =
+      deepLinkPathSchemas[path as keyof typeof deepLinkPathSchemas];
+    const querySchema =
+      deepLinkQuerySchemas[path as keyof typeof deepLinkQuerySchemas];
 
-    let validatedParams;
+    let validatedPathParams: Record<string, string> = {};
+    let validatedQueryParams: Record<string, string> = {};
     try {
-      validatedParams = await schema.parseAsync(params);
+      if (pathSchema) {
+        validatedPathParams = await pathSchema.parseAsync(params);
+      }
+      if (querySchema) {
+        validatedQueryParams = await querySchema.parseAsync(query);
+      }
     } catch (error) {
       // For parameter validation errors, provide specific error feedback
       logger.error(
-        `[DeepLink] Invalid parameters for route name ${routeName} for path: ${path}: ${JSON.stringify(error)} ... with params: ${JSON.stringify(params)} ... and query: ${JSON.stringify(query)}`,
+        `[DeepLink] Invalid parameters for route name ${routeName} for path: ${path} ... with error: ${JSON.stringify(error)} ... with params: ${JSON.stringify(params)} ... and query: ${JSON.stringify(query)}`,
       );
       await this.router.replace({
         name: "deep-link-error",
@@ -226,20 +236,22 @@ export class DeepLinkHandler {
     try {
       await this.router.replace({
         name: routeName,
-        params: validatedParams,
+        params: validatedPathParams,
+        query: validatedQueryParams,
       });
     } catch (error) {
       logger.error(
-        `[DeepLink] Error routing to route name ${routeName} for path: ${path}: ${JSON.stringify(error)} ... with validated params: ${JSON.stringify(validatedParams)}`,
+        `[DeepLink] Error routing to route name ${routeName} for path: ${path}: ${JSON.stringify(error)} ... with validated params: ${JSON.stringify(validatedPathParams)} ... and query: ${JSON.stringify(validatedQueryParams)}`,
       );
       // For parameter validation errors, provide specific error feedback
       await this.router.replace({
         name: "deep-link-error",
-        params: validatedParams,
+        params: validatedPathParams,
         query: {
           originalPath: path,
           errorCode: "ROUTING_ERROR",
           errorMessage: `Error routing to ${routeName}: ${JSON.stringify(error)}`,
+          ...validatedQueryParams,
         },
       });
     }

src/views/AccountViewView.vue

@@ -182,7 +182,6 @@
           @change="onLocationCheckboxChange"
         />
         <label for="includeUserProfileLocation">Include Location</label>
-
       </div>
       <div v-if="includeUserProfileLocation" class="mb-4 aspect-video">
         <p class="text-sm mb-2 text-slate-500">

src/views/DeepLinkErrorView.vue

@@ -47,7 +47,7 @@ import { computed, onMounted } from "vue";
 import { useRoute, useRouter } from "vue-router";
 import {
   VALID_DEEP_LINK_ROUTES,
-  deepLinkSchemas,
+  deepLinkPathSchemas,
 } from "../interfaces/deepLinks";
 import { logConsoleAndDb } from "../db/databaseUtil";
 import { logger } from "../utils/logger";
@@ -56,7 +56,7 @@ const route = useRoute();
 const router = useRouter();
 // an object with the route as the key and the first param name as the value
 const deepLinkSchemaKeys = Object.fromEntries(
-  Object.entries(deepLinkSchemas).map(([route, schema]) => {
+  Object.entries(deepLinkPathSchemas).map(([route, schema]) => {
     const param = Object.keys(schema.shape)[0];
     return [route, param];
   }),

src/views/OnboardMeetingMembersView.vue

@@ -113,7 +113,7 @@ export default class OnboardMeetingMembersView extends Vue {
     try {
       // Identity creation should be handled by router guard, but keep as fallback for meeting setup
       if (!this.activeDid) {
-        logger.info(
+        this.$logAndConsole(
           "[OnboardMeetingMembersView] No active DID found, creating identity as fallback for meeting setup",
         );
         this.activeDid = await generateSaveAndActivateIdentity();