diff --git a/BUILDING.md b/BUILDING.md
index e5abf069..17c367d6 100644
--- a/BUILDING.md
+++ b/BUILDING.md
@@ -13,7 +13,7 @@ npm run build:web:serve -- --test    # Start with test endorser server
 npm run build:web:dev                # Start development server with hot reload with local endorser server
 npm run build:web:prod               # Production build
 
-# 📱 Mobile Development  
+# 📱 Mobile Development
 npm run build:ios              # iOS build (opens Xcode)
 npm run build:android          # Android build (opens Android Studio)
 
@@ -31,6 +31,7 @@ npm run clean:all              # Clean all platforms
 ### Development Workflow
 
 #### 1. First-Time Setup
+
 ```bash
 # Install dependencies
 npm install
@@ -40,6 +41,7 @@ npm run test:web               # Run web tests to verify setup
 ```
 
 #### 2. Daily Development
+
 ```bash
 # Start web development server
 npm run build:web:dev          # Opens http://localhost:8080
@@ -48,11 +50,12 @@ npm run build:web:dev          # Opens http://localhost:8080
 npm run build:ios              # Opens Xcode with iOS project
 npm run build:android          # Opens Android Studio with Android project
 
-# For desktop development  
+# For desktop development
 npm run build:electron:dev     # Runs Electron app directly
 ```
 
 #### 3. Testing Your Changes
+
 ```bash
 # Test web functionality
 npm run test:web               # Run web tests
@@ -66,6 +69,7 @@ npm run build:android:test:run # Build and run on Android emulator
 ```
 
 #### 4. Production Builds
+
 ```bash
 # Build for production
 npm run build:web:prod         # Web production build
@@ -77,6 +81,7 @@ npm run build:electron:prod    # Electron production build
 ### Environment Configuration
 
 #### Quick Environment Setup
+
 ```bash
 # Copy environment template (if available)
 cp .env.example .env.development
@@ -89,6 +94,7 @@ cp .env.example .env.development
 ```
 
 #### Platform-Specific Development
+
 - **Web**: Uses `localhost:3000` for APIs by default
 - **iOS Simulator**: Uses `localhost:3000` for APIs
 - **Android Emulator**: Uses `10.0.2.2:3000` for APIs
@@ -97,6 +103,7 @@ cp .env.example .env.development
 ### Troubleshooting Quick Fixes
 
 #### Common Issues
+
 ```bash
 # Clean and rebuild
 npm run clean:all
@@ -114,6 +121,7 @@ npm run test:web               # Verifies web setup
 ```
 
 #### Platform-Specific Issues
+
 - **iOS**: Ensure Xcode and Command Line Tools are installed
 - **Android**: Ensure Android Studio and SDK are configured
 - **Electron**: Ensure platform-specific build tools are installed
@@ -222,6 +230,7 @@ All web build commands use the `./scripts/build-web.sh` script, which provides:
 ```
 
 **Script Flow:**
+
 1. **Environment Validation**: Check prerequisites (Node.js, npm, etc.)
 2. **Environment Setup**: Load `.env` files, set NODE_ENV
 3. **Clean Dist**: Remove previous build artifacts
@@ -230,8 +239,9 @@ All web build commands use the `./scripts/build-web.sh` script, which provides:
 6. **Optional Serve**: Start local HTTP server if requested
 
 **Exit Codes:**
+
 - `1` - Web cleanup failed
-- `2` - Environment setup failed  
+- `2` - Environment setup failed
 - `3` - Vite build failed
 - `4` - Docker build failed
 - `5` - Serve command failed
@@ -239,19 +249,25 @@ All web build commands use the `./scripts/build-web.sh` script, which provides:
 
 ### Compile and minify for test & production
 
-* If there are DB changes: before updating the test server, open browser(s) with current version to test DB migrations.
+- If there are DB changes: before updating the test server, open browser(s) with
+current version to test DB migrations.
 
-* Update the ClickUp tasks & CHANGELOG.md & the version in package.json, run `npm install`.
+- Update the ClickUp tasks & CHANGELOG.md & the version in package.json, run
+`npm install`.
 
-* Run a build to make sure package-lock version is updated, linting works, etc: `npm install && npm run build:web`
+- Run a build to make sure package-lock version is updated, linting works, etc:
+`npm install && npm run build:web`
 
-* Commit everything (since the commit hash is used the app).
+- Commit everything (since the commit hash is used the app).
 
-* Put the commit hash in the changelog (which will help you remember to bump the version in the step later).
+- Put the commit hash in the changelog (which will help you remember to bump the
+  version in the step later).
 
-* Tag with the new version, [online](https://gitea.anomalistdesign.com/trent_larson/crowd-funder-for-time-pwa/releases) or `git tag 1.0.2 && git push origin 1.0.2`.
+- Tag with the new version, 
+[online](https://gitea.anomalistdesign.com/trent_larson/crowd-funder-for-time-pwa/releases) or 
+`git tag 1.0.2 && git push origin 1.0.2`.
 
-* For test, build the app (because test server is not yet set up to build):
+- For test, build the app (because test server is not yet set up to build):
 
 ```bash
 TIME_SAFARI_APP_TITLE="TimeSafari_Test" \
@@ -274,25 +290,28 @@ rsync -azvu -e "ssh -i ~/.ssh/..." dist ubuntutest@test.timesafari.app:time-safa
 
 (Note: The test BVC_MEETUPS_PROJECT_CLAIM_ID does not resolve as a URL because it's only in the test DB and the prod redirect won't redirect there.)
 
-* For prod, get on the server and run the correct build:
+- For prod, get on the server and run the correct build:
 
 ... and log onto the server:
 
-* `pkgx +npm sh`
+- `pkgx +npm sh`
 
-* `cd crowd-funder-for-time-pwa && git checkout master && git pull && git checkout 1.0.2 && npm install && npm run build:web:prod && cd -`
+- `cd crowd-funder-for-time-pwa && git checkout master && git pull && git checkout
+1.0.2 && npm install && npm run build:web:prod && cd -`
 
 (The plain `npm run build:web:prod` uses the .env.production file.)
 
-* Back up the time-safari/dist folder & deploy: `mv time-safari/dist time-safari-dist-prev-2 && mv crowd-funder-for-time-pwa/dist time-safari/`
+- Back up the time-safari/dist folder & deploy: `mv time-safari/dist time-safari-dist-prev-2 && mv crowd-funder-for-time-pwa/dist time-safari/`
 
-* Record the new hash in the changelog. Edit package.json to increment version & add "-beta", `npm install`, commit, and push. Also record what version is on production.
+- Record the new hash in the changelog. Edit package.json to increment version &
+add "-beta", `npm install`, commit, and push. Also record what version is on production.
 
 ## Docker Deployment
 
-The application can be containerized using Docker for consistent deployment across environments.
+The application can be containerized using Docker for consistent deployment across
+environments.
 
-### Prerequisites
+### Docker Prerequisites
 
 - Docker installed on your system
 - Docker Compose (optional, for multi-container setups)
@@ -402,7 +421,10 @@ docker run -d \
 
 ## Desktop Build (Electron)
 
-TimeSafari's Electron build system provides comprehensive desktop application packaging and distribution capabilities across Windows, macOS, and Linux platforms. The system supports multiple build modes, environment configurations, and package formats.
+TimeSafari's Electron build system provides comprehensive desktop application
+packaging and distribution capabilities across Windows, macOS, and Linux
+platforms. The system supports multiple build modes, environment configurations,
+and package formats.
 
 ### Electron Build Commands
 
@@ -436,15 +458,18 @@ npm run clean:electron               # Clean Electron build artifacts
 
 #### Development Build
 
-Start development build using `npm run build:electron:dev` (builds and runs the app directly).
+Start development build using `npm run build:electron:dev` (builds and runs the
+app directly).
 
 #### Production Build
 
-Run production builds using the commands above. Production builds create platform-specific packages.
+Run production builds using the commands above. Production builds create
+platform-specific packages.
 
 #### Package-Specific Builds
 
-Create platform-specific packages using the commands above. These build the app and create installable packages.
+Create platform-specific packages using the commands above. These build the app
+and create installable packages.
 
 ### Single Instance Enforcement
 
@@ -484,29 +509,29 @@ The Electron app enforces single-instance operation to prevent:
 
 The Electron build process follows a multi-stage approach:
 
-```
+```text
 1. Web Build (Vite) → 2. Capacitor Sync → 3. TypeScript Compile → 4. Package
 ```
 
-**Stage 1: Web Build**
+#### **Stage 1: Web Build**
 
 - Vite builds web assets with Electron-specific configuration
 - Environment variables loaded based on build mode
 - Assets optimized for desktop application
 
-**Stage 2: Capacitor Sync**
+#### **Stage 2: Capacitor Sync**
 
 - Copies web assets to Electron app directory
 - Syncs Capacitor configuration and plugins
 - Prepares native module bindings
 
-**Stage 3: TypeScript Compile**
+#### **Stage 3: TypeScript Compile**
 
 - Compiles Electron main process TypeScript
 - Rebuilds native modules for target platform
 - Generates production-ready JavaScript
 
-**Stage 4: Package Creation**
+#### **Stage 4: Package Creation**
 
 - Creates platform-specific installers
 - Generates distribution packages
@@ -566,6 +591,7 @@ npm run build:electron:windows:prod
 ```
 
 **Configuration**:
+
 - NSIS installer with custom options
 - Desktop and Start Menu shortcuts
 - Elevation permissions for installation
@@ -588,6 +614,7 @@ npm run build:electron:mac:prod
 ```
 
 **Configuration**:
+
 - Universal binary (x64 + arm64)
 - DMG installer with custom branding
 - App Store compliance (when configured)
@@ -610,12 +637,13 @@ npm run build:electron:linux:prod
 ```
 
 **Configuration**:
+
 - AppImage for universal distribution
 - DEB package for Debian-based systems
 - RPM package for Red Hat-based systems
 - Desktop integration
 
-### Package-Specific Builds
+### Desktop Package-Specific Builds
 
 #### AppImage Package
 
@@ -634,6 +662,7 @@ npm run build:electron:appimage:prod
 ```
 
 **Features**:
+
 - Single file distribution
 - No installation required
 - Portable across Linux distributions
@@ -656,6 +685,7 @@ npm run build:electron:deb:prod
 ```
 
 **Features**:
+
 - Native package management
 - Dependency resolution
 - System integration
@@ -678,6 +708,7 @@ npm run build:electron:dmg:prod
 ```
 
 **Features**:
+
 - Native macOS installer
 - Custom branding and layout
 - Drag-and-drop installation
@@ -742,7 +773,7 @@ npm run build:electron:dmg:test         # DMG test build
 npm run build:electron:dmg:prod         # DMG production build
 ```
 
-#### Direct Script Usage
+#### Direct Script Usage Reference
 
 All npm scripts use the underlying `./scripts/build-electron.sh` script:
 
@@ -766,9 +797,9 @@ npm run clean:electron                  # Clean Electron build artifacts
 
 ### Build Output Structure
 
-#### Development Build
+#### Development Build Structure
 
-```
+```text
 electron/
 ├── app/                    # Web assets
 ├── build/                  # Compiled TypeScript
@@ -776,9 +807,9 @@ electron/
 └── node_modules/           # Dependencies
 ```
 
-#### Production Build
+#### Production Build Output
 
-```
+```text
 electron/
 ├── app/                    # Web assets
 ├── build/                  # Compiled TypeScript
@@ -796,7 +827,8 @@ electron/
 
 For public distribution on macOS, you need to code sign and notarize your app:
 
-1. Set up environment variables:
+##### 1. Set up environment variables
+
 ```bash
 export CSC_LINK=/path/to/your/certificate.p12
 export CSC_KEY_PASSWORD=your_certificate_password
@@ -804,7 +836,8 @@ export APPLE_ID=your_apple_id
 export APPLE_ID_PASSWORD=your_app_specific_password
 ```
 
-2. Build with signing:
+##### 2. Build with signing
+
 ```bash
 npm run build:electron:mac:prod
 ```
@@ -813,13 +846,15 @@ npm run build:electron:mac:prod
 
 For Windows distribution, configure Authenticode signing:
 
-1. Set up environment variables:
+##### 1. Set up desktop environment variables
+
 ```bash
 export CSC_LINK=/path/to/your/certificate.p12
 export CSC_KEY_PASSWORD=your_certificate_password
 ```
 
-2. Build with signing:
+##### 2. Build desktop with signing
+
 ```bash
 npm run build:electron:windows:prod
 ```
@@ -829,12 +864,14 @@ npm run build:electron:windows:prod
 #### Linux
 
 - **AppImage**: Make executable and run
+
 ```bash
 chmod +x electron/dist/TimeSafari-*.AppImage
 ./electron/dist/TimeSafari-*.AppImage
 ```
 
 - **DEB**: Install and run
+
 ```bash
 sudo dpkg -i electron/dist/timesafari_*_amd64.deb
 timesafari
@@ -849,6 +886,7 @@ timesafari
   3. Launch from Applications
 
 Note: If you get a security warning when running the app:
+
 1. Right-click the app
 2. Select "Open"
 3. Click "Open" in the security dialog
@@ -863,6 +901,7 @@ Note: If you get a security warning when running the app:
 #### Common Build Issues
 
 **TypeScript Compilation Errors**:
+
 ```bash
 # Clean and rebuild
 npm run clean:electron
@@ -870,30 +909,35 @@ npm run build:electron:dev
 ```
 
 **Native Module Issues**:
+
 ```bash
 # Rebuild native modules
 npm run build:electron:dev
 ```
 
 **Asset Copy Issues**:
+
 ```bash
 # Verify Capacitor sync
 npx cap sync electron
 ```
 
-#### Platform-Specific Issues
+#### Platform-Specific Building Issues
 
 **Windows**:
+
 - Ensure Windows Build Tools installed
 - Check NSIS installation
 - Verify code signing certificates
 
 **macOS**:
+
 - Install Xcode Command Line Tools
 - Configure code signing certificates
 - Check app notarization requirements
 
 **Linux**:
+
 - Install required packages (rpm-tools, etc.)
 - Check AppImage dependencies
 - Verify desktop integration
@@ -984,6 +1028,7 @@ The recommended way to build for iOS is using the automated build script:
 ```
 
 The script handles all the necessary steps including:
+
 - Environment setup and validation
 - Web asset building (Capacitor mode)
 - Capacitor synchronization
@@ -1004,11 +1049,11 @@ If you need to build manually or want to understand the individual steps:
 
 #### Each Release
 
-0. First time (or if dependencies change):
+##### 0. First time (or if dependencies change)
 
-  - `pkgx +rubygems.org sh`
+- `pkgx +rubygems.org sh`
 
-  - ... and you may have to fix these, especially with pkgx:
+- ... and you may have to fix these, especially with pkgx:
 
    ```bash
    gem_path=$(which gem)
@@ -1017,15 +1062,15 @@ If you need to build manually or want to understand the individual steps:
    export GEM_PATH=$shortened_path
    ```
 
-1. Bump the version in package.json, then here.
+##### 1. Bump the version in package.json, then here
 
-   ```
+   ```bash
    cd ios/App && xcrun agvtool new-version 40 && perl -p -i -e "s/MARKETING_VERSION = .*;/MARKETING_VERSION = 1.0.7;/g" App.xcodeproj/project.pbxproj && cd -
    # Unfortunately this edits Info.plist directly.
    #xcrun agvtool new-marketing-version 0.4.5
    ```
 
-2. Build.
+##### 2. Build
 
   Here's prod. Also available: test, dev
 
@@ -1035,22 +1080,28 @@ If you need to build manually or want to understand the individual steps:
 
 3.1. Use Xcode to build and run on simulator or device.
 
-  * Select Product -> Destination with some Simulator version. Then click the run arrow.
+- Select Product -> Destination with some Simulator version. Then click the run arrow.
 
 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
-  * Choose Product -> Archive
-    * This will trigger a build and take time, needing user's "login" keychain password (user's login password), repeatedly.
-    * If it fails with `building for 'iOS', but linking in dylib (.../.pkgx/zlib.net/v1.3.0/lib/libz.1.3.dylib) built for 'macOS'` then run XCode outside that terminal (ie. not with `npx cap open ios`).
-    * Click Distribute -> App Store Connect
-  * In AppStoreConnect, add the build to the distribution. You may have to remove the current build with the "-" when you hover over it, then "Add Build" with the new build.
-    * May have to go to App Review, click Submission, then hover over the build and click "-".
-    * It can take 15 minutes for the build to show up in the list of builds.
-    * You'll probably have to "Manage" something about encryption, disallowed in France.
-    * Then "Save" and "Add to Review" and "Resubmit to App Review".
-  * Eventually it'll be "Ready for Distribution" which means
+- Someday: Under "General" we want to rename a bunch of things to "Time Safari"
+- Choose Product -> Destination -> Any iOS Device
+- Choose Product -> Archive
+  - This will trigger a build and take time, needing user's "login" keychain
+    password (user's login password), repeatedly.
+  - If it fails with `building for 'iOS', but linking in dylib 
+    (.../.pkgx/zlib.net/v1.3.0/lib/libz.1.3.dylib) built for 'macOS'` then run
+    XCode outside that terminal (ie. not with `npx cap open ios`).
+  - Click Distribute -> App Store Connect
+- In AppStoreConnect, add the build to the distribution. You may have to remove
+  the current build with the "-" when you hover over it, then "Add Build" with the
+  new build.
+  - May have to go to App Review, click Submission, then hover over the build 
+    and click "-".
+  - It can take 15 minutes for the build to show up in the list of builds.
+  - You'll probably have to "Manage" something about encryption, disallowed in France.
+  - Then "Save" and "Add to Review" and "Resubmit to App Review".
+- Eventually it'll be "Ready for Distribution" which means
 
 ### Android Build
 
@@ -1063,7 +1114,7 @@ Prerequisites: Android Studio with Java SDK installed
 npm run build:android                 # Development build (builds and opens Android Studio)
 npm run build:android:dev            # Development build (builds and opens Android Studio)
 npm run build:android:test           # Test build (builds for testing environment)
-npm run build:android:prod           # Production build (builds for production environment)
+npm run build:android:prod           # Production build (builds for production environment).
 
 # Auto-run builds
 npm run build:android:test:run       # Test build with auto-run (builds then runs on emulator)
@@ -1085,7 +1136,7 @@ npm run build:android:assets         # Generate assets only
 npm run build:android:deploy         # Build and deploy to connected device
 ```
 
-#### Automated Build Script
+#### Android Automated Build Script
 
 The recommended way to build for Android is using the automated build script:
 
@@ -1103,16 +1154,16 @@ The recommended way to build for Android is using the automated build script:
 ./scripts/build-android.sh --help
 ```
 
-#### Manual Build Process
+#### Android Manual Build Process
 
-1. Bump the version in package.json, then here: android/app/build.gradle
+##### 1. Bump the version in package.json, then here: android/app/build.gradle
 
   ```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. Build.
+##### 2. Build
 
   Here's prod. Also available: test, dev
 
@@ -1120,13 +1171,13 @@ The recommended way to build for Android is using the automated build script:
   npm run build:android:prod
   ```
 
-3. Open the project in Android Studio:
+##### 3. Open the project in Android Studio
 
    ```bash
    npx cap open android
    ```
 
-4. 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
 
@@ -1145,9 +1196,10 @@ cd -
 
 ... or, to create a signed release:
 
-* Setup by adding the app/gradle.properties.secrets file (see properties at top of app/build.gradle) and the app/time-safari-upload-key-pkcs12.jks file
-* In app/build.gradle, bump the versionCode and maybe the versionName
-* Then `bundleRelease`:
+- Setup by adding the app/gradle.properties.secrets file (see properties at top
+  of app/build.gradle) and the app/time-safari-upload-key-pkcs12.jks file
+- In app/build.gradle, bump the versionCode and maybe the versionName
+- Then `bundleRelease`:
 
 ```bash
 cd android
@@ -1165,7 +1217,8 @@ At play.google.com/console:
 - Hit "Next".
 - Save, go to "Publishing Overview" as prompted, and click "Send changes for review".
 
-- Note that if you add testers, you have to go to "Publishing Overview" and send those changes or your (closed) testers won't see it.
+- Note that if you add testers, you have to go to "Publishing Overview" and send
+  those changes or your (closed) testers won't see it.
 
 ### Capacitor Operations
 
@@ -1263,7 +1316,7 @@ npm run lint-fix                     # Fix linting issues
 
 Use the commands above to check and fix code quality issues.
 
-## Build Architecture
+## Code Build Architecture
 
 ### Web Build Process
 
@@ -1288,19 +1341,22 @@ Use the commands above to check and fix code quality issues.
 4. **Native Build**: Platform-specific compilation
 5. **Package Creation**: APK/IPA generation
 
-## Environment Configuration
+## Architecture Environment Configuration
 
 ### Environment Files
 
 The build system supports multiple environment file patterns for different scenarios:
 
 #### Primary Environment Files
+
 - `.env.development` - Development environment (local development)
 - `.env.test` - Testing environment (staging/testing)
 - `.env.production` - Production environment (production deployment)
 
 #### Fallback and Local Files
-- `.env` - General fallback environment file (loaded if mode-specific file doesn't exist)
+
+- `.env` - General fallback environment file (loaded if mode-specific file
+  doesn't exist)
 - `.env.local` - Local development overrides (gitignored)
 - `.env.*.local` - Mode-specific local overrides (gitignored)
 
@@ -1324,6 +1380,7 @@ The build system supports multiple environment file patterns for different scena
 ### Key Environment Variables
 
 #### API Server Configuration
+
 ```bash
 # API Servers (Environment-specific)
 VITE_DEFAULT_ENDORSER_API_SERVER=https://api.endorser.ch
@@ -1342,6 +1399,7 @@ VITE_BVC_MEETUPS_PROJECT_CLAIM_ID=https://endorser.ch/entity/01HWE8FWHQ1YGP7GFZY
 #### Environment-Specific Configurations
 
 **Development Environment** (`.env.development`):
+
 ```bash
 # Development API Servers (Local)
 VITE_DEFAULT_ENDORSER_API_SERVER=http://localhost:3000
@@ -1351,6 +1409,7 @@ VITE_APP_SERVER=http://localhost:8080
 ```
 
 **Test Environment** (`.env.test`):
+
 ```bash
 # Test API Servers
 VITE_DEFAULT_ENDORSER_API_SERVER=https://test-api.endorser.ch
@@ -1360,6 +1419,7 @@ VITE_APP_SERVER=https://test.timesafari.app
 ```
 
 **Production Environment** (`.env.production`):
+
 ```bash
 # Production API Servers
 VITE_DEFAULT_ENDORSER_API_SERVER=https://api.endorser.ch
@@ -1371,16 +1431,19 @@ VITE_APP_SERVER=https://timesafari.app
 ### Platform-Specific Overrides
 
 #### Android Development
+
 - **Emulator**: Uses `http://10.0.2.2:3000` (Android emulator default)
 - **Physical Device**: Uses custom IP address (e.g., `http://192.168.1.100:3000`)
 
 #### iOS Development
+
 - **Simulator**: Uses `http://localhost:3000` (iOS simulator default)
 - **Physical Device**: Uses custom IP address (e.g., `http://192.168.1.100:3000`)
 
 ### Environment Loading Process
 
 1. **Build Script Initialization**
+
    ```bash
    # scripts/common.sh - setup_build_env()
    if [ "$BUILD_MODE" = "development" ]; then
@@ -1390,6 +1453,7 @@ VITE_APP_SERVER=https://timesafari.app
    ```
 
 2. **Platform-Specific Overrides**
+
    ```bash
    # scripts/build-android.sh
    if [ "$BUILD_MODE" = "development" ]; then
@@ -1399,13 +1463,14 @@ VITE_APP_SERVER=https://timesafari.app
    ```
 
 3. **Environment File Loading**
+
    ```bash
    # scripts/build-web.sh
    local env_file=".env.$BUILD_MODE"  # .env.development, .env.test, .env.production
    if [ -f "$env_file" ]; then
        load_env_file "$env_file"
    fi
-   
+
    # Fallback to .env
    if [ -f ".env" ]; then
        load_env_file ".env"
@@ -1413,6 +1478,7 @@ VITE_APP_SERVER=https://timesafari.app
    ```
 
 4. **Application Usage**
+
    ```typescript
    // src/constants/app.ts
    export const DEFAULT_ENDORSER_API_SERVER =
@@ -1420,9 +1486,9 @@ VITE_APP_SERVER=https://timesafari.app
      AppString.PROD_ENDORSER_API_SERVER;
    ```
 
-## Troubleshooting
+## Building Troubleshooting
 
-### Common Issues
+### Common Issues Building
 
 #### Build Failures
 
@@ -1447,29 +1513,34 @@ npm run build:ios:assets
 npm run build:android:assets
 ```
 
-### Platform-Specific Issues
+### More Platform-Specific Building Issues
+
+#### Building on Windows
 
-#### Windows
 - Ensure Windows Build Tools installed
 - Check NSIS installation
 - Verify code signing certificates
 
-#### macOS
+#### Building on macOS
+
 - Install Xcode Command Line Tools
 - Configure code signing certificates
 - Check app notarization requirements
 
-#### Linux
+#### Building on Linux
+
 - Install required packages (rpm-tools, etc.)
 - Check AppImage dependencies
 - Verify desktop integration
 
 #### iOS
+
 - Install Xcode and Command Line Tools
 - Configure signing certificates
 - Check provisioning profiles
 
 #### Android
+
 - Install Android Studio and SDK
 - Configure signing keys
 - Check device/emulator setup
@@ -1488,37 +1559,45 @@ npm run build:android:assets
 
 ### Build Process Overview
 
-TimeSafari's build system follows a multi-stage process that prepares assets, combines scripts, and generates platform-specific outputs.
+TimeSafari's build system follows a multi-stage process that prepares assets,
+combines scripts, and generates platform-specific outputs.
 
 #### Pre-Build Preparation
 
-**1. Service Worker Script Preparation**
+##### 1. Service Worker Script Preparation
+
 ```bash
 # Optional: Format third-party service worker scripts
 npx prettier --write ./sw_scripts/
 ```
 
 **What this does:**
-- Formats cryptographic libraries (`nacl.js`, `noble-curves.js`, `noble-hashes.js`, etc.)
+
+- Formats cryptographic libraries (`nacl.js`, `noble-curves.js`,
+ `noble-hashes.js`, etc.)
 - These scripts are automatically combined during the build process
 - Improves readability and makes version control diffs cleaner
 - **Note**: This is optional and only needed when updating third-party scripts
 
 **2. Automatic Pre-Build Steps**
 The `prebuild` script automatically runs before any build:
+
 ```json
 "prebuild": "eslint --ext .js,.ts,.vue --ignore-path .gitignore src && node sw_combine.js && node scripts/copy-wasm.js"
 ```
 
 **What happens automatically:**
+
 - **ESLint**: Checks and fixes code formatting in `src/`
-- **Script Combination**: `sw_combine.js` combines all `sw_scripts/*.js` files into `sw_scripts-combined.js`
+- **Script Combination**: `sw_combine.js` combines all `sw_scripts/*.js` files
+  into `sw_scripts-combined.js`
 - **WASM Copy**: `copy-wasm.js` copies SQLite WASM files to `public/wasm/`
 
-#### Build Architecture
+#### Build Process Architecture
 
 **Web Build Process:**
-```
+
+```text
 1. Pre-Build: ESLint + Script Combination + WASM Copy
 2. Environment Setup: Load .env files, set NODE_ENV
 3. Vite Build: Bundle web assets with PWA support
@@ -1527,7 +1606,8 @@ The `prebuild` script automatically runs before any build:
 ```
 
 **Electron Build Process:**
-```
+
+```text
 1. Web Build: Vite builds web assets for Electron
 2. Capacitor Sync: Copies assets to Electron app directory
 3. TypeScript Compile: Compiles main process code
@@ -1536,7 +1616,8 @@ The `prebuild` script automatically runs before any build:
 ```
 
 **Mobile Build Process:**
-```
+
+```text
 1. Web Build: Vite builds web assets
 2. Capacitor Sync: Syncs with native platforms
 3. Asset Generation: Creates platform-specific assets
@@ -1547,12 +1628,14 @@ The `prebuild` script automatically runs before any build:
 #### Service Worker Architecture
 
 **Script Organization:**
+
 - `sw_scripts/` - Individual third-party scripts
 - `sw_combine.js` - Combines scripts into single file
 - `sw_scripts-combined.js` - Combined service worker (317KB, 10K+ lines)
 - `vite.config.utils.mts` - PWA configuration using combined script
 
 **PWA Integration:**
+
 ```typescript
 // vite.config.utils.mts
 pwaConfig: {
@@ -1563,31 +1646,35 @@ pwaConfig: {
 ```
 
 **What Gets Combined:**
+
 - `nacl.js` - NaCl cryptographic library
 - `noble-curves.js` - Elliptic curve cryptography (177KB)
 - `noble-hashes.js` - Cryptographic hash functions (91KB)
 - `safari-notifications.js` - Safari-specific notifications
 - `additional-scripts.js` - Additional service worker functionality
 
-#### Environment Configuration
+#### Process Environment Configuration
 
 **Environment Files:**
 The build system supports multiple environment file patterns:
 
 - `.env.development` - Development environment (local development)
-- `.env.test` - Testing environment (staging/testing)  
+- `.env.test` - Testing environment (staging/testing)
 - `.env.production` - Production environment (production deployment)
-- `.env` - General fallback environment file (loaded if mode-specific file doesn't exist)
+- `.env` - General fallback environment file (loaded if mode-specific file
+  doesn't exist)
 - `.env.local` - Local development overrides (gitignored)
 - `.env.*.local` - Mode-specific local overrides (gitignored)
 
 **Environment Variable Precedence (Highest to Lowest):**
+
 1. **Shell Script Overrides** - Platform-specific overrides in build scripts
 2. **Environment-Specific .env Files** - `.env.development`, `.env.test`, `.env.production`
 3. **Fallback .env File** - General `.env` file (if mode-specific file doesn't exist)
 4. **Hardcoded Constants** - Default values in `src/constants/app.ts`
 
 **Key Environment Variables:**
+
 ```bash
 # API Servers (Environment-specific)
 VITE_DEFAULT_ENDORSER_API_SERVER=https://api.endorser.ch
@@ -1604,13 +1691,17 @@ VITE_BVC_MEETUPS_PROJECT_CLAIM_ID=https://endorser.ch/entity/01HWE8FWHQ1YGP7GFZY
 ```
 
 **Platform-Specific Overrides:**
-- **Android Development**: `http://10.0.2.2:3000` (emulator) or custom IP (physical device)
-- **iOS Development**: `http://localhost:3000` (simulator) or custom IP (physical device)
 
-#### Build Output Structure
+- **Android Development**: `http://10.0.2.2:3000` (emulator) or custom IP
+(physical device)
+- **iOS Development**: `http://localhost:3000` (simulator) or custom IP (physical
+device)
+
+#### Build Process Output Structure
 
 **Web Build:**
-```
+
+```folders
 dist/
 ├── index.html              # Main HTML file
 ├── assets/                 # Bundled JavaScript/CSS
@@ -1620,7 +1711,8 @@ dist/
 ```
 
 **Electron Build:**
-```
+
+```folders
 electron/
 ├── app/                    # Web assets
 ├── build/                  # Compiled TypeScript
@@ -1635,35 +1727,41 @@ electron/
 #### Manual vs Automatic Steps
 
 **Manual Steps (Developer Responsibility):**
+
 - Database migration testing
 - Service worker script formatting (optional)
 - Version updates and changelog
 - Environment-specific builds
 
 **Automatic Steps (Build System):**
+
 - Code linting and formatting
 - Script combination
 - Asset optimization
 - Package creation
 - Service worker injection
 
-This architecture ensures consistent builds across all platforms while providing flexibility for platform-specific optimizations and manual quality assurance steps.
+This architecture ensures consistent builds across all platforms while providing
+flexibility for platform-specific optimizations and manual quality assurance steps.
 
 ---
 
 ## Appendix A: Build Scripts Reference
 
-This appendix provides detailed documentation for all build scripts in the `scripts/` directory.
+This appendix provides detailed documentation for all build scripts in the
+`scripts/` directory.
 
 ### A.1 build-web.sh
 
-**File**: `scripts/build-web.sh`  
-**Author**: Matthew Raymer  
+**File**: `scripts/build-web.sh`
+**Author**: Matthew Raymer
 **Description**: Web build script for TimeSafari application
 
-**Purpose**: Handles the complete web build process including cleanup, environment setup, Vite build, and optional Docker containerization.
+**Purpose**: Handles the complete web build process including cleanup,
+environment setup, Vite build, and optional Docker containerization.
 
 **Usage**:
+
 ```bash
 # Direct script usage
 ./scripts/build-web.sh                    # Development build
@@ -1687,11 +1785,13 @@ npm run build:web:docker:prod             # Production Docker build
 ```
 
 **Build Modes**:
+
 - **Development**: Starts Vite dev server with hot reload (default)
 - **Test**: Optimized for testing with minimal minification
 - **Production**: Optimized for production with full minification
 
 **Script Features**:
+
 - **Environment Validation**: Checks for Node.js, npm, npx, package.json
 - **Environment Setup**: Loads `.env` files based on build mode
 - **Clean Build**: Removes previous `dist/` directory
@@ -1700,6 +1800,7 @@ npm run build:web:docker:prod             # Production Docker build
 - **Local Serving**: Built-in HTTP server for testing builds
 
 **Exit Codes**:
+
 - `1` - Web cleanup failed
 - `2` - Environment setup failed
 - `3` - Vite build failed
@@ -1709,13 +1810,15 @@ npm run build:web:docker:prod             # Production Docker build
 
 ### A.2 build-electron.sh
 
-**File**: `scripts/build-electron.sh`  
-**Author**: Matthew Raymer  
+**File**: `scripts/build-electron.sh`
+**Author**: Matthew Raymer
 **Description**: Clean, modular Electron build script for TimeSafari application
 
-**Purpose**: Handles Electron builds with proper separation of concerns and no command chaining, following DRY principles.
+**Purpose**: Handles Electron builds with proper separation of concerns and no
+command chaining, following DRY principles.
 
 **Usage**:
+
 ```bash
 # Direct script usage
 ./scripts/build-electron.sh                    # Development build (runs app)
@@ -1738,22 +1841,26 @@ npm run build:web:docker:prod             # Production Docker build
 ```
 
 **Build Modes**:
+
 - **Development**: Development build (runs app)
 - **Test**: Test environment build
 - **Production**: Production environment build
 - **Clean**: Clean Electron build artifacts only
 
 **Platforms**:
+
 - **Windows**: Windows build
 - **macOS**: macOS build
 - **Linux**: Linux build
 
 **Packages**:
+
 - **AppImage**: Linux AppImage
 - **Deb**: Debian package
 - **DMG**: macOS DMG
 
 **Exit Codes**:
+
 - `1` - Invalid arguments
 - `2` - Electron cleanup failed
 - `3` - Web build failed
@@ -1765,21 +1872,23 @@ npm run build:web:docker:prod             # Production Docker build
 
 ### A.3 build-android.sh
 
-**File**: `scripts/build-android.sh`  
-**Author**: Matthew Raymer  
-**Date**: 2025-07-11  
+**File**: `scripts/build-android.sh`
+**Author**: Matthew Raymer
+**Date**: 2025-07-11
 **Description**: Android build script for TimeSafari application
 
-**Purpose**: Handles the complete Android build process including cleanup, web build, Capacitor build, Gradle build, and Android Studio launch.
+**Purpose**: Handles the complete Android build process including cleanup, web
+  build, Capacitor build, Gradle build, and Android Studio launch.
 
 **Usage**:
+
 ```bash
 # Direct script usage
 ./scripts/build-android.sh [options]
 
 # Options
 --dev, --development    Build for development environment
---test                  Build for testing environment  
+--test                  Build for testing environment
 --prod, --production    Build for production environment
 --debug                 Build debug APK
 --release               Build release APK
@@ -1802,15 +1911,18 @@ npm run build:web:docker:prod             # Production Docker build
 ```
 
 **Build Modes**:
+
 - **Development**: Build for development environment
 - **Test**: Build for testing environment
 - **Production**: Build for production environment
 
 **Build Types**:
+
 - **Debug**: Build debug APK (default)
 - **Release**: Build release APK
 
 **Exit Codes**:
+
 - `1` - Android cleanup failed
 - `2` - Web build failed
 - `3` - Capacitor build failed
@@ -1823,14 +1935,16 @@ npm run build:web:docker:prod             # Production Docker build
 
 ### A.4 build-ios.sh
 
-**File**: `scripts/build-ios.sh`  
-**Author**: Matthew Raymer  
-**Date**: 2025-07-11  
+**File**: `scripts/build-ios.sh`
+**Author**: Matthew Raymer
+**Date**: 2025-07-11
 **Description**: iOS build script for TimeSafari application
 
-**Purpose**: Handles the complete iOS build process including cleanup, web build, Capacitor build, Xcode build, and iOS Simulator launch.
+**Purpose**: Handles the complete iOS build process including cleanup, web build,
+  Capacitor build, Xcode build, and iOS Simulator launch.
 
 **Usage**:
+
 ```bash
 # Direct script usage
 ./scripts/build-ios.sh [options]
@@ -1861,15 +1975,18 @@ npm run build:web:docker:prod             # Production Docker build
 ```
 
 **Build Modes**:
+
 - **Development**: Build for development environment
 - **Test**: Build for testing environment
 - **Production**: Build for production environment
 
 **Build Types**:
+
 - **Debug**: Build debug app (default)
 - **Release**: Build release app
 
 **Key Features**:
+
 - **Environment Validation**: Checks for Xcode, iOS Simulator, Capacitor
 - **Resource Checking**: Validates app icons, splash screens, Info.plist
 - **Clean Build**: Removes Xcode build artifacts and DerivedData
@@ -1878,15 +1995,17 @@ npm run build:web:docker:prod             # Production Docker build
 
 ### A.5 common.sh
 
-**File**: `scripts/common.sh`  
-**Author**: Matthew Raymer  
+**File**: `scripts/common.sh`
+**Author**: Matthew Raymer
 **Description**: Common utilities and functions for build scripts
 
-**Purpose**: Provides shared functionality, logging, environment setup, and utility functions used by all build scripts.
+**Purpose**: Provides shared functionality, logging, environment setup, and
+utility functions used by all build scripts.
 
 **Key Functions**:
 
 **Logging Functions**:
+
 ```bash
 log_info "message"      # Info level logging
 log_success "message"   # Success level logging
@@ -1896,6 +2015,7 @@ log_debug "message"     # Debug level logging
 ```
 
 **Environment Functions**:
+
 ```bash
 setup_build_env "platform"    # Setup build environment for platform
 load_env_file "filename"      # Load environment variables from file
@@ -1903,6 +2023,7 @@ print_env_vars "prefix"       # Print environment variables with prefix
 ```
 
 **Utility Functions**:
+
 ```bash
 check_command "command"       # Check if command is available
 check_file "filename"         # Check if file exists
@@ -1911,6 +2032,7 @@ clean_build_artifacts "dir"   # Clean build artifacts directory
 ```
 
 **Validation Functions**:
+
 ```bash
 validate_build_environment    # Validate common build environment
 setup_app_directories         # Setup application directories
@@ -1919,13 +2041,15 @@ print_header "title"          # Print formatted header
 
 ### A.6 Cleaning Commands
 
-**File**: `package.json` scripts  
-**Author**: Matthew Raymer  
+**File**: `package.json` scripts
+**Author**: Matthew Raymer
 **Description**: Platform-specific and comprehensive cleaning commands
 
-**Purpose**: Provides commands to clean build artifacts for individual platforms or all platforms at once.
+**Purpose**: Provides commands to clean build artifacts for individual platforms
+or all platforms at once.
 
 **Available Commands**:
+
 ```bash
 # Platform-specific cleaning
 npm run clean:ios              # Clean iOS build artifacts
@@ -1944,26 +2068,31 @@ npm run build:electron:clean   # Clean Electron build artifacts (via build scrip
 **Command Details**:
 
 **clean:ios**:
+
 - Removes iOS build directories (`ios/App/build`, `ios/App/Pods`, etc.)
 - Cleans DerivedData and Capacitor artifacts
 - Safe to run multiple times
 
 **clean:android**:
+
 - Uninstalls app from connected devices
 - Cleans Android build artifacts
 - Safe to run multiple times
 
 **clean:electron**:
+
 - Cleans Electron build artifacts (`electron/build`, `electron/dist`, `electron/app`)
 - Removes TypeScript compilation artifacts
 - Safe to run multiple times
 
 **clean:all**:
+
 - Executes all platform-specific clean commands in sequence
 - Stops on first failure (uses `&&` operator)
 - Most convenient for complete cleanup
 
 **Usage Examples**:
+
 ```bash
 # Clean everything before a fresh build
 npm run clean:all
@@ -1981,17 +2110,20 @@ npm run build:web:dev
 
 ## Appendix B: Vite Configuration Files Reference
 
-This appendix provides detailed documentation for all Vite configuration files used in the TimeSafari build system.
+This appendix provides detailed documentation for all Vite configuration files used
+in the TimeSafari build system.
 
 ### B.1 vite.config.common.mts
 
-**File**: `vite.config.common.mts`  
-**Author**: Matthew Raymer  
+**File**: `vite.config.common.mts`
+**Author**: Matthew Raymer
 **Description**: Common Vite configuration shared across all platforms
 
-**Purpose**: Provides base configuration that is extended by platform-specific configs with unified environment handling and platform detection.
+**Purpose**: Provides base configuration that is extended by platform-specific
+configs with unified environment handling and platform detection.
 
 **Key Features**:
+
 - **Platform Detection**: Automatically detects and configures for web/capacitor/electron
 - **Environment Setup**: Loads environment variables and sets platform flags
 - **Path Aliases**: Configures TypeScript path resolution and module aliases
@@ -1999,6 +2131,7 @@ This appendix provides detailed documentation for all Vite configuration files u
 - **Dependency Management**: Handles platform-specific dependencies
 
 **Configuration Structure**:
+
 ```typescript
 export async function createBuildConfig(platform: string): Promise<UserConfig> {
   const appConfig = await loadAppConfig();
@@ -2066,25 +2199,29 @@ export async function createBuildConfig(platform: string): Promise<UserConfig> {
 ```
 
 **Environment Variables**:
+
 - `VITE_PLATFORM`: Set to platform name (web/capacitor/electron)
 - `__IS_MOBILE__`: Boolean flag for mobile platforms
 - `__IS_ELECTRON__`: Boolean flag for Electron platform
 - `__USE_QR_READER__`: Boolean flag for QR reader availability
 
 **Path Aliases**:
+
 - `@`: Points to `src/` directory
 - `@nostr/tools`: Nostr tools library
 - `path`, `fs`, `crypto`: Node.js polyfills for browser
 
 ### B.2 vite.config.web.mts
 
-**File**: `vite.config.web.mts`  
-**Author**: Matthew Raymer  
+**File**: `vite.config.web.mts`
+**Author**: Matthew Raymer
 **Description**: Vite configuration for web platform with PWA support
 
-**Purpose**: Configures Vite for web builds with environment-specific optimizations and PWA features.
+**Purpose**: Configures Vite for web builds with environment-specific
+optimizations and PWA features.
 
 **Key Features**:
+
 - **Environment-Specific Configuration**: Different settings for dev/test/prod
 - **PWA Integration**: Progressive Web App support with service worker
 - **Build Optimization**: Manual chunk splitting for better caching
@@ -2094,6 +2231,7 @@ export async function createBuildConfig(platform: string): Promise<UserConfig> {
 **Environment Configurations**:
 
 **Development Mode**:
+
 ```typescript
 {
   build: {
@@ -2110,6 +2248,7 @@ export async function createBuildConfig(platform: string): Promise<UserConfig> {
 ```
 
 **Test Mode**:
+
 ```typescript
 {
   build: {
@@ -2126,6 +2265,7 @@ export async function createBuildConfig(platform: string): Promise<UserConfig> {
 ```
 
 **Production Mode**:
+
 ```typescript
 {
   build: {
@@ -2151,6 +2291,7 @@ export async function createBuildConfig(platform: string): Promise<UserConfig> {
 ```
 
 **PWA Configuration**:
+
 ```typescript
 VitePWA({
   registerType: 'autoUpdate',
@@ -2169,13 +2310,15 @@ VitePWA({
 
 ### B.3 vite.config.electron.mts
 
-**File**: `vite.config.electron.mts`  
-**Author**: Matthew Raymer  
+**File**: `vite.config.electron.mts`
+**Author**: Matthew Raymer
 **Description**: Vite configuration for Electron desktop platform
 
-**Purpose**: Configures Vite for Electron builds with desktop-specific optimizations and native module support.
+**Purpose**: Configures Vite for Electron builds with desktop-specific optimizations
+  and native module support.
 
 **Key Features**:
+
 - **Electron-Specific Entry Point**: Uses `main.electron.ts` instead of `main.web.ts`
 - **Native Module Support**: Handles Electron-specific dependencies
 - **Desktop Optimizations**: Larger chunk sizes and desktop-specific settings
@@ -2183,10 +2326,11 @@ VitePWA({
 - **External Dependencies**: Properly handles Electron and native modules
 
 **Configuration Structure**:
+
 ```typescript
 export default defineConfig(async () => {
   const baseConfig = await createBuildConfig("electron");
-  
+
   return {
     ...baseConfig,
     plugins: [
@@ -2220,24 +2364,28 @@ export default defineConfig(async () => {
 ```
 
 **Plugins**:
+
 - **electron-entry-point**: Replaces main entry point for Electron
 - **electron-config**: Handles Electron-specific configurations
 - **suppress-source-maps**: Suppresses source map loading errors
 
 **External Dependencies**:
+
 - `electron`: Electron runtime
 - `@capacitor-community/electron`: Capacitor Electron plugin
 - `better-sqlite3-multiple-ciphers`: Native SQLite module
 
 ### B.4 vite.config.capacitor.mts
 
-**File**: `vite.config.capacitor.mts`  
-**Author**: Matthew Raymer  
+**File**: `vite.config.capacitor.mts`
+**Author**: Matthew Raymer
 **Description**: Vite configuration for Capacitor mobile platform
 
-**Purpose**: Provides minimal configuration for Capacitor builds, inheriting from common config.
+**Purpose**: Provides minimal configuration for Capacitor builds, inheriting from
+common config.
 
 **Configuration**:
+
 ```typescript
 import { defineConfig } from "vite";
 import { createBuildConfig } from "./vite.config.common.mts";
@@ -2246,6 +2394,7 @@ export default defineConfig(async () => createBuildConfig('capacitor'));
 ```
 
 **Key Features**:
+
 - **Minimal Configuration**: Inherits all settings from common config
 - **Mobile Platform**: Automatically configures for mobile-specific settings
 - **PWA Disabled**: Progressive Web App features disabled for native apps
@@ -2253,8 +2402,8 @@ export default defineConfig(async () => createBuildConfig('capacitor'));
 
 ### B.5 vite.config.utils.mts
 
-**File**: `vite.config.utils.mts`  
-**Author**: Matthew Raymer  
+**File**: `vite.config.utils.mts`
+**Author**: Matthew Raymer
 **Description**: Utility functions for Vite configuration
 
 **Purpose**: Provides shared configuration loading and PWA manifest generation.
@@ -2266,6 +2415,7 @@ export default defineConfig(async () => createBuildConfig('capacitor'));
 **loadAppConfig()**: Loads complete application configuration including PWA settings
 
 **PWA Configuration**:
+
 ```typescript
 interface PWAConfig {
   registerType: string;
@@ -2284,11 +2434,13 @@ interface PWAConfig {
 ```
 
 **Manifest Icons**:
+
 - Android Chrome 192x192 PNG
 - Android Chrome 512x512 PNG
 - Maskable icons for adaptive UI
 
 **Share Target Configuration**:
+
 ```typescript
 share_target: {
   action: "/share-target",
@@ -2301,6 +2453,7 @@ share_target: {
 ```
 
 **Alias Configuration**:
+
 - `@`: Source directory alias
 - `buffer`: Buffer polyfill
 - `dexie-export-import`: Database import/export utilities
@@ -2335,23 +2488,27 @@ source "$(dirname "$0")/common.sh"
 ### C.3 Build Process Flow
 
 **Web Build**:
-```
+
+```text
 build-web.sh → vite.config.web.mts → dist/
 ```
 
 **Electron Build**:
-```
+
+```text
 build-electron.sh → vite.config.electron.mts → electron/app/
 ```
 
 **Mobile Build**:
-```
+
+```text
 build-android.sh/build-ios.sh → vite.config.capacitor.mts → android/ios/
 ```
 
 ### C.4 Error Handling
 
 All scripts use consistent error handling:
+
 - Exit codes for different failure types
 - Verbose logging with `--verbose` flag
 - Safe command execution with `safe_execute()`
@@ -2360,20 +2517,25 @@ All scripts use consistent error handling:
 ### C.5 Platform-Specific Considerations
 
 **Web Platform**:
+
 - PWA features enabled
 - Service worker injection
 - Browser-specific optimizations
 
 **Electron Platform**:
+
 - Native module support
 - Desktop-specific entry points
 - Source map suppression
 
 **Mobile Platform**:
+
 - Capacitor integration
 - Native asset generation
 - Platform-specific builds
 
 ---
 
-**Note**: This documentation is maintained alongside the build system. For the most up-to-date information, refer to the actual script files and Vite configuration files in the repository.
+**Note**: This documentation is maintained alongside the build system. For the
+most up-to-date information, refer to the actual script files and Vite
+configuration files in the repository.
diff --git a/CHANGELOG.md b/CHANGELOG.md
index 19209fb6..641ff920 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -6,69 +6,88 @@ 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.7] - 2025.08.18
+
 ### Fixed
-- Deep link for onboard-meeting-members
 
+- Deep link for onboard-meeting-members
 
 ## [1.0.6] - 2025.08.09
+
 ### Fixed
-- Deep link errors where none would validate
 
+- Deep link errors where none would validate
 
 ## [1.0.5] - 2025.07.24
+
 ### Fixed
-- Export & import of contacts corrupted contact methods
 
+- Export & import of contacts corrupted contact methods
 
 ## [1.0.4] - 2025.07.20 - 002f2407208d56cc59c0aa7c880535ae4cbace8b
+
 ### Fixed
-- Deep link for invite-one-accept
 
+- Deep link for invite-one-accept
 
 ## [1.0.3] - 2025.07.12 - a9a8ba217cd6015321911e98e6843e988dc2c4ae
+
 ### Changed
+
 - Photo is pinned to profile mode
+
 ### Fixed
+
 - Deep link URLs (and other prod settings)
 - Error in BVC begin view
 
-
 ## [1.0.2] - 2025.06.20 - 276e0a741bc327de3380c4e508cccb7fee58c06d
+
 ### Added
-- Version on feed title
 
+- Version on feed title
 
 ## [1.0.1] - 2025.06.20
+
 ### Added
-- Allow a user to block someone else's content from view
 
+- Allow a user to block someone else's content from view
 
 ## [1.0.0] - 2025.06.20 - 5aa693de6337e5dbb278bfddc6bd39094bc14f73
+
 ### Added
-- Web-oriented migration from IndexedDB to SQLite
 
+- Web-oriented migration from IndexedDB to SQLite
 
 ## [0.5.8]
+
 ### Added
+
 - /deep-link/ path for URLs that are shared with people
+
 ### Changed
+
 - External links now go to /deep-link/...
 - Feed visuals now have arrow imagery from giver to receiver
 
-
 ## [0.4.7]
+
 ### Fixed
+
 - Cameras everywhere
+
 ### Changed
-- IndexedDB -> SQLite
 
+- IndexedDB -> SQLite
 
 ## [0.4.5] - 2025.02.23
+
 ### Added
+
 - Total amounts of gives on project page
+
 ### Changed in DB or environment
-- Requires Endorser.ch version 4.2.6+
 
+- Requires Endorser.ch version 4.2.6+
 
 ## [0.4.4] - 2025.02.17
 
diff --git a/TASK_storage.md b/TASK_storage.md
index a33cbb87..52b52b76 100644
--- a/TASK_storage.md
+++ b/TASK_storage.md
@@ -1,7 +1,6 @@
 
 # What to do about storage for native apps?
 
-
 ## Problem
 
 We can't trust iOS IndexedDB to persist. I want to start delivering an app to people now, in preparation for presentations mid-June: Rotary on June 12 and Porcfest on June 17.
@@ -14,7 +13,6 @@ We can't trust iOS IndexedDB to persist. I want to start delivering an app to pe
 
 Also, with sensitive data, the accounts info should be encrypted.
 
-
 # Options
 
 * There is a community [SQLite plugin for Capacitor](https://github.com/capacitor-community/sqlite) with encryption by [SQLCipher](https://github.com/sqlcipher/sqlcipher).
@@ -29,16 +27,12 @@ Also, with sensitive data, the accounts info should be encrypted.
 
 * Not an option yet: Dexie may support SQLite in [a future version](https://dexie.org/roadmap/dexie5.0).
 
-
-
 # Current Plan
 
 * Implement SQLite for Capacitor & web, with encryption. That will allow us to test quickly and keep the same interface for native & web, but we don't deal with migrations for current web users.
 
 * After that is delivered, write a migration for current web users from IndexedDB to SQLite.
 
-
-
 # Current method calls
 
 ... which is not 100% complete because the AI that generated thus claimed no usage of 'temp' DB.
@@ -80,5 +74,3 @@ Logs operations:
 db.logs.get(todayKey) - Gets logs for a specific day
 db.logs.update(todayKey, { message: fullMessage }) - Updates logs
 db.logs.clear() - Clears all logs
-
-
diff --git a/doc/DEEP_LINKS.md b/doc/DEEP_LINKS.md
index a6bf9f6b..8638074b 100644
--- a/doc/DEEP_LINKS.md
+++ b/doc/DEEP_LINKS.md
@@ -47,6 +47,7 @@ type ClaimParams = z.infer<typeof claimSchema>;
 ### Type Safety Layers
 
 1. **Schema Definition**
+
    ```typescript
    // src/interfaces/deepLinks.ts
    export const deepLinkSchemas = {
@@ -59,6 +60,7 @@ type ClaimParams = z.infer<typeof claimSchema>;
    ```
 
 2. **Type Generation**
+
    ```typescript
    // Types are automatically generated from schemas
    export type DeepLinkParams = {
@@ -67,6 +69,7 @@ type ClaimParams = z.infer<typeof claimSchema>;
    ```
 
 3. **Runtime Validation**
+
    ```typescript
    // In DeepLinkHandler
    const result = deepLinkSchemas.claim.safeParse(params);
diff --git a/doc/README.md b/doc/README.md
index 45e98fc4..3e876ca0 100644
--- a/doc/README.md
+++ b/doc/README.md
@@ -6,7 +6,7 @@ This uses Pandoc and BasicTex (LaTeX) Installed through Homebrew.
 
 ### Set Up
 
-```bash 
+```bash
 brew install pandoc
 
 brew install basictex
@@ -54,7 +54,7 @@ sudo tlmgr install sourceserifpro
 
 The following guide was adapted to this project except that we install with Brew and have a few more packages.
 
-Guide: https://daniel.feldroy.com/posts/setting-up-latex-on-mac-os-x
+Guide: <https://daniel.feldroy.com/posts/setting-up-latex-on-mac-os-x>
 
 ### Usage
 
@@ -71,6 +71,7 @@ open usage-guide.pdf
 ```
 
 Or use this one-liner
+
 ```bash
 pandoc usage-guide.md -o usage-guide.pdf && open usage-guide.pdf
 ```
diff --git a/doc/architecture-decisions.md b/doc/architecture-decisions.md
index 40fa3d3f..11861b8f 100644
--- a/doc/architecture-decisions.md
+++ b/doc/architecture-decisions.md
@@ -122,4 +122,4 @@ export default class HomeView extends Vue {
 
 ---
 
-*This decision was made based on the current codebase architecture and team expertise. The mixin approach provides the best balance of performance, developer experience, and architectural consistency for the TimeSafari application.* 
\ No newline at end of file
+*This decision was made based on the current codebase architecture and team expertise. The mixin approach provides the best balance of performance, developer experience, and architectural consistency for the TimeSafari application.*
diff --git a/doc/asset-migration-plan.md b/doc/asset-migration-plan.md
index 3a05353c..86c0954e 100644
--- a/doc/asset-migration-plan.md
+++ b/doc/asset-migration-plan.md
@@ -103,6 +103,7 @@ scripts/
 ### Configuration Schema
 
 The schema enforces:
+
 - Source files must be in `resources/` directory
 - Required fields for icon and splash sections
 - Android adaptive icon support (foreground/background/monochrome)
diff --git a/doc/build-modernization-context.md b/doc/build-modernization-context.md
index 133c2ad6..4f2ae09e 100644
--- a/doc/build-modernization-context.md
+++ b/doc/build-modernization-context.md
@@ -3,11 +3,13 @@
 **Author:** Matthew Raymer
 
 ## Motivation
+
 - Eliminate manual hacks and post-build scripts for Electron builds
 - Ensure maintainability, reproducibility, and security of build outputs
 - Unify build, test, and deployment scripts for developer experience and CI/CD
 
 ## Key Technical Decisions
+
 - **Vite is the single source of truth for build output**
   - All Electron build output (main process, preload, renderer HTML/CSS/JS) is managed by `vite.config.electron.mts`
 - **CSS injection for Electron is handled by a Vite plugin**
@@ -21,6 +23,7 @@
   - Renderer assets: `dist-electron/www/` (HTML, CSS, JS)
 
 ## Security & Maintenance Checklist
+
 - [x] All scripts and configs are committed and documented
 - [x] No manual file hacks remain
 - [x] All build output is deterministic and reproducible
@@ -28,24 +31,29 @@
 - [x] Documentation (`BUILDING.md`) is up to date
 
 ## How to Build Electron
+
 1. Run:
+
    ```bash
    ./scripts/build-electron.sh
    ```
+
 2. Output will be in `dist-electron/`:
    - `main.js`, `preload.js` in root
    - `www/` contains all renderer assets
 3. No manual post-processing is required
 
 ## Customization
+
 - **Vite config:** All build output and asset handling is controlled in `vite.config.electron.mts`
 - **CSS/HTML injection:** Use Vite plugins (see `electron-css-injection` in the config) for further customization
 - **Build scripts:** All orchestration is in `scripts/` and documented in `BUILDING.md`
 
 ## For Future Developers
+
 - Always use Vite plugins/config for build output changes
 - Never manually edit built files or inject assets post-build
 - Keep documentation and scripts in sync with the build process
 
 ---
-This file documents the context and rationale for the build modernization and should be included in the repository for onboarding and future reference. 
\ No newline at end of file
+This file documents the context and rationale for the build modernization and should be included in the repository for onboarding and future reference.
diff --git a/doc/circular-dependency-analysis.md b/doc/circular-dependency-analysis.md
index 0ae322dc..a6530e62 100644
--- a/doc/circular-dependency-analysis.md
+++ b/doc/circular-dependency-analysis.md
@@ -13,27 +13,31 @@ The codebase currently has **no active circular dependencies** that are causing
 ### 🔍 **Resolved Dependency Patterns**
 
 #### 1. **Logger → PlatformServiceFactory → Logger** (RESOLVED)
+
 - **Status**: ✅ **RESOLVED**
 - **Previous Issue**: Logger imported `logToDb` from databaseUtil, which imported logger
 - **Solution**: Logger now uses direct database access via PlatformServiceFactory
 - **Implementation**: Self-contained `logToDatabase()` function in logger.ts
 
 #### 2. **PlatformServiceMixin → databaseUtil → logger → PlatformServiceMixin** (RESOLVED)
+
 - **Status**: ✅ **RESOLVED**
 - **Previous Issue**: PlatformServiceMixin imported `memoryLogs` from databaseUtil
 - **Solution**: Created self-contained `_memoryLogs` array in PlatformServiceMixin
 - **Implementation**: Self-contained memory logs implementation
 
 #### 3. **databaseUtil → logger → PlatformServiceFactory → databaseUtil** (RESOLVED)
+
 - **Status**: ✅ **RESOLVED**
 - **Previous Issue**: databaseUtil imported logger, which could create loops
 - **Solution**: Logger is now self-contained and doesn't import from databaseUtil
 
 #### 4. **Utility Files → databaseUtil → PlatformServiceMixin** (RESOLVED)
+
 - **Status**: ✅ **RESOLVED**
 - **Previous Issue**: `src/libs/util.ts` and `src/services/deepLinks.ts` imported from databaseUtil
 - **Solution**: Replaced with self-contained implementations and PlatformServiceFactory usage
-- **Implementation**: 
+- **Implementation**:
   - Self-contained `parseJsonField()` and `mapQueryResultToValues()` functions
   - Direct PlatformServiceFactory usage for database operations
   - Console logging instead of databaseUtil logging functions
@@ -43,18 +47,21 @@ The codebase currently has **no active circular dependencies** that are causing
 ### ✅ **All Critical Dependencies Resolved**
 
 #### PlatformServiceMixin Independence
+
 - **Status**: ✅ **COMPLETE**
 - **Achievement**: PlatformServiceMixin has no external dependencies on databaseUtil
 - **Implementation**: Self-contained memory logs and utility functions
 - **Impact**: Enables complete migration of databaseUtil functions to PlatformServiceMixin
 
 #### Logger Independence
+
 - **Status**: ✅ **COMPLETE**
 - **Achievement**: Logger is completely self-contained
 - **Implementation**: Direct database access via PlatformServiceFactory
 - **Impact**: Eliminates all circular dependency risks
 
 #### Utility Files Independence
+
 - **Status**: ✅ **COMPLETE**
 - **Achievement**: All utility files no longer depend on databaseUtil
 - **Implementation**: Self-contained functions and direct platform service access
@@ -63,6 +70,7 @@ The codebase currently has **no active circular dependencies** that are causing
 ### 🎯 **Migration Readiness Status**
 
 #### Files Ready for Migration (52 files)
+
 1. **Components** (15 files):
    - `PhotoDialog.vue`
    - `FeedFilters.vue`
@@ -98,6 +106,7 @@ The codebase currently has **no active circular dependencies** that are causing
 ### 🟢 **Healthy Dependencies**
 
 #### Logger Usage (80+ files)
+
 - **Status**: ✅ **HEALTHY**
 - **Pattern**: All files import logger from `@/utils/logger`
 - **Impact**: No circular dependencies, logger is self-contained
@@ -106,21 +115,25 @@ The codebase currently has **no active circular dependencies** that are causing
 ## Resolution Strategy - COMPLETED
 
 ### ✅ **Phase 1: Complete PlatformServiceMixin Independence (COMPLETE)**
+
 1. **Removed memoryLogs import** from PlatformServiceMixin ✅
 2. **Created self-contained memoryLogs** implementation ✅
 3. **Added missing utility methods** to PlatformServiceMixin ✅
 
 ### ✅ **Phase 2: Utility Files Migration (COMPLETE)**
+
 1. **Migrated deepLinks.ts** - Replaced databaseUtil logging with console logging ✅
 2. **Migrated util.ts** - Replaced databaseUtil functions with self-contained implementations ✅
 3. **Updated all PlatformServiceFactory calls** to use async pattern ✅
 
 ### 🎯 **Phase 3: File-by-File Migration (READY TO START)**
+
 1. **High-usage files first** (views, core components)
 2. **Replace databaseUtil imports** with PlatformServiceMixin
 3. **Update function calls** to use mixin methods
 
 ### 🎯 **Phase 4: Cleanup (FUTURE)**
+
 1. **Remove unused databaseUtil functions**
 2. **Update TypeScript interfaces**
 3. **Remove databaseUtil imports** from all files
@@ -128,6 +141,7 @@ The codebase currently has **no active circular dependencies** that are causing
 ## Current Status Summary
 
 ### ✅ **Resolved Issues**
+
 1. **Logger circular dependency** - Fixed with self-contained implementation
 2. **PlatformServiceMixin circular dependency** - Fixed with self-contained memoryLogs
 3. **Utility files circular dependency** - Fixed with self-contained implementations
@@ -135,6 +149,7 @@ The codebase currently has **no active circular dependencies** that are causing
 5. **Runtime stability** - No circular dependency crashes
 
 ### 🎯 **Ready for Next Phase**
+
 1. **52 files** ready for databaseUtil migration
 2. **PlatformServiceMixin** fully independent and functional
 3. **Clear migration path** - Well-defined targets and strategy
@@ -142,6 +157,7 @@ The codebase currently has **no active circular dependencies** that are causing
 ## Benefits of Current State
 
 ### ✅ **Achieved**
+
 1. **No runtime circular dependencies** - Application runs without crashes
 2. **Self-contained logger** - No more logger/databaseUtil loops
 3. **PlatformServiceMixin ready** - All methods implemented and independent
@@ -149,6 +165,7 @@ The codebase currently has **no active circular dependencies** that are causing
 5. **Clear migration path** - Well-defined targets and strategy
 
 ### 🎯 **Expected After Migration**
+
 1. **Complete databaseUtil migration** - Single source of truth
 2. **Eliminated circular dependencies** - Clean architecture
 3. **Improved performance** - Caching and optimization
@@ -160,4 +177,4 @@ The codebase currently has **no active circular dependencies** that are causing
 **Created**: 2025-07-05
 **Status**: ✅ **COMPLETE - All Circular Dependencies Resolved**
 **Last Updated**: 2025-01-06
-**Note**: PlatformServiceMixin circular dependency completely resolved. Ready for Phase 2: File-by-File Migration 
\ No newline at end of file
+**Note**: PlatformServiceMixin circular dependency completely resolved. Ready for Phase 2: File-by-File Migration
diff --git a/doc/component-communication-guide.md b/doc/component-communication-guide.md
index 1fad5968..797e5740 100644
--- a/doc/component-communication-guide.md
+++ b/doc/component-communication-guide.md
@@ -93,6 +93,7 @@ export default class FormComponent extends Vue {
 When generating component templates, follow these patterns:
 
 #### Function Props Template
+
 ```vue
 <template>
   <div class="component-name">
@@ -124,6 +125,7 @@ export default class ComponentName extends Vue {
 ```
 
 #### $emit Template (for DOM events)
+
 ```vue
 <template>
   <div class="component-name">
@@ -155,12 +157,14 @@ export default class ComponentName extends Vue {
 ### Code Generation Rules
 
 #### 1. Function Props for Business Logic
+
 - **Data operations**: Save, delete, update, validate
 - **Navigation**: Route changes, modal opening/closing
 - **State management**: Store actions, state updates
 - **API calls**: Data fetching, form submissions
 
 #### 2. $emit for User Interactions
+
 - **Click events**: Button clicks, link navigation
 - **Form events**: Input changes, form submissions
 - **Lifecycle events**: Component mounting, unmounting
@@ -169,6 +173,7 @@ export default class ComponentName extends Vue {
 #### 3. Naming Conventions
 
 **Function Props:**
+
 ```typescript
 // Action-oriented names
 onSave: (data: SaveData) => Promise<void>
@@ -179,6 +184,7 @@ onNavigate: (route: string) => void
 ```
 
 **$emit Events:**
+
 ```typescript
 // Event-oriented names
 @click: (event: MouseEvent) => void
@@ -191,6 +197,7 @@ onNavigate: (route: string) => void
 ### TypeScript Integration
 
 #### Function Prop Types
+
 ```typescript
 // Define reusable function types
 interface SaveHandler {
@@ -207,6 +214,7 @@ interface ValidationHandler {
 ```
 
 #### Event Types
+
 ```typescript
 // Define event payload types
 interface ClickEvent {
@@ -226,6 +234,7 @@ handleClick(): ClickEvent {
 ## Testing Guidelines
 
 ### Function Props Testing
+
 ```typescript
 // Easy to mock and test
 const mockOnSave = jest.fn();
@@ -240,6 +249,7 @@ expect(mockOnSave).toHaveBeenCalledWith(expectedData);
 ```
 
 ### $emit Testing
+
 ```typescript
 // Requires event simulation
 const wrapper = mount(MyComponent);
@@ -260,6 +270,7 @@ expect(wrapper.emitted('click')).toBeTruthy();
 ### Example Migration
 
 **Before ($emit):**
+
 ```typescript
 @Emit("save")
 handleSave() {
@@ -268,6 +279,7 @@ handleSave() {
 ```
 
 **After (Function Props):**
+
 ```typescript
 @Prop({ required: true }) onSave!: (data: FormData) => void;
 
@@ -288,6 +300,7 @@ handleSave() {
 ## Code Generation Templates
 
 ### Component Generator Input
+
 ```typescript
 interface ComponentSpec {
   name: string;
@@ -306,9 +319,10 @@ interface ComponentSpec {
 ```
 
 ### Generated Output
+
 ```typescript
 // Generator should automatically choose function props vs $emit
 // based on the nature of the interaction (business logic vs DOM event)
 ```
 
-This guide ensures consistent, maintainable component communication patterns across the application. 
\ No newline at end of file
+This guide ensures consistent, maintainable component communication patterns across the application.
diff --git a/doc/cors-disabled-for-universal-images.md b/doc/cors-disabled-for-universal-images.md
index 6eb73a2c..f688b39f 100644
--- a/doc/cors-disabled-for-universal-images.md
+++ b/doc/cors-disabled-for-universal-images.md
@@ -7,10 +7,12 @@ CORS headers have been **disabled** to support Time Safari's core mission: enabl
 ## What Changed
 
 ### ❌ Removed CORS Headers
+
 - `Cross-Origin-Opener-Policy: same-origin`
 - `Cross-Origin-Embedder-Policy: require-corp`
 
 ### ✅ Results
+
 - Images from **any domain** now work in development and production
 - No proxy configuration needed
 - No whitelist of supported image hosts
@@ -19,11 +21,13 @@ CORS headers have been **disabled** to support Time Safari's core mission: enabl
 ## Technical Tradeoffs
 
 ### 🔻 Lost: SharedArrayBuffer Performance
+
 - **Before**: Fast SQLite operations via SharedArrayBuffer
 - **After**: Slightly slower IndexedDB fallback mode
 - **Impact**: Minimal for typical usage - absurd-sql automatically falls back
 
 ### 🔺 Gained: Universal Image Support
+
 - **Before**: Only specific domains worked (TimeSafari, Flickr, Imgur, etc.)
 - **After**: Any image URL works immediately
 - **Impact**: Massive improvement for user experience
@@ -31,6 +35,7 @@ CORS headers have been **disabled** to support Time Safari's core mission: enabl
 ## Architecture Impact
 
 ### Database Operations
+
 ```typescript
 // absurd-sql automatically detects SharedArrayBuffer availability
 if (typeof SharedArrayBuffer === "undefined") {
@@ -43,6 +48,7 @@ if (typeof SharedArrayBuffer === "undefined") {
 ```
 
 ### Image Loading
+
 ```typescript
 // All images load directly now
 export function transformImageUrlForCors(imageUrl: string): string {
@@ -53,11 +59,13 @@ export function transformImageUrlForCors(imageUrl: string): string {
 ## Why This Was The Right Choice
 
 ### Time Safari's Use Case
+
 - **Community platform** where users share content from anywhere
 - **User-generated content** includes images from arbitrary websites
 - **Flexibility** is more important than marginal performance gains
 
 ### Alternative Would Require
+
 - Pre-configuring proxies for every possible image hosting service
 - Constantly updating proxy list as users find new sources
 - Poor user experience when images fail to load
@@ -66,11 +74,13 @@ export function transformImageUrlForCors(imageUrl: string): string {
 ## Performance Comparison
 
 ### Database Operations
+
 - **SharedArrayBuffer**: ~2x faster for large operations
 - **IndexedDB**: Still very fast for typical Time Safari usage
 - **Real Impact**: Negligible for typical user operations
 
 ### Image Loading
+
 - **With CORS**: Many images failed to load in development
 - **Without CORS**: All images load immediately
 - **Real Impact**: Massive improvement in user experience
@@ -87,11 +97,13 @@ export function transformImageUrlForCors(imageUrl: string): string {
 ## Migration Notes
 
 ### For Developers
+
 - No code changes needed
 - `transformImageUrlForCors()` still exists but returns original URL
 - All existing image references work without modification
 
 ### For Users
+
 - Images from any website now work immediately
 - No more "image failed to load" issues in development
 - Consistent behavior between development and production
@@ -99,12 +111,14 @@ export function transformImageUrlForCors(imageUrl: string): string {
 ## Future Considerations
 
 ### If Performance Becomes Critical
+
 1. **Selective CORS**: Enable only for specific operations
 2. **Service Worker**: Handle image proxying at service worker level
 3. **Build-time Processing**: Pre-process images during build
 4. **User Education**: Guide users toward optimized image hosting
 
 ### Monitoring
+
 - Track database operation performance
 - Monitor for any user-reported slowness
 - Consider re-enabling SharedArrayBuffer if usage patterns change
@@ -113,4 +127,4 @@ export function transformImageUrlForCors(imageUrl: string): string {
 
 This change prioritizes **user experience** and **community functionality** over marginal performance gains. The database still works efficiently via IndexedDB, while images now work universally without configuration.
 
-For a community platform like Time Safari, the ability to share images from any domain is fundamental to the user experience and mission. 
\ No newline at end of file
+For a community platform like Time Safari, the ability to share images from any domain is fundamental to the user experience and mission.
diff --git a/doc/cors-image-loading-solution.md b/doc/cors-image-loading-solution.md
index 0ae689ee..c0df26ba 100644
--- a/doc/cors-image-loading-solution.md
+++ b/doc/cors-image-loading-solution.md
@@ -7,6 +7,7 @@ This document describes the implementation of a comprehensive image loading solu
 ## Problem Statement
 
 When using SharedArrayBuffer (required for absurd-sql), browsers enforce a cross-origin isolated environment with these headers:
+
 - `Cross-Origin-Opener-Policy: same-origin`
 - `Cross-Origin-Embedder-Policy: require-corp`
 
@@ -19,6 +20,7 @@ This isolation prevents loading external resources (including images) unless the
 The solution uses a multi-tier approach to handle images from various sources:
 
 #### Tier 1: Specific Domain Proxies (Development Only)
+
 - **TimeSafari Images**: `/image-proxy/` → `https://image.timesafari.app/`
 - **Flickr Images**: `/flickr-proxy/` → `https://live.staticflickr.com/`
 - **Imgur Images**: `/imgur-proxy/` → `https://i.imgur.com/`
@@ -26,14 +28,17 @@ The solution uses a multi-tier approach to handle images from various sources:
 - **Unsplash**: `/unsplash-proxy/` → `https://images.unsplash.com/`
 
 #### Tier 2: Universal CORS Proxy (Development Only)
+
 - **Any External Domain**: Uses `https://api.allorigins.win/raw?url=` for arbitrary domains
 
 #### Tier 3: Direct Loading (Production)
+
 - **Production Mode**: All images load directly without proxying
 
 ### 2. Smart URL Transformation
 
 The `transformImageUrlForCors` function automatically:
+
 - Detects the image source domain
 - Routes through appropriate proxy in development
 - Preserves original URLs in production
@@ -44,6 +49,7 @@ The `transformImageUrlForCors` function automatically:
 ### Configuration Files
 
 #### `vite.config.common.mts`
+
 ```typescript
 server: {
   headers: {
@@ -63,6 +69,7 @@ server: {
 ```
 
 #### `src/libs/util.ts`
+
 ```typescript
 export function transformImageUrlForCors(imageUrl: string): string {
   // Development mode: Transform URLs to use proxies
@@ -93,21 +100,25 @@ const imageUrl = transformImageUrlForCors(originalImageUrl);
 ## Benefits
 
 ### ✅ SharedArrayBuffer Support
+
 - Maintains cross-origin isolation required for SharedArrayBuffer
 - Enables fast SQLite database operations via absurd-sql
 - Provides better performance than IndexedDB fallback
 
 ### ✅ Universal Image Support
+
 - Handles images from any domain
 - No need to pre-configure every possible image source
 - Graceful fallback for unknown domains
 
 ### ✅ Development/Production Flexibility
+
 - Proxy system only active in development
 - Production uses direct URLs for maximum performance
 - No proxy server required in production
 
 ### ✅ Automatic Detection
+
 - Smart URL transformation based on domain patterns
 - Preserves relative URLs and data URLs
 - Handles edge cases gracefully
@@ -115,6 +126,7 @@ const imageUrl = transformImageUrlForCors(originalImageUrl);
 ## Testing
 
 ### Automated Testing
+
 Run the test suite to verify URL transformation:
 
 ```typescript
@@ -125,6 +137,7 @@ testCorsImageTransformation();
 ```
 
 ### Visual Testing
+
 Create test image elements to verify loading:
 
 ```typescript
@@ -135,6 +148,7 @@ createTestImageElements();
 ```
 
 ### Manual Testing
+
 1. Start development server: `npm run dev`
 2. Open browser console to see transformation logs
 3. Check Network tab for proxy requests
@@ -143,16 +157,19 @@ createTestImageElements();
 ## Security Considerations
 
 ### Development Environment
+
 - CORS proxies are only used in development
 - External proxy services (allorigins.win) are used for testing
 - No sensitive data is exposed through proxies
 
 ### Production Environment
+
 - All images load directly without proxying
 - No dependency on external proxy services
 - Original security model maintained
 
 ### Privacy
+
 - Image URLs are not logged or stored by proxy services
 - Proxy requests are only made during development
 - No tracking or analytics in proxy chain
@@ -160,11 +177,13 @@ createTestImageElements();
 ## Performance Impact
 
 ### Development
+
 - Slight latency from proxy requests
 - Additional network hops for external domains
 - More verbose logging for debugging
 
 ### Production
+
 - No performance impact
 - Direct image loading as before
 - No proxy overhead
@@ -174,17 +193,20 @@ createTestImageElements();
 ### Common Issues
 
 #### Images Not Loading in Development
+
 1. Check console for proxy errors
 2. Verify CORS headers are set
 3. Test with different image URLs
 4. Check network connectivity to proxy services
 
 #### SharedArrayBuffer Not Available
+
 1. Verify CORS headers are set in server configuration
 2. Check that site is served over HTTPS (or localhost)
 3. Ensure browser supports SharedArrayBuffer
 
 #### Proxy Service Unavailable
+
 1. Check if allorigins.win is accessible
 2. Consider using alternative CORS proxy services
 3. Temporarily disable CORS headers for testing
@@ -207,12 +229,14 @@ testCorsImageTransformation();
 ## Migration Guide
 
 ### From Previous Implementation
+
 1. CORS headers are now required for SharedArrayBuffer
 2. Image URLs automatically transformed in development
 3. No changes needed to existing image loading code
 4. Test thoroughly in both development and production
 
 ### Adding New Image Sources
+
 1. Add specific proxy for frequently used domains
 2. Update `transformImageUrlForCors` function
 3. Add CORS headers to proxy configuration
@@ -221,6 +245,7 @@ testCorsImageTransformation();
 ## Future Enhancements
 
 ### Possible Improvements
+
 1. **Local Proxy Server**: Run dedicated proxy server for development
 2. **Caching**: Cache proxy responses for better performance
 3. **Fallback Chain**: Multiple proxy services for reliability
@@ -228,6 +253,7 @@ testCorsImageTransformation();
 5. **Analytics**: Track image loading success/failure rates
 
 ### Alternative Approaches
+
 1. **Service Worker**: Intercept image requests at service worker level
 2. **Build-time Processing**: Pre-process images during build
 3. **CDN Integration**: Use CDN with proper CORS headers
@@ -237,4 +263,4 @@ testCorsImageTransformation();
 
 This solution provides a robust, scalable approach to image loading in a cross-origin isolated environment while maintaining the benefits of SharedArrayBuffer support. The multi-tier proxy system ensures compatibility with any image source while optimizing for performance and security.
 
-For questions or issues, refer to the troubleshooting section or consult the development team. 
\ No newline at end of file
+For questions or issues, refer to the troubleshooting section or consult the development team.
diff --git a/doc/database-migration-guide.md b/doc/database-migration-guide.md
index 00103452..f202f5ad 100644
--- a/doc/database-migration-guide.md
+++ b/doc/database-migration-guide.md
@@ -294,6 +294,7 @@ const result = await this.$db("SELECT * FROM contacts WHERE did = ?", [accountDi
 ```
 
 This provides:
+
 - **Caching**: Automatic caching for performance
 - **Error Handling**: Consistent error handling
 - **Type Safety**: Enhanced TypeScript integration
diff --git a/doc/debug-hook-guide.md b/doc/debug-hook-guide.md
index 956a21e7..fef2e269 100644
--- a/doc/debug-hook-guide.md
+++ b/doc/debug-hook-guide.md
@@ -120,6 +120,7 @@ git commit -m "test"  # Should be blocked
 ## ⚙️ Configuration
 
 Edit `.git/hooks/debug-checker.config` to customize:
+
 - **Protected branches**: Add/remove branches as needed
 - **Debug patterns**: Customize what gets detected
 - **Skip patterns**: Adjust file filtering rules
@@ -127,14 +128,17 @@ Edit `.git/hooks/debug-checker.config` to customize:
 ## 🚨 Emergency Bypass
 
 If you absolutely need to commit debug code to a protected branch:
+
 ```bash
 git commit --no-verify -m "emergency: debug code needed"
 ```
+
 ⚠️ **Warning**: This bypasses all pre-commit hooks. Use sparingly.
 
 ## 🔄 Updates
 
 When the hook is updated in the main repository:
+
 ```bash
 ./scripts/install-debug-hook.sh
 ```
@@ -170,6 +174,7 @@ A test script is available at `scripts/test-debug-hook.sh` to verify the hook wo
 ## 🎯 Team Workflow
 
 **Recommended setup:**
+
 1. **Repository setup**: Include hook files in `.githooks/` directory
 2. **Team onboarding**: Run installation script in each repo
 3. **Updates**: Re-run installation script when hooks are updated
diff --git a/doc/electron-cleanup-summary.md b/doc/electron-cleanup-summary.md
index 94b7ef5b..c904ef42 100644
--- a/doc/electron-cleanup-summary.md
+++ b/doc/electron-cleanup-summary.md
@@ -7,18 +7,22 @@ This document summarizes the comprehensive cleanup and improvements made to the
 ## Key Issues Resolved
 
 ### 1. Platform Detection Problems
+
 - **Before**: `PlatformServiceFactory` only supported "capacitor" and "web" platforms
 - **After**: Added proper "electron" platform support with dedicated `ElectronPlatformService`
 
 ### 2. Build Configuration Confusion
+
 - **Before**: Electron builds used `VITE_PLATFORM=capacitor`, causing confusion
 - **After**: Electron builds now properly use `VITE_PLATFORM=electron`
 
 ### 3. Missing Platform Service Methods
+
 - **Before**: Platform services lacked proper `isElectron()`, `isCapacitor()`, `isWeb()` methods
 - **After**: All platform services implement complete interface with proper detection
 
 ### 4. Inconsistent Build Scripts
+
 - **Before**: Mixed platform settings in build scripts
 - **After**: Clean, consistent electron-specific build process
 
@@ -215,11 +219,13 @@ if (capabilities.hasFileDownload) {
 ## File Structure Changes
 
 ### New Files
+
 - `vite.config.electron.mts` - Electron-specific Vite configuration
 - `src/main.electron.ts` - Electron main entry point
 - `doc/electron-cleanup-summary.md` - This documentation
 
 ### Modified Files
+
 - `src/services/PlatformServiceFactory.ts` - Added electron platform support
 - `src/services/PlatformService.ts` - Added platform detection methods
 - `src/services/platforms/CapacitorPlatformService.ts` - Added missing interface methods
@@ -301,4 +307,4 @@ For developers working with the previous implementation:
 - [ ] Implement desktop-specific UI components
 - [ ] Add Electron auto-updater integration
 - [ ] Create platform-specific testing utilities
-- [ ] Add desktop notification system integration 
\ No newline at end of file
+- [ ] Add desktop notification system integration
diff --git a/doc/electron-console-cleanup.md b/doc/electron-console-cleanup.md
index a979f972..ef89667c 100644
--- a/doc/electron-console-cleanup.md
+++ b/doc/electron-console-cleanup.md
@@ -7,18 +7,22 @@ This document summarizes the comprehensive changes made to reduce excessive cons
 ## Issues Addressed
 
 ### 1. Excessive Database Logging (Major Issue - 90% Reduction)
+
 **Problem:** Every database operation was logging detailed parameter information, creating hundreds of lines of console output.
 
 **Solution:** Modified `src/services/platforms/CapacitorPlatformService.ts`:
+
 - Changed `logger.warn` to `logger.debug` for routine SQL operations
-- Reduced migration logging verbosity 
+- Reduced migration logging verbosity
 - Made database integrity checks use debug-level logging
 - Kept error and completion messages at appropriate log levels
 
 ### 2. Enhanced Logger Configuration
+
 **Problem:** No platform-specific logging controls, causing noise in Electron.
 
 **Solution:** Updated `src/utils/logger.ts`:
+
 - Added platform detection for Electron vs Web
 - Suppressed debug and verbose logs for Electron
 - Filtered out routine database operations from database logging
@@ -26,28 +30,35 @@ This document summarizes the comprehensive changes made to reduce excessive cons
 - Added intelligent filtering for CapacitorPlatformService messages
 
 ### 3. API Configuration Issues (Major Fix)
+
 **Problem:** Electron was trying to use local development endpoints (localhost:3000) from saved user settings, which don't exist in desktop environment, causing:
+
 - 400 status errors from missing local development servers
 - JSON parsing errors (HTML error pages instead of JSON responses)
 
-**Solution:** 
+**Solution:**
+
 - Updated `src/constants/app.ts` to provide Electron-specific API endpoints
 - **Critical Fix:** Modified `src/db/databaseUtil.ts` in `retrieveSettingsForActiveAccount()` to force Electron to use production API endpoints regardless of saved user settings
 - This ensures Electron never uses localhost development servers that users might have saved
 
 ### 4. SharedArrayBuffer Logging Noise
+
 **Problem:** Web-specific SharedArrayBuffer detection was running in Electron, creating unnecessary debug output.
 
 **Solution:** Modified `src/main.web.ts`:
+
 - Made SharedArrayBuffer logging conditional on web platform only
 - Converted console.log statements to logger.debug
 - Only show in development mode for web platform
 - Reduced platform detection noise
 
 ### 5. Missing Source Maps Warnings
+
 **Problem:** Electron DevTools was complaining about missing source maps for external dependencies.
 
 **Solution:** Updated `vite.config.electron.mts`:
+
 - Disabled source maps for Electron builds (`sourcemap: false`)
 - Added build configuration to suppress external dependency warnings
 - Prevents DevTools from looking for non-existent source map files
@@ -87,14 +98,16 @@ This document summarizes the comprehensive changes made to reduce excessive cons
 
 ## Impact
 
-### Before Cleanup:
+### Before Cleanup
+
 - 500+ lines of console output per minute
 - Detailed SQL parameter logging for every operation
 - API connection errors every few seconds (400 status, JSON parsing errors)
 - SharedArrayBuffer warnings on every startup
 - DevTools source map warnings
 
-### After Cleanup:
+### After Cleanup
+
 - **~95% reduction** in console output
 - Only errors and important status messages visible
 - **No API connection errors** - Electron uses proper production endpoints
@@ -106,6 +119,7 @@ This document summarizes the comprehensive changes made to reduce excessive cons
 ## Technical Details
 
 ### API Configuration Fix
+
 The most critical fix was in `src/db/databaseUtil.ts` where we added:
 
 ```typescript
@@ -122,6 +136,7 @@ if (process.env.VITE_PLATFORM === "electron") {
 This ensures that even if users have localhost development endpoints saved in their settings, Electron will override them with production endpoints.
 
 ### Logger Enhancement
+
 Enhanced the logger with platform-specific behavior:
 
 ```typescript
@@ -135,6 +150,7 @@ if (!isElectron || !message.includes("[CapacitorPlatformService]")) {
 ## Testing
 
 The changes were tested with:
+
 - `npm run lint-fix` - 0 errors, warnings only (pre-existing)
 - Electron development environment
 - Web platform (unchanged functionality)
@@ -150,6 +166,7 @@ The changes were tested with:
 ## Backward Compatibility
 
 All changes maintain backward compatibility:
+
 - Web platform logging unchanged
 - Capacitor platform logging unchanged  
 - Error handling preserved
@@ -185,4 +202,4 @@ Tests: lint passes, Web/Capacitor functionality preserved
 1. **Test the fixes** - Run `npm run electron:dev` to verify console noise is eliminated
 2. **Monitor for remaining issues** - Check for any other console noise sources
 3. **Performance monitoring** - Verify the reduced logging doesn't impact functionality
-4. **Documentation updates** - Update any development guides that reference the old logging behavior 
\ No newline at end of file
+4. **Documentation updates** - Update any development guides that reference the old logging behavior
diff --git a/doc/error-diagnostics-log.md b/doc/error-diagnostics-log.md
index 0a54ba1b..78763433 100644
--- a/doc/error-diagnostics-log.md
+++ b/doc/error-diagnostics-log.md
@@ -5,9 +5,10 @@ This file tracks console errors observed during development for future investiga
 ## 2025-07-07 08:56 UTC - ProjectsView.vue Migration Session
 
 ### Migration Context
+
 - **Current Work**: Completed ProjectsView.vue Triple Migration Pattern
 - **Migration Status**: 21 complete, 4 appropriately incomplete components
-- **Recent Changes**: 
+- **Recent Changes**:
   - ProjectsView.vue: databaseUtil → PlatformServiceMixin
   - Added notification constants and literal string extraction
   - Template logic streamlining with computed properties
@@ -15,42 +16,50 @@ This file tracks console errors observed during development for future investiga
 ### Observed Errors
 
 #### 1. HomeView.vue API Rate Limit Errors
+
 ```
 GET https://api.endorser.ch/api/report/rateLimits 400 (Bad Request)
 Source: endorserServer.ts:1494, HomeView.vue:593, HomeView.vue:742
 ```
 
-**Analysis**: 
+**Analysis**:
+
 - API server returning 400 for rate limit checks
 - Occurs during identity initialization and registration status checks
 - **Migration Impact**: None - HomeView.vue was migrated and tested earlier
 - **Likely Cause**: Server-side authentication or API configuration issue
 
 **Action Items**:
+
 - [ ] Check endorser.ch API documentation for rate limit endpoint changes
 - [ ] Verify authentication headers being sent correctly
 - [ ] Consider fallback handling for rate limit API failures
 
 #### 2. ProjectViewView.vue Project Not Found Error
+
 ```
 GET https://api.endorser.ch/api/claim/byHandle/...01JY2Q5D90E8P267ABB963S71D 404 (Not Found)
 Source: ProjectViewView.vue:830 loadProject() method
 ```
 
 **Analysis**:
+
 - Attempting to load project ID: `01JY2Q5D90E8P267ABB963S71D`
 - **Migration Impact**: None - error handling working correctly
 - **Likely Cause**: User navigated to non-existent project or stale link
 
 **Action Items**:
+
 - [ ] Consider adding better user messaging for missing projects
 - [ ] Investigate if project IDs are being generated/stored correctly
 - [ ] Add breadcrumb or "return to projects" option on 404s
 
 #### 3. Axios Request Stack Traces
+
 Multiple stack traces showing Vue router navigation and component mounting cycles.
 
 **Analysis**:
+
 - Normal Vue.js lifecycle and routing behavior
 - No obvious memory leaks or infinite loops
 - **Migration Impact**: None - expected framework behavior
@@ -58,26 +67,30 @@ Multiple stack traces showing Vue router navigation and component mounting cycle
 ### System Health Indicators
 
 #### ✅ Working Correctly
+
 - Database migrations: `Migration process complete! Summary: 0 applied, 2 skipped`
 - Platform service factory initialization: `Creating singleton instance for platform: development`
 - SQL worker loading: `Worker loaded, ready to receive messages`
 - Database connection: `Opened!`
 
 #### 🔄 For Investigation
+
 - API authentication/authorization with endorser.ch
 - Project ID validation and error handling
 - Rate limiting strategy
 
 ### Migration Validation
+
 - **ProjectsView.vue**: Appropriately incomplete (3 helpers + 1 complex modal)
 - **Error Handling**: Migrated components showing proper error handling
 - **No Migration-Related Errors**: All errors appear to be infrastructure/data issues
 
 ### Next Steps
+
 1. Continue migration slog with next component
 2. Monitor these same error patterns in future sessions
 3. Address API/server issues in separate debugging session
 
 ---
 *Log Entry by: Migration Assistant*  
-*Session: ProjectsView.vue Triple Migration Pattern* 
\ No newline at end of file
+*Session: ProjectsView.vue Triple Migration Pattern*
diff --git a/doc/image-hosting-guide.md b/doc/image-hosting-guide.md
index d94ab450..1a8d1e04 100644
--- a/doc/image-hosting-guide.md
+++ b/doc/image-hosting-guide.md
@@ -25,6 +25,7 @@
 ## Why This Happens
 
 In development mode, we enable SharedArrayBuffer for fast SQLite operations, which requires:
+
 - `Cross-Origin-Opener-Policy: same-origin`
 - `Cross-Origin-Embedder-Policy: require-corp`
 
@@ -35,6 +36,7 @@ These headers create a **cross-origin isolated environment** that blocks resourc
 ### 1. Use Supported Image Hosting Services
 
 **Recommended services that work well:**
+
 - **Imgur**: Free, no registration required, direct links
 - **GitHub**: If you have images in repositories
 - **Unsplash**: For stock photos
@@ -45,6 +47,7 @@ These headers create a **cross-origin isolated environment** that blocks resourc
 If you frequently use images from a specific domain, add a proxy:
 
 #### Step 1: Add Proxy to `vite.config.common.mts`
+
 ```typescript
 '/yourservice-proxy': {
   target: 'https://yourservice.com',
@@ -63,6 +66,7 @@ If you frequently use images from a specific domain, add a proxy:
 ```
 
 #### Step 2: Update Transform Function in `src/libs/util.ts`
+
 ```typescript
 // Transform YourService URLs to use proxy
 if (imageUrl.startsWith("https://yourservice.com/")) {
@@ -74,6 +78,7 @@ if (imageUrl.startsWith("https://yourservice.com/")) {
 ### 3. Use Alternative Image Sources
 
 For frequently failing domains, consider:
+
 - Upload images to Imgur or GitHub
 - Use a CDN with proper CORS headers
 - Host images on your own domain with CORS enabled
@@ -81,11 +86,13 @@ For frequently failing domains, consider:
 ## Development vs Production
 
 ### Development Mode
+
 - Images from supported services work through proxies
 - Unsupported images may fail to load
 - Console warnings show which images have issues
 
 ### Production Mode
+
 - All images load directly without proxies
 - No CORS restrictions in production
 - Better performance without proxy overhead
@@ -93,6 +100,7 @@ For frequently failing domains, consider:
 ## Testing Image Sources
 
 ### Check if an Image Source Works
+
 ```bash
 # Test in browser console:
 fetch('https://example.com/image.jpg', { mode: 'cors' })
@@ -101,6 +109,7 @@ fetch('https://example.com/image.jpg', { mode: 'cors' })
 ```
 
 ### Visual Testing
+
 ```typescript
 import { createTestImageElements } from './libs/test-cors-images';
 createTestImageElements(); // Creates visual test panel
@@ -109,30 +118,36 @@ createTestImageElements(); // Creates visual test panel
 ## Common Error Messages
 
 ### `ERR_BLOCKED_BY_RESPONSE.NotSameOriginAfterDefaultedToSameOriginByCoep`
+
 **Cause**: Image source doesn't send required CORS headers
 **Solution**: Use a supported image hosting service or add a proxy
 
 ### `ERR_NETWORK` or `ERR_INTERNET_DISCONNECTED`
+
 **Cause**: Proxy service is unavailable
 **Solution**: Check internet connection or use alternative image source
 
 ### Images Load in Production but Not Development
+
 **Cause**: Normal behavior - development has stricter CORS requirements
 **Solution**: Use supported image sources for development testing
 
 ## Best Practices
 
 ### For New Projects
+
 1. Use supported image hosting services from the start
 2. Upload user images to Imgur or similar service
 3. Host critical images on your own domain with CORS enabled
 
 ### For Existing Projects
+
 1. Identify frequently used image domains in console warnings
 2. Add proxies for the most common domains
 3. Gradually migrate to supported image hosting services
 
 ### For User-Generated Content
+
 1. Provide upload functionality to supported services
 2. Validate image URLs against supported domains
 3. Show helpful error messages for unsupported sources
@@ -140,17 +155,20 @@ createTestImageElements(); // Creates visual test panel
 ## Troubleshooting
 
 ### Image Not Loading?
+
 1. Check browser console for error messages
 2. Verify the domain is in the supported list
 3. Test if the image loads in production mode
 4. Consider adding a proxy for that domain
 
 ### Proxy Not Working?
+
 1. Check if the target service allows proxying
 2. Verify CORS headers are being set correctly
 3. Test with a simpler image URL from the same domain
 
 ### Performance Issues?
+
 1. Proxies add latency in development only
 2. Production uses direct image loading
 3. Consider using a local image cache for development
@@ -158,6 +176,7 @@ createTestImageElements(); // Creates visual test panel
 ## Quick Fixes
 
 ### For Immediate Issues
+
 ```typescript
 // Temporary fallback: disable CORS headers for testing
 // In vite.config.common.mts, comment out:
@@ -166,9 +185,11 @@ createTestImageElements(); // Creates visual test panel
 //   'Cross-Origin-Embedder-Policy': 'require-corp'
 // },
 ```
+
 **Note**: This disables SharedArrayBuffer performance benefits.
 
 ### For Long-term Solution
+
 - Use supported image hosting services
 - Add proxies for frequently used domains
 - Migrate critical images to your own CORS-enabled CDN
@@ -177,4 +198,4 @@ createTestImageElements(); // Creates visual test panel
 
 The cross-origin isolated environment is necessary for SharedArrayBuffer performance but requires careful image source management. Use the supported services, add proxies for common domains, and accept that some external images may not work in development mode.
 
-This is a development-only limitation - production deployments work with any image source. 
\ No newline at end of file
+This is a development-only limitation - production deployments work with any image source.
diff --git a/doc/logging-configuration.md b/doc/logging-configuration.md
index 2ef2a6d2..f0e14e9e 100644
--- a/doc/logging-configuration.md
+++ b/doc/logging-configuration.md
@@ -101,6 +101,7 @@ Database logging continues to work regardless of console log level settings. All
 ### No Logs Appearing
 
 Check your `VITE_LOG_LEVEL` setting:
+
 ```bash
 echo $VITE_LOG_LEVEL
 ```
@@ -108,6 +109,7 @@ echo $VITE_LOG_LEVEL
 ### Too Many Logs
 
 Reduce verbosity by setting a lower log level:
+
 ```bash
 VITE_LOG_LEVEL=warn
 ```
diff --git a/doc/migration-fence-definition.md b/doc/migration-fence-definition.md
index fe0d7f5a..14341f6e 100644
--- a/doc/migration-fence-definition.md
+++ b/doc/migration-fence-definition.md
@@ -9,6 +9,7 @@ This document defines the **migration fence** - the boundary between the legacy
 ## Current Migration Status
 
 ### ✅ Completed Components
+
 - **SQLite Database Service**: Fully implemented with absurd-sql
 - **Platform Service Layer**: Unified database interface across platforms
 - **PlatformServiceMixin**: Centralized database access with caching and utilities
@@ -17,12 +18,14 @@ This document defines the **migration fence** - the boundary between the legacy
 - **Data Export/Import**: Backup and restore functionality
 
 ### 🔄 Active Migration Components
+
 - **Settings Migration**: Core user settings transferred
 - **Account Migration**: Identity and key management
 - **Contact Migration**: User contact data (via import interface)
 - **DatabaseUtil Migration**: Moving functions to PlatformServiceMixin
 
 ### ❌ Legacy Components (Fence Boundary)
+
 - **Dexie Database**: Legacy IndexedDB storage (disabled by default)
 - **Dexie-Specific Code**: Direct database access patterns
 - **Legacy Migration Paths**: Old data transfer methods
@@ -45,6 +48,7 @@ export const PlatformServiceMixin = {
 ```
 
 **Fence Rule**: All database operations must use:
+
 - `this.$db()` for read operations
 - `this.$exec()` for write operations
 - `this.$settings()` for settings access
@@ -64,6 +68,7 @@ export class PlatformServiceFactory {
 ```
 
 **Fence Rule**: All database operations must use:
+
 - `PlatformService.dbQuery()` for read operations
 - `PlatformService.dbExec()` for write operations
 - No direct `db.` or `accountsDBPromise` access in application code
@@ -71,6 +76,7 @@ export class PlatformServiceFactory {
 ### 3. Data Access Patterns
 
 #### ✅ Allowed (Inside Fence)
+
 ```typescript
 // Use PlatformServiceMixin for all database operations
 const contacts = await this.$contacts();
@@ -79,6 +85,7 @@ const result = await this.$db("SELECT * FROM contacts WHERE did = ?", [accountDi
 ```
 
 #### ❌ Forbidden (Outside Fence)
+
 ```typescript
 // Direct Dexie access (legacy pattern)
 const contacts = await db.contacts.where('did').equals(accountDid).toArray();
@@ -98,6 +105,7 @@ export async function compareDatabases(): Promise<DataComparison> {
 ```
 
 **Fence Rule**: Migration tools are the exclusive interface between:
+
 - Legacy Dexie database
 - New SQLite database
 - Data comparison and transfer operations
@@ -107,11 +115,13 @@ export async function compareDatabases(): Promise<DataComparison> {
 ### 1. Code Development Rules
 
 #### New Feature Development
+
 - **Always** use `PlatformServiceMixin` for database operations
 - **Never** import or reference Dexie directly
 - **Always** use mixin methods like `this.$settings()`, `this.$contacts()`
 
 #### Legacy Code Maintenance
+
 - **Only** modify Dexie code for migration purposes
 - **Always** add migration tests for schema changes
 - **Never** add new Dexie-specific features
@@ -119,11 +129,13 @@ export async function compareDatabases(): Promise<DataComparison> {
 ### 2. Data Integrity Rules
 
 #### Migration Safety
+
 - **Always** create backups before migration
 - **Always** verify data integrity after migration
 - **Never** delete legacy data until verified
 
 #### Rollback Strategy
+
 - **Always** maintain ability to rollback to Dexie
 - **Always** preserve migration logs
 - **Never** assume migration is irreversible
@@ -131,6 +143,7 @@ export async function compareDatabases(): Promise<DataComparison> {
 ### 3. Testing Requirements
 
 #### Migration Testing
+
 ```typescript
 // Required test pattern for migration
 describe('Database Migration', () => {
@@ -144,6 +157,7 @@ describe('Database Migration', () => {
 ```
 
 #### Application Testing
+
 ```typescript
 // Required test pattern for application features
 describe('Feature with Database', () => {
@@ -159,6 +173,7 @@ describe('Feature with Database', () => {
 ### 1. Static Analysis
 
 #### ESLint Rules
+
 ```json
 {
   "rules": {
@@ -178,6 +193,7 @@ describe('Feature with Database', () => {
 ```
 
 #### TypeScript Rules
+
 ```json
 {
   "compilerOptions": {
@@ -190,6 +206,7 @@ describe('Feature with Database', () => {
 ### 2. Runtime Checks
 
 #### Development Mode Validation
+
 ```typescript
 // Development-only fence validation
 if (import.meta.env.DEV) {
@@ -198,6 +215,7 @@ if (import.meta.env.DEV) {
 ```
 
 #### Production Safety
+
 ```typescript
 // Production fence enforcement
 if (import.meta.env.PROD) {
@@ -209,6 +227,7 @@ if (import.meta.env.PROD) {
 ## Migration Status Checklist
 
 ### ✅ Completed
+
 - [x] PlatformServiceMixin implementation
 - [x] SQLite database service
 - [x] Migration tools
@@ -217,11 +236,13 @@ if (import.meta.env.PROD) {
 - [x] ActiveDid migration
 
 ### 🔄 In Progress
+
 - [ ] Contact migration
 - [ ] DatabaseUtil to PlatformServiceMixin migration
 - [ ] File-by-file migration
 
 ### ❌ Not Started
+
 - [ ] Legacy Dexie removal
 - [ ] Final cleanup and validation
 
@@ -240,4 +261,4 @@ if (import.meta.env.PROD) {
 **Created**: 2025-07-05
 **Status**: Active Migration Phase
 **Last Updated**: 2025-07-05
-**Note**: Migration fence now implemented through PlatformServiceMixin instead of USE_DEXIE_DB constant 
\ No newline at end of file
+**Note**: Migration fence now implemented through PlatformServiceMixin instead of USE_DEXIE_DB constant
diff --git a/doc/migration-progress-tracker.md b/doc/migration-progress-tracker.md
index 41c2c592..63c190d7 100644
--- a/doc/migration-progress-tracker.md
+++ b/doc/migration-progress-tracker.md
@@ -3,6 +3,7 @@
 ## Per-File Migration Workflow (MANDATORY)
 
 For each file migrated:
+
 1. **First**, migrate to PlatformServiceMixin (replace all databaseUtil usage, etc.).
 2. **Immediately after**, standardize notify helper usage (property + created() pattern) and fix any related linter/type errors.
 
@@ -25,22 +26,26 @@ This document tracks the progress of the 2-day sprint to complete PlatformServic
 ## ✅ **DAY 1: PlatformServiceMixin Completion (COMPLETE)**
 
 ### **Phase 1: Remove Circular Dependency (COMPLETE)**
+
 **Status**: ✅ **COMPLETE**
 **Issue**: PlatformServiceMixin imports `memoryLogs` from databaseUtil
 **Solution**: Create self-contained memoryLogs implementation
 
-#### **Tasks**:
+#### **Tasks**
+
 - [x] **Step 1.1**: Remove `memoryLogs` import from PlatformServiceMixin.ts ✅
 - [x] **Step 1.2**: Add self-contained `_memoryLogs` array to PlatformServiceMixin ✅
 - [x] **Step 1.3**: Add `$appendToMemoryLogs()` method to PlatformServiceMixin ✅
 - [x] **Step 1.4**: Update logger.ts to use self-contained memoryLogs ✅
 - [x] **Step 1.5**: Test memoryLogs functionality ✅
 
-#### **Files Modified**:
+#### **Files Modified**
+
 - `src/utils/PlatformServiceMixin.ts` ✅
 - `src/utils/logger.ts` ✅
 
-#### **Validation**:
+#### **Validation**
+
 - [x] No circular dependency errors ✅
 - [x] memoryLogs functionality works correctly ✅
 - [x] Linting passes ✅
@@ -48,20 +53,24 @@ This document tracks the progress of the 2-day sprint to complete PlatformServic
 ---
 
 ### **Phase 2: Add Missing Utility Functions (COMPLETE)**
+
 **Status**: ✅ **COMPLETE**
 **Missing Functions**: `generateInsertStatement`, `generateUpdateStatement`
 
-#### **Tasks**:
+#### **Tasks**
+
 - [x] **Step 2.1**: Add `_generateInsertStatement()` private method to PlatformServiceMixin ✅
 - [x] **Step 2.2**: Add `_generateUpdateStatement()` private method to PlatformServiceMixin ✅
 - [x] **Step 2.3**: Add `$generateInsertStatement()` public wrapper method ✅
 - [x] **Step 2.4**: Add `$generateUpdateStatement()` public wrapper method ✅
 - [x] **Step 2.5**: Test both utility functions ✅
 
-#### **Files Modified**:
+#### **Files Modified**
+
 - `src/utils/PlatformServiceMixin.ts` ✅
 
-#### **Validation**:
+#### **Validation**
+
 - [x] Both functions generate correct SQL ✅
 - [x] Parameter handling works correctly ✅
 - [x] Type safety maintained ✅
@@ -69,18 +78,22 @@ This document tracks the progress of the 2-day sprint to complete PlatformServic
 ---
 
 ### **Phase 3: Update Type Definitions (COMPLETE)**
+
 **Status**: ✅ **COMPLETE**
 **Goal**: Add new methods to TypeScript interfaces
 
-#### **Tasks**:
+#### **Tasks**
+
 - [x] **Step 3.1**: Add new methods to `IPlatformServiceMixin` interface ✅
 - [x] **Step 3.2**: Add new methods to `ComponentCustomProperties` interface ✅
 - [x] **Step 3.3**: Verify TypeScript compilation ✅
 
-#### **Files Modified**:
+#### **Files Modified**
+
 - `src/utils/PlatformServiceMixin.ts` (interface definitions) ✅
 
-#### **Validation**:
+#### **Validation**
+
 - [x] TypeScript compilation passes ✅
 - [x] All new methods properly typed ✅
 - [x] No type errors in existing code ✅
@@ -88,17 +101,20 @@ This document tracks the progress of the 2-day sprint to complete PlatformServic
 ---
 
 ### **Phase 4: Testing & Validation (COMPLETE)**
+
 **Status**: ✅ **COMPLETE**
 **Goal**: Ensure PlatformServiceMixin is fully functional
 
-#### **Tasks**:
+#### **Tasks**
+
 - [x] **Step 4.1**: Create test component to verify all methods ✅
 - [x] **Step 4.2**: Run comprehensive linting ✅
 - [x] **Step 4.3**: Run TypeScript type checking ✅
 - [x] **Step 4.4**: Test caching functionality ✅
 - [x] **Step 4.5**: Test database operations ✅
 
-#### **Validation**:
+#### **Validation**
+
 - [x] All tests pass ✅
 - [x] No linting errors ✅
 - [x] No TypeScript errors ✅
@@ -108,10 +124,12 @@ This document tracks the progress of the 2-day sprint to complete PlatformServic
 ---
 
 ### **Phase 5: Utility Files Migration (COMPLETE)**
+
 **Status**: ✅ **COMPLETE**
 **Goal**: Remove all remaining databaseUtil imports from utility files
 
-#### **Tasks**:
+#### **Tasks**
+
 - [x] **Step 5.1**: Migrate `src/services/deepLinks.ts` ✅
   - Replaced `logConsoleAndDb` with `console.error`
   - Removed databaseUtil import
@@ -121,7 +139,8 @@ This document tracks the progress of the 2-day sprint to complete PlatformServic
   - Updated all async calls to use proper async pattern
 - [x] **Step 5.3**: Verify no remaining databaseUtil imports ✅
 
-#### **Validation**:
+#### **Validation**
+
 - [x] No databaseUtil imports in any TypeScript files ✅
 - [x] No databaseUtil imports in any Vue files ✅
 - [x] All functions work correctly ✅
@@ -131,13 +150,16 @@ This document tracks the progress of the 2-day sprint to complete PlatformServic
 ## 🎯 **DAY 2: Migrate All 52 Files (READY TO START)**
 
 ### **Migration Strategy**
+
 **Priority Order**:
+
 1. **Views** (25 files) - User-facing components
 2. **Components** (15 files) - Reusable UI components  
 3. **Services** (8 files) - Business logic
 4. **Utils** (4 files) - Utility functions
 
 ### **Migration Pattern for Each File**
+
 ```typescript
 // 1. Add PlatformServiceMixin
 import { PlatformServiceMixin } from "@/utils/PlatformServiceMixin";
@@ -155,6 +177,7 @@ export default class ComponentName extends Vue {
 ```
 
 ### **Common Replacements**
+
 - `generateInsertStatement` → `this.$generateInsertStatement`
 - `generateUpdateStatement` → `this.$generateUpdateStatement`
 - `parseJsonField` → `this._parseJsonField`
@@ -168,6 +191,7 @@ export default class ComponentName extends Vue {
 ## 📋 **File Migration Checklist**
 
 ### **Views (25 files) - Priority 1**
+
 **Progress**: 6/25 (24%)
 
 - [ ] QuickActionBvcEndView.vue
@@ -209,6 +233,7 @@ export default class ComponentName extends Vue {
 - [ ] UserProfileView.vue
 
 ### **Components (15 files) - Priority 2**
+
 **Progress**: 9/15 (60%)
 
 - [x] UserNameDialog.vue ✅ **MIGRATED**
@@ -233,6 +258,7 @@ export default class ComponentName extends Vue {
 - [x] IconRenderer.vue ✅ MIGRATED & HUMAN TESTED 2024-12-19 (0 min, no migration needed - already compliant)
 
 ### **Services (8 files) - Priority 3**
+
 **Progress**: 2/8 (25%)
 
 - [x] api.ts ✅ MIGRATED 2024-12-19 (0 min, no migration needed - already compliant)
@@ -241,6 +267,7 @@ export default class ComponentName extends Vue {
 - [ ] deepLinks.ts
 
 ### **Utils (4 files) - Priority 4**
+
 **Progress**: 1/4 (25%)
 
 - [ ] LogCollector.ts
@@ -253,6 +280,7 @@ export default class ComponentName extends Vue {
 ## 🛠️ **Migration Tools**
 
 ### **Migration Helper Script**
+
 ```bash
 # Track progress
 ./scripts/migration-helper.sh progress
@@ -277,6 +305,7 @@ export default class ComponentName extends Vue {
 ```
 
 ### **Validation Commands**
+
 ```bash
 # Check for remaining databaseUtil imports
 find src -name "*.vue" -o -name "*.ts" | xargs grep -l "import.*databaseUtil"
@@ -296,12 +325,14 @@ find src -name "*.vue" -o -name "*.ts" | xargs grep -l "import.*databaseUtil" |
 ## 📊 **Progress Tracking**
 
 ### **Day 1 Progress**
+
 - [ ] Phase 1: Circular dependency resolved
 - [ ] Phase 2: Utility functions added
 - [ ] Phase 3: Type definitions updated
 - [ ] Phase 4: Testing completed
 
 ### **Day 2 Progress**
+
 - [ ] Views migrated (0/25)
 - [ ] Components migrated (0/15)
 - [ ] Services migrated (0/8)
@@ -309,6 +340,7 @@ find src -name "*.vue" -o -name "*.ts" | xargs grep -l "import.*databaseUtil" |
 - [ ] Validation completed
 
 ### **Overall Progress**
+
 - **Total files to migrate**: 52
 - **Files migrated**: 3
 - **Progress**: 6%
@@ -318,6 +350,7 @@ find src -name "*.vue" -o -name "*.ts" | xargs grep -l "import.*databaseUtil" |
 ## 🎯 **Success Criteria**
 
 ### **Day 1 Success Criteria**
+
 - [ ] PlatformServiceMixin has no circular dependencies
 - [ ] All utility functions implemented and tested
 - [ ] Type definitions complete and accurate
@@ -325,6 +358,7 @@ find src -name "*.vue" -o -name "*.ts" | xargs grep -l "import.*databaseUtil" |
 - [ ] TypeScript compilation passes
 
 ### **Day 2 Success Criteria**
+
 - [ ] 0 files importing databaseUtil
 - [ ] All 52 files migrated to PlatformServiceMixin
 - [ ] No runtime errors in migrated components
@@ -332,6 +366,7 @@ find src -name "*.vue" -o -name "*.ts" | xargs grep -l "import.*databaseUtil" |
 - [ ] Performance maintained or improved
 
 ### **Overall Success Criteria**
+
 - [ ] Complete elimination of databaseUtil dependency
 - [ ] PlatformServiceMixin is the single source of truth for database operations
 - [ ] Migration fence is fully implemented
@@ -354,14 +389,17 @@ find src -name "*.vue" -o -name "*.ts" | xargs grep -l "import.*databaseUtil" |
 ## 📝 **Notes & Issues**
 
 ### **Current Issues**
+
 - None identified yet
 
 ### **Decisions Made**
+
 - PlatformServiceMixin approach chosen over USE_DEXIE_DB constant
 - Self-contained utility functions preferred over imports
 - Priority order: Views → Components → Services → Utils
 
 ### **Lessons Learned**
+
 - To be filled as migration progresses
 
 ---
@@ -369,6 +407,7 @@ find src -name "*.vue" -o -name "*.ts" | xargs grep -l "import.*databaseUtil" |
 ## 🔄 **Daily Updates**
 
 ### **Day 1 Updates**
+
 - [ ] Start time: _____
 - [ ] Phase 1 completion: _____
 - [ ] Phase 2 completion: _____
@@ -377,6 +416,7 @@ find src -name "*.vue" -o -name "*.ts" | xargs grep -l "import.*databaseUtil" |
 - [ ] End time: _____
 
 ### **Day 2 Updates**
+
 - [ ] Start time: _____
 - [ ] Views migration completion: _____
 - [ ] Components migration completion: _____
@@ -390,16 +430,19 @@ find src -name "*.vue" -o -name "*.ts" | xargs grep -l "import.*databaseUtil" |
 ## 🆘 **Contingency Plans**
 
 ### **If Day 1 Takes Longer**
+
 - Focus on core functionality first
 - Defer advanced utility functions to Day 2
 - Prioritize circular dependency resolution
 
 ### **If Day 2 Takes Longer**
+
 - Focus on high-impact views first
 - Batch similar components together
 - Use automated scripts for common patterns
 
 ### **If Issues Arise**
+
 - Document specific problems in Notes section
 - Create targeted fixes
 - Maintain backward compatibility during transition
@@ -421,4 +464,4 @@ These practices ensure maintainability, consistency, and type safety for all not
 ---
 
 **Last Updated**: $(date)
-**Next Review**: After each phase completion 
\ No newline at end of file
+**Next Review**: After each phase completion
diff --git a/doc/migration-quick-reference.md b/doc/migration-quick-reference.md
index 5f84bfaa..3e77dc8a 100644
--- a/doc/migration-quick-reference.md
+++ b/doc/migration-quick-reference.md
@@ -63,6 +63,7 @@ export default class ComponentName extends Vue {
 ## ✅ **Validation Checklist**
 
 After each file migration:
+
 - [ ] No databaseUtil imports
 - [ ] PlatformServiceMixin added
 - [ ] Method calls updated
@@ -91,4 +92,4 @@ npm run lint && npx tsc --noEmit
 ---
 
 **Last Updated**: $(date)
-**Full Documentation**: `doc/migration-progress-tracker.md` 
\ No newline at end of file
+**Full Documentation**: `doc/migration-progress-tracker.md`
diff --git a/doc/migration-readiness-summary.md b/doc/migration-readiness-summary.md
index a743257c..6797b0d7 100644
--- a/doc/migration-readiness-summary.md
+++ b/doc/migration-readiness-summary.md
@@ -11,11 +11,14 @@
 ## 🎯 **Migration Overview**
 
 ### **Goal**
+
 Complete the TimeSafari database migration from Dexie to SQLite by:
+
 1. **Day 1**: Finish PlatformServiceMixin implementation (4-6 hours)
 2. **Day 2**: Migrate all 52 files to PlatformServiceMixin (6-8 hours)
 
 ### **Current Status**
+
 - ✅ **PlatformServiceMixin**: 95% complete (1,301 lines)
 - ✅ **Migration Tools**: Ready and tested
 - ✅ **Documentation**: Complete and cross-machine accessible
@@ -27,22 +30,30 @@ Complete the TimeSafari database migration from Dexie to SQLite by:
 ## 📊 **File Breakdown**
 
 ### **Views (42 files) - Priority 1**
+
 User-facing components that need immediate attention:
+
 - 25 files from original list
 - 17 additional files identified by migration helper
 
 ### **Components (9 files) - Priority 2**
+
 Reusable UI components:
+
 - FeedFilters.vue, GiftedDialog.vue, GiftedPrompts.vue
 - ImageMethodDialog.vue, OfferDialog.vue, OnboardingDialog.vue
 - PhotoDialog.vue, PushNotificationPermission.vue, UserNameDialog.vue
 
 ### **Services (1 file) - Priority 3**
+
 Business logic:
+
 - deepLinks.ts
 
 ### **Utils (3 files) - Priority 4**
+
 Utility functions:
+
 - util.ts, test/index.ts, PlatformServiceMixin.ts (circular dependency fix)
 
 ---
@@ -50,17 +61,21 @@ Utility functions:
 ## 🛠️ **Available Tools**
 
 ### **Migration Helper Script**
+
 ```bash
 ./scripts/migration-helper.sh [command]
 ```
+
 **Commands**: progress, files, patterns, template, validate, next, all
 
 ### **Progress Tracking**
+
 - **Main Tracker**: `doc/migration-progress-tracker.md`
 - **Quick Reference**: `doc/migration-quick-reference.md`
 - **Completion Plan**: `doc/platformservicemixin-completion-plan.md`
 
 ### **Validation Commands**
+
 ```bash
 # Check progress
 ./scripts/migration-helper.sh progress
@@ -77,6 +92,7 @@ find src -name "*.vue" -o -name "*.ts" | xargs grep -l "import.*databaseUtil" |
 ## 🔄 **Migration Pattern**
 
 ### **Standard Template**
+
 ```typescript
 // 1. Add import
 import { PlatformServiceMixin } from "@/utils/PlatformServiceMixin";
@@ -94,6 +110,7 @@ export default class ComponentName extends Vue {
 ```
 
 ### **Common Replacements**
+
 | Old | New |
 |-----|-----|
 | `generateInsertStatement` | `this.$generateInsertStatement` |
@@ -109,19 +126,23 @@ export default class ComponentName extends Vue {
 ## 🎯 **Day 1 Plan: PlatformServiceMixin Completion**
 
 ### **Phase 1: Remove Circular Dependency (30 min)**
+
 - Remove `memoryLogs` import from PlatformServiceMixin
 - Add self-contained memoryLogs implementation
 - Update logger.ts
 
 ### **Phase 2: Add Missing Functions (1 hour)**
+
 - Add `generateInsertStatement` and `generateUpdateStatement`
 - Test both utility functions
 
 ### **Phase 3: Update Types (30 min)**
+
 - Add new methods to TypeScript interfaces
 - Verify compilation
 
 ### **Phase 4: Testing (1 hour)**
+
 - Comprehensive testing and validation
 - Ensure no circular dependencies
 
@@ -130,17 +151,20 @@ export default class ComponentName extends Vue {
 ## 🎯 **Day 2 Plan: File Migration**
 
 ### **Strategy**
+
 1. **Views First** (42 files) - High impact, user-facing
 2. **Components** (9 files) - Reusable UI elements
 3. **Services** (1 file) - Business logic
 4. **Utils** (3 files) - Utility functions
 
 ### **Batch Processing**
+
 - Process similar files together
 - Use automated scripts for common patterns
 - Validate after each batch
 
 ### **Success Criteria**
+
 - 0 files importing databaseUtil
 - All tests passing
 - No runtime errors
@@ -151,12 +175,14 @@ export default class ComponentName extends Vue {
 ## 🚀 **Expected Benefits**
 
 ### **Immediate Benefits**
+
 - **80% reduction** in database boilerplate code
 - **Eliminated circular dependencies**
 - **Centralized caching** for performance
 - **Type-safe** database operations
 
 ### **Long-term Benefits**
+
 - **Simplified testing** with mockable mixin
 - **Consistent error handling** across components
 - **Ready for SQLite-only mode**
@@ -167,18 +193,21 @@ export default class ComponentName extends Vue {
 ## 📋 **Pre-Migration Checklist**
 
 ### **Environment Ready**
+
 - [x] Migration helper script tested and working
 - [x] Progress tracking system operational
 - [x] Documentation complete and accessible
 - [x] Validation commands working
 
 ### **Tools Available**
+
 - [x] Automated progress tracking
 - [x] Migration pattern templates
 - [x] Validation scripts
 - [x] Cross-machine documentation
 
 ### **Knowledge Base**
+
 - [x] Common replacement patterns documented
 - [x] Migration templates ready
 - [x] Troubleshooting guides available
@@ -191,12 +220,14 @@ export default class ComponentName extends Vue {
 **All systems are ready for the 2-day migration sprint.**
 
 ### **Next Steps**
+
 1. **Start Day 1**: Complete PlatformServiceMixin
 2. **Use tracking tools**: Monitor progress with helper script
 3. **Follow documentation**: Use provided templates and patterns
 4. **Validate frequently**: Run checks after each phase
 
 ### **Success Metrics**
+
 - **Day 1**: PlatformServiceMixin 100% complete, no circular dependencies
 - **Day 2**: 0 files importing databaseUtil, all tests passing
 - **Overall**: Ready for Phase 3 cleanup and optimization
@@ -210,4 +241,4 @@ export default class ComponentName extends Vue {
 ---
 
 **Last Updated**: $(date)
-**Next Review**: After Day 1 completion 
\ No newline at end of file
+**Next Review**: After Day 1 completion
diff --git a/doc/migration-roadmap-next-steps.md b/doc/migration-roadmap-next-steps.md
index 995308d8..994d67c1 100644
--- a/doc/migration-roadmap-next-steps.md
+++ b/doc/migration-roadmap-next-steps.md
@@ -7,6 +7,7 @@ This document outlines the immediate next steps for completing the TimeSafari da
 ## Current Status Summary
 
 ### ✅ **Completed Achievements**
+
 1. **Circular Dependencies Resolved** - No active circular dependencies blocking development
 2. **PlatformServiceMixin Implemented** - Core functionality with caching and utilities
 3. **Migration Tools Ready** - Data comparison and transfer utilities functional
@@ -14,6 +15,7 @@ This document outlines the immediate next steps for completing the TimeSafari da
 5. **Documentation Updated** - All docs reflect current PlatformServiceMixin approach
 
 ### 🔄 **Current Phase: Phase 2 - Active Migration**
+
 - **DatabaseUtil Migration**: 52 files still importing databaseUtil
 - **Contact Migration**: Framework ready, implementation in progress
 - **File-by-File Migration**: Ready to begin systematic migration
@@ -23,6 +25,7 @@ This document outlines the immediate next steps for completing the TimeSafari da
 ### 🔴 **Priority 1: Complete PlatformServiceMixin Independence**
 
 #### **Step 1.1: Remove memoryLogs Dependency**
+
 ```typescript
 // Current: PlatformServiceMixin imports from databaseUtil
 import { memoryLogs } from "@/db/databaseUtil";
@@ -32,12 +35,15 @@ const memoryLogs: string[] = [];
 ```
 
 **Files to modify**:
+
 - `src/utils/PlatformServiceMixin.ts` - Remove import, add self-contained implementation
 
 **Estimated time**: 30 minutes
 
 #### **Step 1.2: Add Missing Utility Methods**
+
 Add these methods to PlatformServiceMixin:
+
 - `$parseJson()` - Self-contained JSON parsing
 - `$generateInsertStatement()` - SQL generation
 - `$generateUpdateStatement()` - SQL generation
@@ -48,6 +54,7 @@ Add these methods to PlatformServiceMixin:
 ### 🟡 **Priority 2: Start File-by-File Migration**
 
 #### **Step 2.1: Migrate Critical Files First**
+
 Based on the migration plan, start with these high-priority files:
 
 1. **`src/App.vue`** - Main application (highest impact)
@@ -57,6 +64,7 @@ Based on the migration plan, start with these high-priority files:
 5. **`src/services/deepLinks.ts`** - Service layer
 
 **Migration pattern for each file**:
+
 ```typescript
 // 1. Remove databaseUtil import
 // Remove: import * as databaseUtil from "../db/databaseUtil";
@@ -82,7 +90,9 @@ Based on the migration plan, start with these high-priority files:
 ### 🟡 **Priority 3: Systematic File Migration**
 
 #### **Step 3.1: Migrate High-Usage Components (15 files)**
+
 Target components with databaseUtil imports:
+
 - `PhotoDialog.vue`
 - `FeedFilters.vue`
 - `UserNameDialog.vue`
@@ -97,7 +107,9 @@ Target components with databaseUtil imports:
 **Estimated time**: 15-30 hours
 
 #### **Step 3.2: Migrate High-Usage Views (20 files)**
+
 Target views with databaseUtil imports:
+
 - `IdentitySwitcherView.vue`
 - `ContactEditView.vue`
 - `ContactGiftingView.vue`
@@ -113,6 +125,7 @@ Target views with databaseUtil imports:
 **Estimated time**: 20-40 hours
 
 #### **Step 3.3: Migrate Remaining Files (27 files)**
+
 Complete migration of all remaining files with databaseUtil imports.
 
 **Estimated time**: 27-54 hours
@@ -120,6 +133,7 @@ Complete migration of all remaining files with databaseUtil imports.
 ### 🟢 **Priority 4: Contact Migration Completion**
 
 #### **Step 4.1: Complete Contact Migration Framework**
+
 - Implement contact import/export functionality
 - Add contact validation and error handling
 - Test contact migration with real data
@@ -127,6 +141,7 @@ Complete migration of all remaining files with databaseUtil imports.
 **Estimated time**: 4-8 hours
 
 #### **Step 4.2: User Testing and Validation**
+
 - Test migration with various data scenarios
 - Validate data integrity after migration
 - Performance testing with large datasets
@@ -138,7 +153,9 @@ Complete migration of all remaining files with databaseUtil imports.
 ### 🔵 **Priority 5: Cleanup and Optimization**
 
 #### **Step 5.1: Remove Unused databaseUtil Functions**
+
 After all files are migrated:
+
 - Remove unused functions from databaseUtil.ts
 - Update TypeScript interfaces
 - Clean up legacy code
@@ -146,6 +163,7 @@ After all files are migrated:
 **Estimated time**: 4-8 hours
 
 #### **Step 5.2: Performance Optimization**
+
 - Optimize PlatformServiceMixin caching
 - Add performance monitoring
 - Implement database query optimization
@@ -153,6 +171,7 @@ After all files are migrated:
 **Estimated time**: 8-16 hours
 
 #### **Step 5.3: Legacy Dexie Removal**
+
 - Remove Dexie dependencies
 - Clean up migration tools
 - Update build configurations
@@ -162,6 +181,7 @@ After all files are migrated:
 ## Migration Commands and Tools
 
 ### **Automated Migration Script**
+
 Create a script to help with bulk migrations:
 
 ```bash
@@ -193,6 +213,7 @@ echo "Please review and test the changes"
 ```
 
 ### **Migration Testing Commands**
+
 ```bash
 # Test individual file migration
 npm run test -- --grep "ComponentName"
@@ -213,18 +234,21 @@ npx tsc --noEmit
 ## Risk Mitigation
 
 ### **Incremental Migration Strategy**
+
 1. **One file at a time** - Minimize risk of breaking changes
 2. **Comprehensive testing** - Test each migration thoroughly
 3. **Rollback capability** - Keep databaseUtil.ts until migration complete
 4. **Documentation updates** - Update docs as methods are migrated
 
 ### **Testing Strategy**
+
 1. **Unit tests** - Test individual component functionality
 2. **Integration tests** - Test database operations
 3. **End-to-end tests** - Test complete user workflows
 4. **Performance tests** - Ensure no performance regression
 
 ### **Rollback Plan**
+
 1. **Git branches** - Each migration in separate branch
 2. **Backup files** - Keep original files until migration verified
 3. **Feature flags** - Ability to switch back to databaseUtil if needed
@@ -233,18 +257,21 @@ npx tsc --noEmit
 ## Success Metrics
 
 ### **Short-Term (This Week)**
+
 - [ ] PlatformServiceMixin completely independent
 - [ ] 5 critical files migrated
 - [ ] No new circular dependencies
 - [ ] All tests passing
 
 ### **Medium-Term (Next 2 Weeks)**
+
 - [ ] 35+ files migrated (70% completion)
 - [ ] Contact migration framework complete
 - [ ] Performance maintained or improved
 - [ ] User testing completed
 
 ### **Long-Term (Next Month)**
+
 - [ ] All 52 files migrated (100% completion)
 - [ ] databaseUtil.ts removed or minimal
 - [ ] Legacy Dexie code removed
@@ -253,12 +280,14 @@ npx tsc --noEmit
 ## Resource Requirements
 
 ### **Development Time**
+
 - **Immediate (This Week)**: 8-12 hours
 - **Medium-Term (Next 2 Weeks)**: 35-70 hours
 - **Long-Term (Next Month)**: 16-32 hours
 - **Total Estimated**: 59-114 hours
 
 ### **Testing Time**
+
 - **Unit Testing**: 20-30 hours
 - **Integration Testing**: 10-15 hours
 - **User Testing**: 8-12 hours
@@ -266,6 +295,7 @@ npx tsc --noEmit
 - **Total Testing**: 43-65 hours
 
 ### **Total Project Time**
+
 - **Development**: 59-114 hours
 - **Testing**: 43-65 hours
 - **Documentation**: 5-10 hours
@@ -274,6 +304,7 @@ npx tsc --noEmit
 ## Conclusion
 
 The migration is well-positioned for completion with:
+
 - ✅ **No blocking circular dependencies**
 - ✅ **PlatformServiceMixin mostly complete**
 - ✅ **Clear migration path defined**
@@ -287,4 +318,4 @@ The next steps focus on systematic file-by-file migration with proper testing an
 **Created**: 2025-07-05
 **Status**: Active Planning
 **Last Updated**: 2025-07-05
-**Note**: This roadmap is based on current codebase analysis and documented progress 
\ No newline at end of file
+**Note**: This roadmap is based on current codebase analysis and documented progress
diff --git a/doc/migration-security-checklist.md b/doc/migration-security-checklist.md
index da219b69..501953f5 100644
--- a/doc/migration-security-checklist.md
+++ b/doc/migration-security-checklist.md
@@ -352,4 +352,4 @@ This security audit checklist ensures that the database migration maintains the
 
 **Reviewed By**: _______________
 
-**Approved By**: _______________ 
\ No newline at end of file
+**Approved By**: _______________
diff --git a/doc/migration-to-wa-sqlite.md b/doc/migration-to-wa-sqlite.md
index 34f6a632..eac594ab 100644
--- a/doc/migration-to-wa-sqlite.md
+++ b/doc/migration-to-wa-sqlite.md
@@ -29,12 +29,15 @@ This document outlines the migration process from Dexie.js to absurd-sql for the
 ## Migration Architecture
 
 ### Migration Fence
+
 The migration fence is now defined by the **PlatformServiceMixin** in `src/utils/PlatformServiceMixin.ts`:
+
 - **PlatformServiceMixin**: Centralized database access with caching and utilities
 - **Migration Tools**: Exclusive interface between legacy and new databases
 - **Service Layer**: All database operations go through PlatformService
 
 ### Migration Order
+
 The migration follows a specific order to maintain data integrity:
 
 1. **Accounts** (foundational - contains DIDs)
@@ -45,9 +48,11 @@ The migration follows a specific order to maintain data integrity:
 ## ActiveDid Migration ⭐ **NEW FEATURE**
 
 ### Problem Solved
+
 Previously, the `activeDid` setting was not migrated from Dexie to SQLite, causing users to lose their active identity after migration.
 
 ### Solution Implemented
+
 The migration now includes a dedicated step for migrating the `activeDid`:
 
 1. **Detection**: Identifies the `activeDid` from Dexie master settings
@@ -58,6 +63,7 @@ The migration now includes a dedicated step for migrating the `activeDid`:
 ### Implementation Details
 
 #### New Function: `migrateActiveDid()`
+
 ```typescript
 export async function migrateActiveDid(): Promise<MigrationResult> {
   // 1. Get Dexie settings to find the activeDid
@@ -76,13 +82,17 @@ export async function migrateActiveDid(): Promise<MigrationResult> {
    ```
 
 #### Enhanced `migrateSettings()` Function
+
 The settings migration now includes activeDid handling:
+
 - Extracts `activeDid` from Dexie master settings
 - Validates account existence in SQLite
 - Updates SQLite master settings with the `activeDid`
 
 #### Updated `migrateAll()` Function
+
 The complete migration now includes a dedicated step for activeDid:
+
 ```typescript
 // Step 3: Migrate ActiveDid (depends on accounts and settings)
 logger.info("[MigrationService] Step 3: Migrating activeDid...");
@@ -90,6 +100,7 @@ const activeDidResult = await migrateActiveDid();
 ```
 
 ### Benefits
+
 - ✅ **User Identity Preservation**: Users maintain their active identity
 - ✅ **Seamless Experience**: No need to manually select identity after migration
 - ✅ **Data Consistency**: Ensures all identity-related settings are preserved
@@ -98,17 +109,20 @@ const activeDidResult = await migrateActiveDid();
 ## Migration Process
 
 ### Phase 1: Preparation ✅
+
 - [x] PlatformServiceMixin implementation
 - [x] Implement data comparison tools
 - [x] Create migration service structure
 
 ### Phase 2: Core Migration ✅
+
 - [x] Account migration with `importFromMnemonic`
 - [x] Settings migration (excluding activeDid)
 - [x] **ActiveDid migration** ⭐ **COMPLETED**
 - [x] Contact migration framework
 
 ### Phase 3: Validation and Cleanup 🔄
+
 - [ ] Comprehensive data validation
 - [ ] Performance testing
 - [ ] User acceptance testing
@@ -117,6 +131,7 @@ const activeDidResult = await migrateActiveDid();
 ## Usage
 
 ### Manual Migration
+
 ```typescript
 import { migrateAll, migrateActiveDid } from '../services/indexedDBMigrationService';
 
@@ -128,6 +143,7 @@ const activeDidResult = await migrateActiveDid();
 ```
 
 ### Migration Verification
+
 ```typescript
 import { compareDatabases } from '../services/indexedDBMigrationService';
 
@@ -136,7 +152,9 @@ console.log('Migration differences:', comparison.differences);
 ```
 
 ### PlatformServiceMixin Integration
+
 After migration, use the mixin for all database operations:
+
 ```typescript
 // Use mixin methods for database access
 const contacts = await this.$contacts();
@@ -147,11 +165,13 @@ const result = await this.$db("SELECT * FROM contacts WHERE did = ?", [accountDi
 ## Error Handling
 
 ### ActiveDid Migration Errors
+
 - **Missing Account**: If the `activeDid` from Dexie doesn't exist in SQLite accounts
 - **Database Errors**: Connection or query failures
 - **Settings Update Failures**: Issues updating SQLite master settings
 
 ### Recovery Strategies
+
 1. **Automatic Recovery**: Migration continues even if activeDid migration fails
 2. **Manual Recovery**: Users can manually select their identity after migration
 3. **Fallback**: System creates new identity if none exists
@@ -159,11 +179,13 @@ const result = await this.$db("SELECT * FROM contacts WHERE did = ?", [accountDi
 ## Security Considerations
 
 ### Data Protection
+
 - All sensitive data (mnemonics, private keys) are encrypted
 - Migration preserves encryption standards
 - No plaintext data exposure during migration
 
 ### Identity Verification
+
 - ActiveDid migration validates account existence
 - Prevents setting non-existent identities as active
 - Maintains cryptographic integrity
@@ -171,6 +193,7 @@ const result = await this.$db("SELECT * FROM contacts WHERE did = ?", [accountDi
 ## Testing
 
 ### Migration Testing
+
 ```bash
 # Run migration
 npm run migrate
@@ -180,6 +203,7 @@ npm run test:migration
 ```
 
 ### ActiveDid Testing
+
    ```typescript
 // Test activeDid migration specifically
 const result = await migrateActiveDid();
@@ -188,6 +212,7 @@ expect(result.warnings).toContain('Successfully migrated activeDid');
 ```
 
 ### PlatformServiceMixin Testing
+
 ```typescript
 // Test mixin integration
 describe('PlatformServiceMixin', () => {
@@ -224,6 +249,7 @@ describe('PlatformServiceMixin', () => {
    - Verify caching and error handling work correctly
 
 ### Debugging
+
 ```typescript
 // Debug migration process
 import { logger } from '../utils/logger';
@@ -245,6 +271,7 @@ logger.debug('[Migration] Migration completed:', result);
 ## Migration Status Checklist
 
 ### ✅ Completed
+
 - [x] PlatformServiceMixin implementation
 - [x] SQLite database service
 - [x] Migration tools
@@ -253,11 +280,13 @@ logger.debug('[Migration] Migration completed:', result);
 - [x] ActiveDid migration
 
 ### 🔄 In Progress
+
 - [ ] Contact migration
 - [ ] DatabaseUtil to PlatformServiceMixin migration
 - [ ] File-by-file migration
 
 ### ❌ Not Started
+
 - [ ] Legacy Dexie removal
 - [ ] Final cleanup and validation
 
@@ -267,4 +296,4 @@ logger.debug('[Migration] Migration completed:', result);
 **Created**: 2025-07-05
 **Status**: Active Migration Phase
 **Last Updated**: 2025-07-05
-**Note**: Migration fence now implemented through PlatformServiceMixin instead of USE_DEXIE_DB constant 
\ No newline at end of file
+**Note**: Migration fence now implemented through PlatformServiceMixin instead of USE_DEXIE_DB constant
diff --git a/doc/platformservicemixin-completion-plan.md b/doc/platformservicemixin-completion-plan.md
index 9eaa7061..b2dfa913 100644
--- a/doc/platformservicemixin-completion-plan.md
+++ b/doc/platformservicemixin-completion-plan.md
@@ -7,6 +7,7 @@ This document outlines the complete plan to finish PlatformServiceMixin implemen
 ## Current Status
 
 ### ✅ **PlatformServiceMixin - 95% Complete**
+
 - **Core functionality**: ✅ Implemented
 - **Caching system**: ✅ Implemented  
 - **Database methods**: ✅ Implemented
@@ -14,6 +15,7 @@ This document outlines the complete plan to finish PlatformServiceMixin implemen
 - **Type definitions**: ✅ Implemented
 
 ### ⚠️ **Remaining Issues**
+
 1. **Single circular dependency**: `memoryLogs` import from databaseUtil
 2. **Missing utility functions**: `generateInsertStatement`, `generateUpdateStatement`
 3. **52 files** still importing databaseUtil
@@ -25,6 +27,7 @@ This document outlines the complete plan to finish PlatformServiceMixin implemen
 ### **Phase 1: Remove Circular Dependency (30 minutes)**
 
 #### **Step 1.1: Create Self-Contained memoryLogs**
+
 ```typescript
 // In PlatformServiceMixin.ts - Replace line 50:
 // Remove: import { memoryLogs } from "@/db/databaseUtil";
@@ -48,6 +51,7 @@ $appendToMemoryLogs(message: string): void {
 ```
 
 #### **Step 1.2: Update logger.ts**
+
 ```typescript
 // In logger.ts - Replace memoryLogs usage:
 // Remove: import { memoryLogs } from "@/db/databaseUtil";
@@ -70,6 +74,7 @@ export function getMemoryLogs(): string[] {
 ### **Phase 2: Add Missing Utility Functions (1 hour)**
 
 #### **Step 2.1: Add generateInsertStatement to PlatformServiceMixin**
+
 ```typescript
 // Add to PlatformServiceMixin methods:
 _generateInsertStatement(
@@ -95,6 +100,7 @@ _generateInsertStatement(
 ```
 
 #### **Step 2.2: Add generateUpdateStatement to PlatformServiceMixin**
+
 ```typescript
 // Add to PlatformServiceMixin methods:
 _generateUpdateStatement(
@@ -129,6 +135,7 @@ _generateUpdateStatement(
 ```
 
 #### **Step 2.3: Add Public Wrapper Methods**
+
 ```typescript
 // Add to PlatformServiceMixin methods:
 $generateInsertStatement(
@@ -151,6 +158,7 @@ $generateUpdateStatement(
 ### **Phase 3: Update Type Definitions (30 minutes)**
 
 #### **Step 3.1: Update IPlatformServiceMixin Interface**
+
 ```typescript
 // Add to IPlatformServiceMixin interface:
 $generateInsertStatement(
@@ -167,6 +175,7 @@ $appendToMemoryLogs(message: string): void;
 ```
 
 #### **Step 3.2: Update ComponentCustomProperties**
+
 ```typescript
 // Add to ComponentCustomProperties interface:
 $generateInsertStatement(
@@ -185,12 +194,14 @@ $appendToMemoryLogs(message: string): void;
 ### **Phase 4: Test PlatformServiceMixin (1 hour)**
 
 #### **Step 4.1: Create Test Component**
+
 ```typescript
 // Create test file: src/test/PlatformServiceMixin.test.ts
 // Test all methods including new utility functions
 ```
 
 #### **Step 4.2: Run Linting and Type Checking**
+
 ```bash
 npm run lint
 npx tsc --noEmit
@@ -203,6 +214,7 @@ npx tsc --noEmit
 ### **Migration Strategy**
 
 #### **Priority Order:**
+
 1. **Views** (25 files) - User-facing components
 2. **Components** (15 files) - Reusable UI components  
 3. **Services** (8 files) - Business logic
@@ -211,6 +223,7 @@ npx tsc --noEmit
 #### **Migration Pattern for Each File:**
 
 **Step 1: Add PlatformServiceMixin**
+
 ```typescript
 // Add to component imports:
 import { PlatformServiceMixin } from "@/utils/PlatformServiceMixin";
@@ -223,6 +236,7 @@ export default class ComponentName extends Vue {
 ```
 
 **Step 2: Replace databaseUtil Imports**
+
 ```typescript
 // Remove:
 import { 
@@ -244,6 +258,7 @@ import {
 ```
 
 **Step 3: Update Method Calls**
+
 ```typescript
 // Before:
 const { sql, params } = generateInsertStatement(contact, 'contacts');
@@ -255,6 +270,7 @@ const { sql, params } = this.$generateInsertStatement(contact, 'contacts');
 ### **File Migration Checklist**
 
 #### **Views (25 files) - Priority 1**
+
 - [ ] QuickActionBvcEndView.vue
 - [ ] ProjectsView.vue
 - [ ] ClaimReportCertificateView.vue
@@ -278,6 +294,7 @@ const { sql, params } = this.$generateInsertStatement(contact, 'contacts');
 - [ ] [5 more view files]
 
 #### **Components (15 files) - Priority 2**
+
 - [ ] ActivityListItem.vue
 - [ ] AmountInput.vue
 - [ ] ChoiceButtonDialog.vue
@@ -295,18 +312,21 @@ const { sql, params } = this.$generateInsertStatement(contact, 'contacts');
 - [ ] IconRenderer.vue
 
 #### **Services (8 files) - Priority 3**
+
 - [ ] api.ts
 - [ ] endorserServer.ts
 - [ ] partnerServer.ts
 - [ ] [5 more service files]
 
 #### **Utils (4 files) - Priority 4**
+
 - [ ] LogCollector.ts
 - [ ] [3 more util files]
 
 ### **Migration Tools**
 
 #### **Automated Script for Common Patterns**
+
 ```bash
 #!/bin/bash
 # migration-helper.sh
@@ -326,6 +346,7 @@ echo "logConsoleAndDb → this.\$logAndConsole"
 ```
 
 #### **Validation Script**
+
 ```bash
 #!/bin/bash
 # validate-migration.sh
@@ -350,6 +371,7 @@ echo "Migration validation complete!"
 ## 🎯 **Success Criteria**
 
 ### **Day 1 Success Criteria:**
+
 - [ ] PlatformServiceMixin has no circular dependencies
 - [ ] All utility functions implemented and tested
 - [ ] Type definitions complete and accurate
@@ -357,6 +379,7 @@ echo "Migration validation complete!"
 - [ ] TypeScript compilation passes
 
 ### **Day 2 Success Criteria:**
+
 - [ ] 0 files importing databaseUtil
 - [ ] All 52 files migrated to PlatformServiceMixin
 - [ ] No runtime errors in migrated components
@@ -364,6 +387,7 @@ echo "Migration validation complete!"
 - [ ] Performance maintained or improved
 
 ### **Overall Success Criteria:**
+
 - [ ] Complete elimination of databaseUtil dependency
 - [ ] PlatformServiceMixin is the single source of truth for database operations
 - [ ] Migration fence is fully implemented
@@ -386,12 +410,14 @@ echo "Migration validation complete!"
 ## 📋 **Daily Progress Tracking**
 
 ### **Day 1 Progress:**
+
 - [ ] Phase 1: Circular dependency resolved
 - [ ] Phase 2: Utility functions added
 - [ ] Phase 3: Type definitions updated
 - [ ] Phase 4: Testing completed
 
 ### **Day 2 Progress:**
+
 - [ ] Views migrated (0/25)
 - [ ] Components migrated (0/15)
 - [ ] Services migrated (0/8)
@@ -403,16 +429,19 @@ echo "Migration validation complete!"
 ## 🆘 **Contingency Plans**
 
 ### **If Day 1 Takes Longer:**
+
 - Focus on core functionality first
 - Defer advanced utility functions to Day 2
 - Prioritize circular dependency resolution
 
 ### **If Day 2 Takes Longer:**
+
 - Focus on high-impact views first
 - Batch similar components together
 - Use automated scripts for common patterns
 
 ### **If Issues Arise:**
+
 - Document specific problems
 - Create targeted fixes
-- Maintain backward compatibility during transition 
\ No newline at end of file
+- Maintain backward compatibility during transition
diff --git a/doc/qr-code-implementation-guide.md b/doc/qr-code-implementation-guide.md
index 13405160..2ebe5025 100644
--- a/doc/qr-code-implementation-guide.md
+++ b/doc/qr-code-implementation-guide.md
@@ -7,6 +7,7 @@ This document describes the QR code scanning and generation implementation in th
 ## Architecture
 
 ### Directory Structure
+
 ```
 src/
 ├── services/
@@ -74,6 +75,7 @@ interface QRScannerOptions {
 ### Platform-Specific Implementations
 
 #### Mobile (Capacitor)
+
 - Uses `@capacitor-mlkit/barcode-scanning`
 - Native camera access through platform APIs
 - Optimized for mobile performance
@@ -82,6 +84,7 @@ interface QRScannerOptions {
 - Back camera preferred for scanning
 
 Configuration:
+
 ```typescript
 // capacitor.config.ts
 const config: CapacitorConfig = {
@@ -105,6 +108,7 @@ const config: CapacitorConfig = {
 ```
 
 #### Web
+
 - Uses browser's MediaDevices API
 - Vue.js components for UI
 - EventEmitter for stream management
@@ -116,6 +120,7 @@ const config: CapacitorConfig = {
 ### View Components
 
 #### ContactQRScanView
+
 - Dedicated view for scanning QR codes
 - Full-screen camera interface
 - Simple UI focused on scanning
@@ -123,6 +128,7 @@ const config: CapacitorConfig = {
 - Streamlined scanning experience
 
 #### ContactQRScanShowView
+
 - Combined view for QR code display and scanning
 - Shows user's own QR code
 - Handles user registration status
@@ -160,6 +166,7 @@ const config: CapacitorConfig = {
 ## Build Configuration
 
 ### Common Vite Configuration
+
 ```typescript
 // vite.config.common.mts
 export async function createBuildConfig(mode: string) {
@@ -183,6 +190,7 @@ export async function createBuildConfig(mode: string) {
 ```
 
 ### Platform-Specific Builds
+
 ```json
 {
   "scripts": {
@@ -196,6 +204,7 @@ export async function createBuildConfig(mode: string) {
 ## Error Handling
 
 ### Common Error Scenarios
+
 1. No camera found
 2. Permission denied
 3. Camera in use by another application
@@ -207,6 +216,7 @@ export async function createBuildConfig(mode: string) {
 9. Network connectivity issues
 
 ### Error Response
+
 - User-friendly error messages
 - Troubleshooting tips
 - Clear instructions for resolution
@@ -215,6 +225,7 @@ export async function createBuildConfig(mode: string) {
 ## Security Considerations
 
 ### QR Code Security
+
 - Encryption of contact data
 - Timestamp validation
 - Version checking
@@ -222,6 +233,7 @@ export async function createBuildConfig(mode: string) {
 - Rate limiting for scans
 
 ### Data Protection
+
 - Secure transmission of contact data
 - Validation of QR code authenticity
 - Prevention of duplicate scans
@@ -231,6 +243,7 @@ export async function createBuildConfig(mode: string) {
 ## Best Practices
 
 ### Camera Access
+
 1. Always check for camera availability
 2. Request permissions explicitly
 3. Handle all error conditions
@@ -238,6 +251,7 @@ export async function createBuildConfig(mode: string) {
 5. Implement proper cleanup
 
 ### Performance
+
 1. Optimize camera resolution
 2. Implement proper resource cleanup
 3. Handle camera switching efficiently
@@ -245,6 +259,7 @@ export async function createBuildConfig(mode: string) {
 5. Battery usage optimization
 
 ### User Experience
+
 1. Clear visual feedback
 2. Camera preview
 3. Scanning status indicators
@@ -257,6 +272,7 @@ export async function createBuildConfig(mode: string) {
 ## Testing
 
 ### Test Scenarios
+
 1. Permission handling
 2. Camera switching
 3. Error conditions
@@ -267,6 +283,7 @@ export async function createBuildConfig(mode: string) {
 8. Security validation
 
 ### Test Environment
+
 - Multiple browsers
 - iOS and Android devices
 - Various network conditions
@@ -275,6 +292,7 @@ export async function createBuildConfig(mode: string) {
 ## Dependencies
 
 ### Key Packages
+
 - `@capacitor-mlkit/barcode-scanning`
 - `qrcode-stream`
 - `vue-qrcode-reader`
@@ -283,12 +301,14 @@ export async function createBuildConfig(mode: string) {
 ## Maintenance
 
 ### Regular Updates
+
 - Keep dependencies updated
 - Monitor platform changes
 - Update documentation
 - Review security patches
 
 ### Performance Monitoring
+
 - Track memory usage
 - Monitor camera performance
 - Check error rates
@@ -436,6 +456,7 @@ The camera switching implementation includes comprehensive error handling:
    - Camera switch timeout
 
 2. **Error Response**
+
    ```typescript
    private async handleCameraSwitch(deviceId: string): Promise<void> {
      try {
@@ -460,6 +481,7 @@ The camera switching implementation includes comprehensive error handling:
 The camera system maintains several states:
 
 1. **Camera States**
+
    ```typescript
    type CameraState =
      | "initializing"  // Camera is being initialized
@@ -529,6 +551,7 @@ The camera system maintains several states:
 #### MLKit Barcode Scanner Configuration
 
 1. **Plugin Setup**
+
    ```typescript
    // capacitor.config.ts
    const config: CapacitorConfig = {
@@ -552,6 +575,7 @@ The camera system maintains several states:
    ```
 
 2. **Camera Management**
+
    ```typescript
    // CapacitorQRScanner.ts
    export class CapacitorQRScanner implements QRScannerService {
@@ -603,6 +627,7 @@ The camera system maintains several states:
    ```
 
 3. **Camera State Management**
+
    ```typescript
    // CapacitorQRScanner.ts
    private async handleCameraState(): Promise<void> {
@@ -645,6 +670,7 @@ The camera system maintains several states:
    ```
 
 4. **Error Handling**
+
    ```typescript
    // CapacitorQRScanner.ts
    private async handleCameraError(error: Error): Promise<void> {
@@ -737,6 +763,7 @@ The camera system maintains several states:
 #### Performance Optimization
 
 1. **Battery Usage**
+
    ```typescript
    // CapacitorQRScanner.ts
    private optimizeBatteryUsage(): void {
@@ -759,6 +786,7 @@ The camera system maintains several states:
    ```
 
 2. **Memory Management**
+
    ```typescript
    // CapacitorQRScanner.ts
    private async cleanupResources(): Promise<void> {
@@ -802,4 +830,4 @@ The camera system maintains several states:
    - Camera switching speed
    - QR code detection speed
    - App responsiveness
-   - Background/foreground transitions
\ No newline at end of file
+   - Background/foreground transitions
diff --git a/doc/secure-storage-implementation.md b/doc/secure-storage-implementation.md
index ba4f04da..012d83b0 100644
--- a/doc/secure-storage-implementation.md
+++ b/doc/secure-storage-implementation.md
@@ -111,6 +111,7 @@ export class AbsurdSqlDatabaseService implements PlatformService {
 ```
 
 Key features:
+
 - Uses absurd-sql for SQLite in the browser
 - Implements operation queuing for thread safety
 - Handles initialization and connection management
@@ -143,6 +144,7 @@ async function getAccount(did: string): Promise<Account | undefined> {
 When converting from Dexie.js to SQL-based implementation, follow these patterns:
 
 1. **Database Access Pattern**
+
    ```typescript
    // Before (Dexie)
    const result = await db.table.where("field").equals(value).first();
@@ -161,6 +163,7 @@ When converting from Dexie.js to SQL-based implementation, follow these patterns
    ```
 
 2. **Update Operations**
+
    ```typescript
    // Before (Dexie)
    await db.table.where("id").equals(id).modify(changes);
@@ -184,6 +187,7 @@ When converting from Dexie.js to SQL-based implementation, follow these patterns
    ```
 
 3. **Insert Operations**
+
    ```typescript
    // Before (Dexie)
    await db.table.add(item);
@@ -202,6 +206,7 @@ When converting from Dexie.js to SQL-based implementation, follow these patterns
    ```
 
 4. **Delete Operations**
+
    ```typescript
    // Before (Dexie)
    await db.table.where("id").equals(id).delete();
@@ -216,6 +221,7 @@ When converting from Dexie.js to SQL-based implementation, follow these patterns
    ```
 
 5. **Result Processing**
+
    ```typescript
    // Before (Dexie)
    const items = await db.table.toArray();
@@ -247,6 +253,7 @@ await databaseUtil.logConsoleAndDb(message, showInConsole);
 ```
 
 Key Considerations:
+
 - Always use `databaseUtil.mapQueryResultToValues()` to process SQL query results
 - Use utility methods from `db/index.ts` when available instead of direct SQL
 - Keep Dexie fallbacks wrapped in migration period checks
@@ -254,6 +261,7 @@ Key Considerations:
 - For updates/inserts/deletes, execute both SQL and Dexie operations during migration period
 
 Example Migration:
+
 ```typescript
 // Before (Dexie)
 export async function updateSettings(settings: Settings): Promise<void> {
@@ -274,6 +282,7 @@ export async function updateSettings(settings: Settings): Promise<void> {
 ```
 
 Remember to:
+
 - Create database access code to use the platform service, putting it in front of the Dexie version
 - Instead of removing Dexie-specific code, keep it.
 
@@ -330,4 +339,4 @@ it's during migration then use that result instead of the SQL code's result.
 4. **Documentation**
    - Add API documentation
    - Create migration guides
-   - Document security measures
\ No newline at end of file
+   - Document security measures
diff --git a/doc/sharebufferarray_spectre_security.md b/doc/sharebufferarray_spectre_security.md
index 44faebbb..14cd5af8 100644
--- a/doc/sharebufferarray_spectre_security.md
+++ b/doc/sharebufferarray_spectre_security.md
@@ -4,11 +4,13 @@
 ## 1. Introduction to SharedArrayBuffer
 
 ### Overview
+
 - `SharedArrayBuffer` is a JavaScript object that enables **shared memory** access between the main thread and Web Workers.
 - Unlike `ArrayBuffer`, the memory is **not copied** between threads—allowing **true parallelism**.
 - Paired with `Atomics`, it allows low-level memory synchronization (e.g., locks, waits).
 
 ### Example Use
+
 ```js
 const sab = new SharedArrayBuffer(1024);
 const sharedArray = new Uint8Array(sab);
@@ -18,6 +20,7 @@ sharedArray[0] = 42;
 ## 2. Browser Security Requirements
 
 ### Security Headers Required to Use SharedArrayBuffer
+
 Modern browsers **restrict access** to `SharedArrayBuffer` due to Spectre-class vulnerabilities.
 
 The following **HTTP headers must be set** to enable it:
@@ -28,23 +31,28 @@ Cross-Origin-Embedder-Policy: require-corp
 ```
 
 ### HTTPS Requirement
+
 - Must be served over **HTTPS** (except `localhost` for dev).
 - These headers enforce **cross-origin isolation**.
 
 ### Role of CORS
+
 - CORS **alone is not sufficient**.
 - However, embedded resources (like scripts and iframes) must still include proper CORS headers if they are to be loaded in a cross-origin isolated context.
 
 ## 3. Spectre Vulnerability
 
 ### What is Spectre?
+
 - A class of **side-channel attacks** exploiting **speculative execution** in CPUs.
 - Allows an attacker to read arbitrary memory from the same address space.
 
 ### Affected Architectures
+
 - Intel, AMD, ARM — essentially **all modern processors**.
 
 ### Why It's Still a Concern
+
 - It's a **hardware flaw**, not just a software bug.
 - Can't be fully fixed in software without performance penalties.
 - New Spectre **variants** (e.g., v2, RSB, BranchScope) continue to emerge.
@@ -52,16 +60,19 @@ Cross-Origin-Embedder-Policy: require-corp
 ## 4. Mitigations and Current Limitations
 
 ### Browser Mitigations
+
 - **Restricted precision** for `performance.now()`.
 - **Disabled or gated** access to `SharedArrayBuffer`.
 - **Reduced or removed** fine-grained timers.
 
 ### OS/Hardware Mitigations
+
 - **Kernel Page Table Isolation (KPTI)**
 - **Microcode updates**
 - **Retpoline** compiler mitigations
 
 ### Developer Responsibilities
+
 - Avoid sharing sensitive data across threads unless necessary.
 - Use **constant-time cryptographic functions**.
 - Assume timing attacks are **still possible**.
@@ -70,10 +81,12 @@ Cross-Origin-Embedder-Policy: require-corp
 ## 5. Practical Development Notes
 
 ### Using SharedArrayBuffer Safely
+
 - Ensure the site is **cross-origin isolated**:
   - Serve all resources with appropriate **CORS policies** (`Cross-Origin-Resource-Policy`, `Access-Control-Allow-Origin`)
   - Set the required **COOP/COEP headers**
 - Validate support using:
+
 ```js
 if (window.crossOriginIsolated) {
     // Safe to use SharedArrayBuffer
@@ -81,6 +94,7 @@ if (window.crossOriginIsolated) {
 ```
 
 ### Testing and Fallback
+
 - Provide fallbacks to `ArrayBuffer` if isolation is not available.
 - Document use cases clearly (e.g., high-performance WebAssembly applications or real-time audio/video processing).
 
diff --git a/doc/storage-implementation-checklist.md b/doc/storage-implementation-checklist.md
index dec776ac..175cc8e1 100644
--- a/doc/storage-implementation-checklist.md
+++ b/doc/storage-implementation-checklist.md
@@ -3,6 +3,7 @@
 ## Core Services
 
 ### 1. Storage Service Layer
+
 - [x] Create base `PlatformService` interface
   - [x] Define common methods for all platforms
   - [x] Add platform-specific method signatures
@@ -25,6 +26,7 @@
     - [ ] File system access
 
 ### 2. Migration Services
+
 - [x] Implement basic migration support
   - [x] Dual-storage pattern (SQLite + Dexie)
   - [x] Basic data verification
@@ -37,6 +39,7 @@
   - [ ] Manual triggers
 
 ### 3. Security Layer
+
 - [x] Basic data integrity
 - [ ] Implement `EncryptionService` (planned)
   - [ ] Key management
@@ -50,14 +53,17 @@
 ## Platform-Specific Implementation
 
 ### Web Platform
+
 - [x] Setup absurd-sql
   - [x] Install dependencies
+
     ```json
     {
       "@jlongster/sql.js": "^1.8.0",
       "absurd-sql": "^1.8.0"
     }
     ```
+
   - [x] Configure VFS with IndexedDB backend
   - [x] Setup worker threads
   - [x] Implement operation queuing
@@ -83,6 +89,7 @@
   - [x] Implement atomic operations
 
 ### iOS Platform (Planned)
+
 - [ ] Setup SQLCipher
   - [ ] Install pod dependencies
   - [ ] Configure encryption
@@ -96,6 +103,7 @@
   - [ ] Setup app groups
 
 ### Android Platform (Planned)
+
 - [ ] Setup SQLCipher
   - [ ] Add Gradle dependencies
   - [ ] Configure encryption
@@ -109,6 +117,7 @@
   - [ ] Setup file provider
 
 ### Electron Platform (Planned)
+
 - [ ] Setup Node SQLite
   - [ ] Install dependencies
   - [ ] Configure IPC
@@ -124,6 +133,7 @@
 ## Data Models and Types
 
 ### 1. Database Schema
+
 - [x] Define tables
 
   ```sql
@@ -166,6 +176,7 @@
 ### 2. Type Definitions
 
 - [x] Create interfaces
+
   ```typescript
   interface Account {
     did: string;
@@ -197,6 +208,7 @@
 ## UI Components
 
 ### 1. Migration UI (Planned)
+
 - [ ] Create components
   - [ ] `MigrationProgress.vue`
   - [ ] `MigrationError.vue`
@@ -204,6 +216,7 @@
   - [ ] `MigrationStatus.vue`
 
 ### 2. Settings UI (Planned)
+
 - [ ] Update components
   - [ ] Add storage settings
   - [ ] Add migration controls
@@ -211,6 +224,7 @@
   - [ ] Add security settings
 
 ### 3. Error Handling UI (Planned)
+
 - [ ] Create components
   - [ ] `StorageError.vue`
   - [ ] `QuotaExceeded.vue`
@@ -220,6 +234,7 @@
 ## Testing
 
 ### 1. Unit Tests
+
 - [x] Basic service tests
   - [x] Platform service tests
   - [x] Database operation tests
@@ -227,6 +242,7 @@
   - [ ] Platform detection tests (planned)
 
 ### 2. Integration Tests (Planned)
+
 - [ ] Test migrations
   - [ ] Web platform tests
   - [ ] iOS platform tests
@@ -234,6 +250,7 @@
   - [ ] Electron platform tests
 
 ### 3. E2E Tests (Planned)
+
 - [ ] Test workflows
   - [ ] Account management
   - [ ] Settings management
@@ -243,12 +260,14 @@
 ## Documentation
 
 ### 1. Technical Documentation
+
 - [x] Update architecture docs
 - [x] Add API documentation
 - [ ] Create migration guides (planned)
 - [ ] Document security measures (planned)
 
 ### 2. User Documentation (Planned)
+
 - [ ] Update user guides
 - [ ] Add troubleshooting guides
 - [ ] Create FAQ
@@ -257,12 +276,14 @@
 ## Deployment
 
 ### 1. Build Process
+
 - [x] Update build scripts
 - [x] Add platform-specific builds
 - [ ] Configure CI/CD (planned)
 - [ ] Setup automated testing (planned)
 
 ### 2. Release Process (Planned)
+
 - [ ] Create release checklist
 - [ ] Add version management
 - [ ] Setup rollback procedures
@@ -271,12 +292,14 @@
 ## Monitoring and Analytics (Planned)
 
 ### 1. Error Tracking
+
 - [ ] Setup error logging
 - [ ] Add performance monitoring
 - [ ] Configure alerts
 - [ ] Create dashboards
 
 ### 2. Usage Analytics
+
 - [ ] Add storage metrics
 - [ ] Track migration success
 - [ ] Monitor performance
@@ -285,12 +308,14 @@
 ## Security Audit (Planned)
 
 ### 1. Code Review
+
 - [ ] Review encryption
 - [ ] Check access controls
 - [ ] Verify data handling
 - [ ] Audit dependencies
 
 ### 2. Penetration Testing
+
 - [ ] Test data access
 - [ ] Verify encryption
 - [ ] Check authentication
@@ -299,6 +324,7 @@
 ## Success Criteria
 
 ### 1. Performance
+
 - [x] Query response time < 100ms
 - [x] Operation queuing for thread safety
 - [x] Proper initialization handling
@@ -307,6 +333,7 @@
 - [ ] Memory usage < 50MB (planned)
 
 ### 2. Reliability
+
 - [x] Basic data integrity
 - [x] Operation queuing
 - [ ] Automatic recovery (planned)
@@ -315,6 +342,7 @@
 - [ ] Data consistency (planned)
 
 ### 3. Security
+
 - [x] Basic data integrity
 - [ ] AES-256 encryption (planned)
 - [ ] Secure key storage (planned)
@@ -322,8 +350,9 @@
 - [ ] Audit logging (planned)
 
 ### 4. User Experience
+
 - [x] Basic database operations
 - [ ] Smooth migration (planned)
 - [ ] Clear error messages (planned)
 - [ ] Progress indicators (planned)
-- [ ] Recovery options (planned) 
\ No newline at end of file
+- [ ] Recovery options (planned)
diff --git a/doc/usage-guide.md b/doc/usage-guide.md
index 214ebf88..596da455 100644
--- a/doc/usage-guide.md
+++ b/doc/usage-guide.md
@@ -53,10 +53,9 @@ header-includes:
 
 \clearpage
 
-
 # Purpose of Document
 
-Both end-users and development team members need to know how to use TimeSafari. 
+Both end-users and development team members need to know how to use TimeSafari.
 This document serves to show how to use every feature of the TimeSafari platform.
 
 Sections of this document are geared specifically for software developers and quality assurance
@@ -64,7 +63,7 @@ team members.
 
 Companion videos will also describe end-to-end workflows for the end-user.
 
-# TimeSafari 
+# TimeSafari
 
 ## Overview
 
@@ -90,49 +89,51 @@ development environment. This section will guide you through the process.
 ## Prerequisites
 
 1. Have the following installed on your local machine:
-  - Node.js and NPM
-  - A web browser. For this guide, we will use Google Chrome.
-  - Git
-  - A code editor
+
+- Node.js and NPM
+- A web browser. For this guide, we will use Google Chrome.
+- Git
+- A code editor
 
 2. Create an API key on Infura. This is necessary for the Endorser API to connect to the Ethereum
-   blockchain. 
-  - You can create an account on Infura [here](https://infura.io/).\
+   blockchain.
+
+- You can create an account on Infura [here](https://infura.io/).\
     Click "CREATE NEW API KEY" and label the key. Then click "API Keys" in the top menu bar to
     be taken back to the list of keys.
-    
-    Click "VIEW STATS" on the key you want to use.   
-    
+
+    Click "VIEW STATS" on the key you want to use.
+
     ![](images/01_infura-api-keys.png){ width=550px }
   
-  - Go to the key detail page. Then click "MANAGE API KEY".
+- Go to the key detail page. Then click "MANAGE API KEY".
   
     ![](images/02-infura-key-detail.png){ width=550px }
   
-  - Click the copy and paste button next to the string of alphanumeric characters.\
+- Click the copy and paste button next to the string of alphanumeric characters.\
     This is your API, also known as your project ID.
   
     ![](images/03-infura-api-key-id.png){width=550px }
   
-  - Save this for later during the Endorser API setup. This will go in your `INFURA_PROJECT_ID` 
+- Save this for later during the Endorser API setup. This will go in your `INFURA_PROJECT_ID`
     environment variable.
-    
 
 ## Setup steps
 
-### 1. Clone the following repositories from their respective Git hosts:
-  - [TimeSafari Frontend](https://gitea.anomalistdesign.com/trent_larson/crowd-funder-for-time-pwa)\
+### 1. Clone the following repositories from their respective Git hosts
+
+- [TimeSafari Frontend](https://gitea.anomalistdesign.com/trent_larson/crowd-funder-for-time-pwa)\
     This is a Progressive Web App (PWA) built with VueJS and TypeScript.
     Note that the clone command here is different from the one you would use for GitHub.
-    
+
 ```bash
 git clone git clone \
   ssh://git@gitea.anomalistdesign.com:222/trent_larson/crowd-funder-for-time-pwa.git
 ```
   
-  - [TimeSafari Backend - Endorser API](https://github.com/trentlarson/endorser-ch)\
+- [TimeSafari Backend - Endorser API](https://github.com/trentlarson/endorser-ch)\
     This is a NodeJS service providing the backend for TimeSafari.
-    
+
     ```bash
     git clone git@github.com:trentlarson/endorser-ch.git
     ```
@@ -148,7 +149,7 @@ below to generate sample data. Then copy the test database, rename it to `-dev`
 `cp ../endorser-ch-test-local.sqlite3 ../endorser-ch-dev.sqlite3` \
 and rerun `npm run dev` to give yourself user #0 and others from the ETHR_CRED_DATA in [the endorser.ch test util file](https://github.com/trentlarson/endorser-ch/blob/master/test/util.js#L90)
 
-#### Alternative 2 - boostrap single seed user 
+#### Alternative 2 - boostrap single seed user
 
 In this method you will end up with two accounts in the database, one for the first boostrap user,
 and the second as the primary user you will use during testing. The first user will invite the
@@ -157,26 +158,30 @@ second user to the app.
 1. Install dependencies and environment variables.\
    In endorser-ch install dependencies and set up environment variables to allow starting it up in
    development mode.
+
    ```bash
    cd endorser-ch
    npm clean install  # or npm ci
    cp .env.local .env
    ```
+
    Edit the .env file's INFURA_PROJECT_ID with the value you saved earlier in the
    prerequisites.\
    Then create the SQLite database by running `npm run flyway migrate` with environment variables
    set correctly to select the default SQLite development user as follows.
+
    ```bash
    export NODE_ENV=dev 
    export DBUSER=sa 
    export DBPASS=sasa 
    npm run flyway migrate
-   ``` 
-   The first run of flyway migrate may take some time to complete because the entire Flyway 
+   ```
+
+   The first run of flyway migrate may take some time to complete because the entire Flyway
    distribution must be downloaded prior to executing migrations.
-    
+
    Successful output looks similar to the following:
-    
+
 ```
 Database: jdbc:sqlite:../endorser-ch-dev.sqlite3 (SQLite 3.41)
 Schema history table "main"."flyway_schema_history" does not exist yet
@@ -202,23 +207,23 @@ A Flyway report has been generated here: /Users/kbull/code/timesafari/endorser-c
 2. Generate the first user in TimeSafari PWA and bootstrap that user in Endorser's database.\
    As TimeSafari is an invite-only platform the first user must be manually bootstrapped since
    no other users exist to be able to invite the first user. This first user must be added manually
-   to the SQLite database used by Endorser. In this setup you generate the first user from the PWA. 
-   
-   This user is automatically generated on first usage of the TimeSafari PWA. Bootstrapping that 
+   to the SQLite database used by Endorser. In this setup you generate the first user from the PWA.
+
+   This user is automatically generated on first usage of the TimeSafari PWA. Bootstrapping that
    user is required so that this first user can register other users.
    - Change directories into `crowd-funder-for-time-pwa`
-     
+
      ```bash
      cd ..
      cd crowd-funder-for-time-pwa 
      ```
-   
+
    - Ensure the `.env.development` file exists and has the following values:
-   
+
      ```env
      VITE_DEFAULT_ENDORSER_API_SERVER=http://127.0.0.1:3000
      ```
-   
+
    - Install dependencies and run in dev mode. For now don't worry about configuring the app. All we
      need is to generate the first root user and this happens automatically on app startup.
   
@@ -230,45 +235,45 @@ A Flyway report has been generated here: /Users/kbull/code/timesafari/endorser-c
    - Open the app in a browser and go to the developer tools. It is recommended to use a completely
      separate browser profile so you do not clear out your existing user account. We will be
      completely resetting the PWA app state prior to generating the first user.
-   
+
      In the Developer Tools go to the Application tab.
-     
-     ![](images/04-pwa-chrome-devtools.png){width=350px} 
-   
+
+     ![](images/04-pwa-chrome-devtools.png){width=350px}
+
      Click the "Clear site data" button and then refresh the page.
-   
+
    - Click the account button in the bottom right corner of the page.
-   
+
      ![](images/05-pwa-account-button.png){width=150px}
-   
+
    - This will take you to the account page titled "Your Identity" on which you can see your DID,
      a `did:ethr` DID in this case.
-   
+
      ![](images/06-pwa-account-page.png){width=350px}
-   
+
    - Copy the DID by selecting it and copying it to the clipboard or by clicking the copy and paste
      button as shown in the image.
-   
+
      ![](images/07-pwa-did-copied.png){width=200px}
-    
+
      In our case this DID is:\
      `did:ethr:0xe4B783c74c8B0e229524e44d0cD898D272E02CD6`
-   
-  - Add that DID to the following echoed SQL statement where it says `YOUR_DID`
+
+- Add that DID to the following echoed SQL statement where it says `YOUR_DID`
   
     ```bash
     echo "INSERT INTO registration (did, maxClaims, maxRegs, epoch) 
     VALUES ('YOUR_DID', 100, 10000, 1719348718092);"
     | sqlite3 ./endorser-ch-dev.sqlite3
     ```
-    
+
     and run this command in the parent directory just above the `endorser-ch` directory.
-    
-    It needs to be the parent directory of your `endorser-ch` repository because when 
+
+    It needs to be the parent directory of your `endorser-ch` repository because when
     `endorser-ch` creates the SQLite database it depends on it creates it in the parent directory
     of `endorser-ch`.
-    
-  - You can verify with an SQL browser tool that your record has been added to the `registration`
+
+- You can verify with an SQL browser tool that your record has been added to the `registration`
     table.
   
     ![](images/08-endorser-sqlite-row-added.png){width=350px}
@@ -285,14 +290,14 @@ A Flyway report has been generated here: /Users/kbull/code/timesafari/endorser-c
 4. Create the second user by opening up a separate browser profile or incognito session, opening the
    TimeSafari PWA at `http://localhost:8080`. You will see the yellow banner stating "Someone must
    register you before you can give or offer."
-   
+
    ![](images/09-pwa-second-profile-first-open.png){width=350px}
-   
+
    - If you want to ensure you have a fresh user account then open the developer tools, clear the
-     Application data as before, and then refresh the page. This will generate a new user in the 
+     Application data as before, and then refresh the page. This will generate a new user in the
      browser's IndexedDB database.
 5. Go to the second users' account page to copy the DID.
-    
+
     ![](images/10-pwa-second-user-did.png){width=350px}
 
 6. Copy the DID and put it in the text bar on the "Your Contacts" page for the first account
diff --git a/docker/README.md b/docker/README.md
index b79a8b6d..a4032778 100644
--- a/docker/README.md
+++ b/docker/README.md
@@ -155,6 +155,7 @@ VITE_PASSKEYS_ENABLED=true
 ## Build Modes
 
 ### Development Mode
+
 - **Target**: `development`
 - **Features**: Hot reloading, development server
 - **Port**: 5173
@@ -168,6 +169,7 @@ docker build --target development -t timesafari:dev .
 ```
 
 ### Staging Mode
+
 - **Target**: `staging`
 - **Features**: Production build with relaxed caching
 - **Port**: 8080 (mapped from 80)
@@ -181,6 +183,7 @@ docker build --build-arg BUILD_MODE=staging -t timesafari:staging .
 ```
 
 ### Production Mode
+
 - **Target**: `production`
 - **Features**: Optimized production build
 - **Port**: 80
@@ -194,6 +197,7 @@ docker build -t timesafari:latest .
 ```
 
 ### Custom Mode
+
 - **Target**: Configurable via `BUILD_TARGET`
 - **Features**: Fully configurable
 - **Port**: Configurable via `CUSTOM_PORT`
@@ -250,6 +254,7 @@ docker-compose up staging
 ## Security Features
 
 ### Built-in Security
+
 - **Non-root user execution**: All containers run as non-root users
 - **Security headers**: XSS protection, content type options, frame options
 - **Rate limiting**: API request rate limiting
@@ -257,6 +262,7 @@ docker-compose up staging
 - **Minimal attack surface**: Alpine Linux base images
 
 ### Security Headers
+
 - `X-Frame-Options: SAMEORIGIN`
 - `X-Content-Type-Options: nosniff`
 - `X-XSS-Protection: 1; mode=block`
@@ -266,17 +272,20 @@ docker-compose up staging
 ## Performance Optimizations
 
 ### Caching Strategy
+
 - **Static assets**: 1 year cache with immutable flag (production)
 - **HTML files**: 1 hour cache (production) / no cache (staging)
 - **Service worker**: No cache
 - **Manifest**: 1 day cache (production) / 1 hour cache (staging)
 
 ### Compression
+
 - **Gzip compression**: Enabled for text-based files
 - **Compression level**: 6 (balanced)
 - **Minimum size**: 1024 bytes
 
 ### Nginx Optimizations
+
 - **Sendfile**: Enabled for efficient file serving
 - **TCP optimizations**: nopush and nodelay enabled
 - **Keepalive**: 65 second timeout
@@ -285,19 +294,23 @@ docker-compose up staging
 ## Health Checks
 
 ### Built-in Health Checks
+
 All services include health checks that:
+
 - Check every 30 seconds
 - Timeout after 10 seconds
 - Retry 3 times before marking unhealthy
 - Start checking after 40 seconds
 
 ### Health Check Endpoints
+
 - **Production/Staging**: `http://localhost/health`
 - **Development**: `http://localhost:5173`
 
 ## SSL/HTTPS Setup
 
 ### SSL Certificates
+
 For SSL deployment, create an `ssl` directory with certificates:
 
 ```bash
@@ -308,6 +321,7 @@ cp your-key.pem ssl/
 ```
 
 ### SSL Configuration
+
 Use the `production-ssl` service in docker-compose:
 
 ```bash
@@ -317,10 +331,12 @@ docker-compose up production-ssl
 ## Monitoring and Logging
 
 ### Log Locations
+
 - **Access logs**: `/var/log/nginx/access.log`
 - **Error logs**: `/var/log/nginx/error.log`
 
 ### Log Format
+
 ```
 $remote_addr - $remote_user [$time_local] "$request" 
 $status $body_bytes_sent "$http_referer" 
@@ -328,6 +344,7 @@ $status $body_bytes_sent "$http_referer"
 ```
 
 ### Log Levels
+
 - **Production**: `warn` level
 - **Staging**: `debug` level
 - **Development**: Full logging
@@ -337,6 +354,7 @@ $status $body_bytes_sent "$http_referer"
 ### Common Issues
 
 #### Build Failures
+
 ```bash
 # Check build logs
 docker build -t timesafari:latest . 2>&1 | tee build.log
@@ -349,6 +367,7 @@ docker run --rm timesafari:latest npm list --depth=0
 ```
 
 #### Container Won't Start
+
 ```bash
 # Check container logs
 docker logs <container_id>
@@ -361,6 +380,7 @@ netstat -tulpn | grep :80
 ```
 
 #### Environment Variables Not Set
+
 ```bash
 # Check environment in container
 docker exec <container_id> env | grep VITE_
@@ -373,6 +393,7 @@ cat .env.production
 ```
 
 #### Performance Issues
+
 ```bash
 # Check container resources
 docker stats <container_id>
@@ -387,6 +408,7 @@ docker exec <container_id> tail -f /var/log/nginx/access.log
 ### Debug Commands
 
 #### Container Debugging
+
 ```bash
 # Enter running container
 docker exec -it <container_id> /bin/sh
@@ -399,6 +421,7 @@ docker exec <container_id> ls -la /usr/share/nginx/html
 ```
 
 #### Network Debugging
+
 ```bash
 # Check container network
 docker network inspect bridge
@@ -413,6 +436,7 @@ docker exec <container_id> nslookup google.com
 ## Production Deployment
 
 ### Recommended Production Setup
+
 1. **Use specific version tags**: `timesafari:1.0.0`
 2. **Implement health checks**: Already included
 3. **Configure proper logging**: Use external log aggregation
@@ -420,6 +444,7 @@ docker exec <container_id> nslookup google.com
 5. **Use Docker secrets**: For sensitive data
 
 ### Production Commands
+
 ```bash
 # Build with specific version
 docker build -t timesafari:1.0.0 .
@@ -442,6 +467,7 @@ docker run -d --name timesafari -p 80:80 --restart unless-stopped --env-file .en
 ## Development Workflow
 
 ### Local Development
+
 ```bash
 # Start development environment
 ./docker/run.sh dev
@@ -454,6 +480,7 @@ docker-compose down dev
 ```
 
 ### Testing Changes
+
 ```bash
 # Build and test staging
 ./docker/run.sh staging
@@ -463,6 +490,7 @@ docker-compose down dev
 ```
 
 ### Continuous Integration
+
 ```bash
 # Build and test in CI
 docker build -t timesafari:test .
@@ -479,6 +507,7 @@ docker rm timesafari-test
 ## Best Practices
 
 ### Security
+
 - Always use non-root users
 - Keep base images updated
 - Scan images for vulnerabilities
@@ -486,6 +515,7 @@ docker rm timesafari-test
 - Implement proper access controls
 
 ### Performance
+
 - Use multi-stage builds
 - Optimize layer caching
 - Minimize image size
@@ -493,6 +523,7 @@ docker rm timesafari-test
 - Implement proper caching
 
 ### Monitoring
+
 - Use health checks
 - Monitor resource usage
 - Set up log aggregation
@@ -500,8 +531,9 @@ docker rm timesafari-test
 - Use proper error handling
 
 ### Maintenance
+
 - Regular security updates
 - Monitor for vulnerabilities
 - Keep dependencies updated
 - Document configuration changes
-- Test deployment procedures 
\ No newline at end of file
+- Test deployment procedures
diff --git a/electron/README-BUILDING.md b/electron/README-BUILDING.md
index baf3bd17..5b6e33be 100644
--- a/electron/README-BUILDING.md
+++ b/electron/README-BUILDING.md
@@ -18,6 +18,7 @@ This guide covers building and running the TimeSafari Electron application for d
 ## Quick Start
 
 ### Development Mode
+
 ```bash
 # Start development server
 npm run build:electron:dev
@@ -28,6 +29,7 @@ npm run electron:start
 ```
 
 ### Production Builds
+
 ```bash
 # Build for current platform
 npm run build:electron:prod
@@ -48,16 +50,19 @@ npm run build:electron:deb       # Linux DEB package
 The Electron app enforces single instance operation to prevent database conflicts and resource contention:
 
 ### Implementation
+
 - Uses Electron's built-in `app.requestSingleInstanceLock()`
 - Second instances exit immediately with user-friendly message
 - Existing instance focuses and shows informational dialog
 
 ### Behavior
+
 - **First instance**: Starts normally and acquires lock
 - **Second instance**: Detects existing instance, exits immediately
 - **User experience**: Clear messaging about single instance requirement
 
 ### Benefits
+
 - Prevents database corruption from concurrent access
 - Avoids resource conflicts
 - Maintains data integrity
@@ -66,6 +71,7 @@ The Electron app enforces single instance operation to prevent database conflict
 ## Build Configuration
 
 ### Environment Modes
+
 ```bash
 # Development (default)
 npm run build:electron:dev
@@ -78,6 +84,7 @@ npm run build:electron:prod
 ```
 
 ### Platform-Specific Builds
+
 ```bash
 # Windows
 npm run build:electron:windows:dev
@@ -96,6 +103,7 @@ npm run build:electron:linux:prod
 ```
 
 ### Package Types
+
 ```bash
 # Linux AppImage
 npm run build:electron:appimage:dev
@@ -116,26 +124,31 @@ npm run build:electron:deb:prod
 ## Platform-Specific Requirements
 
 ### Windows
+
 - Windows 10+ (64-bit)
 - Visual Studio Build Tools (for native modules)
 
 ### macOS
+
 - macOS 10.15+ (Catalina)
 - Xcode Command Line Tools
 - Code signing certificate (for distribution)
 
 ### Linux
+
 - Ubuntu 18.04+ / Debian 10+ / CentOS 7+
 - Development headers for native modules
 
 ## Database Configuration
 
 ### SQLite Integration
+
 - Uses native Node.js SQLite3 for Electron
 - Database stored in user's app data directory
 - Automatic migration from IndexedDB (if applicable)
 
 ### Single Instance Protection
+
 - File-based locking prevents concurrent database access
 - Automatic cleanup on app exit
 - Graceful handling of lock conflicts
@@ -143,11 +156,13 @@ npm run build:electron:deb:prod
 ## Security Features
 
 ### Content Security Policy
+
 - Strict CSP in production builds
 - Development mode allows localhost connections
 - Automatic configuration based on build mode
 
 ### Auto-Updater
+
 - Disabled in development mode
 - Production builds check for updates automatically
 - AppImage builds skip update checks
@@ -157,6 +172,7 @@ npm run build:electron:deb:prod
 ### Common Issues
 
 #### Build Failures
+
 ```bash
 # Clean and rebuild
 npm run clean:electron
@@ -164,6 +180,7 @@ npm run build:electron:dev
 ```
 
 #### Native Module Issues
+
 ```bash
 # Rebuild native modules
 cd electron
@@ -171,16 +188,19 @@ npm run electron:rebuild
 ```
 
 #### Single Instance Conflicts
+
 - Ensure no other TimeSafari instances are running
 - Check for orphaned processes: `ps aux | grep electron`
 - Restart system if necessary
 
 #### Database Issues
+
 - Check app data directory permissions
 - Verify SQLite database integrity
 - Clear app data if corrupted
 
 ### Debug Mode
+
 ```bash
 # Enable debug logging
 DEBUG=* npm run build:electron:dev
@@ -203,6 +223,7 @@ electron/
 ## Development Workflow
 
 1. **Start Development**
+
    ```bash
    npm run build:electron:dev
    ```
@@ -212,11 +233,13 @@ electron/
    - Changes auto-reload in development
 
 3. **Test Build**
+
    ```bash
    npm run build:electron:test
    ```
 
 4. **Production Build**
+
    ```bash
    npm run build:electron:prod
    ```
@@ -224,16 +247,19 @@ electron/
 ## Performance Considerations
 
 ### Memory Usage
+
 - Monitor renderer process memory
 - Implement proper cleanup in components
 - Use efficient data structures
 
 ### Startup Time
+
 - Lazy load non-critical modules
 - Optimize database initialization
 - Minimize synchronous operations
 
 ### Database Performance
+
 - Use transactions for bulk operations
 - Implement proper indexing
 - Monitor query performance
@@ -251,16 +277,19 @@ electron/
 ## Deployment
 
 ### Distribution
+
 - Windows: `.exe` installer
 - macOS: `.dmg` disk image
 - Linux: `.AppImage` or `.deb` package
 
 ### Code Signing
+
 - Windows: Authenticode certificate
 - macOS: Developer ID certificate
 - Linux: GPG signing (optional)
 
 ### Auto-Updates
+
 - Configured for production builds
 - Disabled for development and AppImage
 - Handles update failures gracefully
@@ -269,4 +298,4 @@ electron/
 
 **Last Updated**: 2025-07-11  
 **Version**: 1.0.3-beta  
-**Status**: Production Ready 
\ No newline at end of file
+**Status**: Production Ready
diff --git a/electron/README.md b/electron/README.md
index 6182fa83..89177fea 100644
--- a/electron/README.md
+++ b/electron/README.md
@@ -56,21 +56,25 @@ npm run build:electron:dmg:prod
 ```
 
 **Stage 1: Web Build**
+
 - Vite builds web assets with Electron configuration
 - Environment variables loaded based on build mode
 - Assets optimized for desktop application
 
 **Stage 2: Capacitor Sync**
+
 - Copies web assets to Electron app directory
 - Syncs Capacitor configuration and plugins
 - Prepares native module bindings
 
 **Stage 3: TypeScript Compile**
+
 - Compiles Electron main process TypeScript
 - Rebuilds native modules for target platform
 - Generates production-ready JavaScript
 
 **Stage 4: Package Creation**
+
 - Creates platform-specific installers
 - Generates distribution packages
 - Signs applications (when configured)
@@ -82,6 +86,7 @@ npm run build:electron:dmg:prod
 **Purpose**: Local development and testing
 **Command**: `npm run build:electron:dev`
 **Features**:
+
 - Hot reload enabled
 - Debug tools available
 - Development logging
@@ -92,6 +97,7 @@ npm run build:electron:dmg:prod
 **Purpose**: Staging and testing environments
 **Command**: `npm run build:electron -- --mode test`
 **Features**:
+
 - Test API endpoints
 - Staging configurations
 - Optimized for testing
@@ -102,6 +108,7 @@ npm run build:electron:dmg:prod
 **Purpose**: Production deployment
 **Command**: `npm run build:electron -- --mode production`
 **Features**:
+
 - Production optimizations
 - Code minification
 - Security hardening
@@ -116,6 +123,7 @@ npm run build:electron:dmg:prod
 **Command**: `npm run build:electron:windows:prod`
 
 **Features**:
+
 - NSIS installer with custom options
 - Desktop and Start Menu shortcuts
 - Elevation permissions for installation
@@ -128,6 +136,7 @@ npm run build:electron:dmg:prod
 **Command**: `npm run build:electron:mac:prod`
 
 **Features**:
+
 - Universal binary (x64 + arm64)
 - DMG installer with custom branding
 - App Store compliance (when configured)
@@ -140,6 +149,7 @@ npm run build:electron:dmg:prod
 **Command**: `npm run build:electron:linux:prod`
 
 **Features**:
+
 - AppImage for universal distribution
 - DEB package for Debian-based systems
 - RPM package for Red Hat-based systems
@@ -152,6 +162,7 @@ npm run build:electron:dmg:prod
 **Format**: Self-contained Linux executable
 **Command**: `npm run build:electron:appimage:prod`
 **Features**:
+
 - Single file distribution
 - No installation required
 - Portable across Linux distributions
@@ -162,6 +173,7 @@ npm run build:electron:dmg:prod
 **Format**: Debian package installer
 **Command**: `npm run build:electron:deb:prod`
 **Features**:
+
 - Native package management
 - Dependency resolution
 - System integration
@@ -172,6 +184,7 @@ npm run build:electron:dmg:prod
 **Format**: macOS disk image
 **Command**: `npm run build:electron:dmg:prod`
 **Features**:
+
 - Native macOS installer
 - Custom branding and layout
 - Drag-and-drop installation
@@ -293,6 +306,7 @@ Local Electron scripts for building:
 ### Environment Variables
 
 **Development**:
+
 ```bash
 VITE_API_URL=http://localhost:3000
 VITE_DEBUG=true
@@ -301,6 +315,7 @@ VITE_ENABLE_DEV_TOOLS=true
 ```
 
 **Testing**:
+
 ```bash
 VITE_API_URL=https://test-api.timesafari.com
 VITE_DEBUG=false
@@ -309,6 +324,7 @@ VITE_ENABLE_DEV_TOOLS=false
 ```
 
 **Production**:
+
 ```bash
 VITE_API_URL=https://api.timesafari.com
 VITE_DEBUG=false
@@ -347,6 +363,7 @@ electron/
 ### Common Issues
 
 **TypeScript Compilation Errors**:
+
 ```bash
 # Clean and rebuild
 npm run clean:electron
@@ -354,18 +371,21 @@ cd electron && npm run build
 ```
 
 **Native Module Issues**:
+
 ```bash
 # Rebuild native modules
 cd electron && npm run build
 ```
 
 **Asset Copy Issues**:
+
 ```bash
 # Verify Capacitor sync
 npx cap sync electron
 ```
 
 **Package Creation Failures**:
+
 ```bash
 # Check electron-builder configuration
 # Verify platform-specific requirements
@@ -375,16 +395,19 @@ npx cap sync electron
 ### Platform-Specific Issues
 
 **Windows**:
+
 - Ensure Windows Build Tools installed
 - Check NSIS installation
 - Verify code signing certificates
 
 **macOS**:
+
 - Install Xcode Command Line Tools
 - Configure code signing certificates
 - Check app notarization requirements
 
 **Linux**:
+
 - Install required packages (rpm-tools, etc.)
 - Check AppImage dependencies
 - Verify desktop integration
@@ -394,11 +417,13 @@ npx cap sync electron
 ### Build Performance
 
 **Parallel Builds**:
+
 - Use concurrent TypeScript compilation
 - Optimize asset copying
 - Minimize file system operations
 
 **Caching Strategies**:
+
 - Cache node_modules between builds
 - Cache compiled TypeScript
 - Cache web assets when unchanged
@@ -406,11 +431,13 @@ npx cap sync electron
 ### Runtime Performance
 
 **Application Startup**:
+
 - Optimize main process initialization
 - Minimize startup dependencies
 - Use lazy loading for features
 
 **Memory Management**:
+
 - Monitor memory usage
 - Implement proper cleanup
 - Optimize asset loading
@@ -420,16 +447,19 @@ npx cap sync electron
 ### Code Signing
 
 **Windows**:
+
 - Authenticode code signing
 - EV certificate for SmartScreen
 - Timestamp server configuration
 
 **macOS**:
+
 - Developer ID code signing
 - App notarization
 - Hardened runtime
 
 **Linux**:
+
 - GPG signing for packages
 - AppImage signing
 - Package verification
@@ -437,12 +467,14 @@ npx cap sync electron
 ### Security Hardening
 
 **Production Builds**:
+
 - Disable developer tools
 - Remove debug information
 - Enable security policies
 - Implement sandboxing
 
 **Update Security**:
+
 - Secure update channels
 - Package integrity verification
 - Rollback capabilities
@@ -496,4 +528,4 @@ npx cap sync electron
 **Status**: Production ready
 **Last Updated**: 2025-01-27
 **Version**: 1.0
-**Maintainer**: Matthew Raymer 
\ No newline at end of file
+**Maintainer**: Matthew Raymer
diff --git a/ios/App/app_privacy_manifest_fixer/CHANGELOG.md b/ios/App/app_privacy_manifest_fixer/CHANGELOG.md
index 0c8a036c..059adbf2 100644
--- a/ios/App/app_privacy_manifest_fixer/CHANGELOG.md
+++ b/ios/App/app_privacy_manifest_fixer/CHANGELOG.md
@@ -1,30 +1,38 @@
 ## 1.4.1
+
 - Fix macOS app re-signing issue.
 - Automatically enable Hardened Runtime in macOS codesign.
 - Add clean script.
 
 ## 1.4.0
+
 - Support for macOS app ([#9](https://github.com/crasowas/app_privacy_manifest_fixer/issues/9)).
 
 ## 1.3.11
+
 - Fix install issue by skipping `PBXAggregateTarget` ([#4](https://github.com/crasowas/app_privacy_manifest_fixer/issues/4)).
 
 ## 1.3.10
+
 - Fix app re-signing issue.
 - Enhance Build Phases script robustness.
 
 ## 1.3.9
+
 - Add log file output.
 
 ## 1.3.8
+
 - Add version info to privacy access report.
 - Remove empty tables from privacy access report.
 
 ## 1.3.7
+
 - Enhance API symbols analysis with strings tool.
 - Improve performance of API usage analysis.
 
 ## 1.3.5
+
 - Fix issue with inaccurate privacy manifest search.
 - Disable dependency analysis to force the script to run on every build.
 - Add placeholder for privacy access report.
@@ -32,27 +40,34 @@
 - Add examples for privacy access report.
 
 ## 1.3.0
+
 - Add privacy access report generation.
 
 ## 1.2.3
+
 - Fix issue with relative path parameter.
 - Add support for all application targets.
 
 ## 1.2.1
+
 - Fix backup issue with empty user templates directory.
 
 ## 1.2.0
+
 - Add uninstall script.
 
 ## 1.1.2
+
 - Remove `Templates/.gitignore` to track `UserTemplates`.
 - Fix incorrect use of `App.xcprivacy` template in `App.framework`.
 
 ## 1.1.0
+
 - Add logs for latest release fetch failure.
 - Fix issue with converting published time to local time.
 - Disable showing environment variables in the build log.
 - Add `--install-builds-only` command line option.
 
 ## 1.0.0
-- Initial version.
\ No newline at end of file
+
+- Initial version.
diff --git a/ios/App/app_privacy_manifest_fixer/README.md b/ios/App/app_privacy_manifest_fixer/README.md
index 3296b771..d3ef32b8 100644
--- a/ios/App/app_privacy_manifest_fixer/README.md
+++ b/ios/App/app_privacy_manifest_fixer/README.md
@@ -150,6 +150,7 @@ The privacy manifest templates are stored in the [`Templates`](https://github.co
 ### Template Types
 
 The templates are categorized as follows:
+
 - **AppTemplate.xcprivacy**: A privacy manifest template for the app.
 - **FrameworkTemplate.xcprivacy**: A generic privacy manifest template for frameworks.
 - **FrameworkName.xcprivacy**: A privacy manifest template for a specific framework, available only in the `Templates/UserTemplates` directory.
@@ -157,20 +158,24 @@ The templates are categorized as follows:
 ### Template Priority
 
 For an app, the priority of privacy manifest templates is as follows:
+
 - `Templates/UserTemplates/AppTemplate.xcprivacy` > `Templates/AppTemplate.xcprivacy`
 
 For a specific framework, the priority of privacy manifest templates is as follows:
+
 - `Templates/UserTemplates/FrameworkName.xcprivacy` > `Templates/UserTemplates/FrameworkTemplate.xcprivacy` > `Templates/FrameworkTemplate.xcprivacy`
 
 ### Default Templates
 
 The default templates are located in the `Templates` root directory and currently include the following templates:
+
 - `Templates/AppTemplate.xcprivacy`
 - `Templates/FrameworkTemplate.xcprivacy`
 
 These templates will be modified based on the API usage analysis results, especially the `NSPrivacyAccessedAPIType` entries, to generate new privacy manifests for fixes, ensuring compliance with App Store requirements.
 
 **If adjustments to the privacy manifest template are needed, such as in the following scenarios, avoid directly modifying the default templates. Instead, use a custom template. If a custom template with the same name exists, it will take precedence over the default template for fixes.**
+
 - Generating a non-compliant privacy manifest due to inaccurate API usage analysis.
 - Modifying the reason declared in the template.
 - Adding declarations for collected data.
@@ -198,6 +203,7 @@ The privacy access API categories and their associated declared reasons in `Fram
 ### Custom Templates
 
 To create custom templates, place them in the `Templates/UserTemplates` directory with the following structure:
+
 - `Templates/UserTemplates/AppTemplate.xcprivacy`
 - `Templates/UserTemplates/FrameworkTemplate.xcprivacy`
 - `Templates/UserTemplates/FrameworkName.xcprivacy`
@@ -205,6 +211,7 @@ To create custom templates, place them in the `Templates/UserTemplates` director
 Among these templates, only `FrameworkTemplate.xcprivacy` will be modified based on the API usage analysis results to adjust the `NSPrivacyAccessedAPIType` entries, thereby generating a new privacy manifest for framework fixes. The other templates will remain unchanged and will be directly used for fixes.
 
 **Important Notes:**
+
 - The template for a specific framework must follow the naming convention `FrameworkName.xcprivacy`, where `FrameworkName` should match the name of the framework. For example, the template for `Flutter.framework` should be named `Flutter.xcprivacy`.
 - For macOS frameworks, the naming convention should be `FrameworkName.Version.xcprivacy`, where the version name is added to distinguish different versions. For a single version macOS framework, the `Version` is typically `A`.
 - The name of an SDK may not exactly match the name of the framework. To determine the correct framework name, check the `Frameworks` directory in the application bundle after building the project.
diff --git a/ios/App/app_privacy_manifest_fixer/README.zh-CN.md b/ios/App/app_privacy_manifest_fixer/README.zh-CN.md
index 19bc9a8b..39db4cb3 100644
--- a/ios/App/app_privacy_manifest_fixer/README.zh-CN.md
+++ b/ios/App/app_privacy_manifest_fixer/README.zh-CN.md
@@ -40,7 +40,7 @@
    ```shell
    sh install.sh <project_path>
    ```  
-   
+
    - 如果是 Flutter 项目，`project_path`应为 Flutter 项目中的`ios/macos`目录路径。
    - 重复运行安装命令时，工具会先移除现有安装（如果有）。若需修改命令行选项，只需重新运行安装命令，无需先卸载。
 
@@ -150,6 +150,7 @@ sh clean.sh
 ### 模板类型
 
 模板分为以下几类：
+
 - **AppTemplate.xcprivacy**：App 的隐私清单模板。
 - **FrameworkTemplate.xcprivacy**：通用的 Framework 隐私清单模板。
 - **FrameworkName.xcprivacy**：特定的 Framework 隐私清单模板，仅在`Templates/UserTemplates`目录有效。
@@ -157,20 +158,24 @@ sh clean.sh
 ### 模板优先级
 
 对于 App，隐私清单模板的优先级如下：
+
 - `Templates/UserTemplates/AppTemplate.xcprivacy` > `Templates/AppTemplate.xcprivacy`
 
 对于特定的 Framework，隐私清单模板的优先级如下：
+
 - `Templates/UserTemplates/FrameworkName.xcprivacy` > `Templates/UserTemplates/FrameworkTemplate.xcprivacy` > `Templates/FrameworkTemplate.xcprivacy`
 
 ### 默认模板
 
 默认模板位于`Templates`根目录，目前包括以下模板：
+
 - `Templates/AppTemplate.xcprivacy`
 - `Templates/FrameworkTemplate.xcprivacy`
 
 这些模板将根据 API 使用分析结果进行修改，特别是`NSPrivacyAccessedAPIType`条目将被调整，以生成新的隐私清单用于修复，确保符合 App Store 要求。
 
 **如果需要调整隐私清单模板，例如以下场景，请避免直接修改默认模板，而是使用自定义模板。如果存在相同名称的自定义模板，它将优先于默认模板用于修复。**
+
 - 由于 API 使用分析结果不准确，生成了不合规的隐私清单。
 - 需要修改模板中声明的理由。
 - 需要声明收集的数据。
@@ -198,6 +203,7 @@ sh clean.sh
 ### 自定义模板
 
 要创建自定义模板，请将其放在`Templates/UserTemplates`目录，结构如下：
+
 - `Templates/UserTemplates/AppTemplate.xcprivacy`
 - `Templates/UserTemplates/FrameworkTemplate.xcprivacy`
 - `Templates/UserTemplates/FrameworkName.xcprivacy`
@@ -205,6 +211,7 @@ sh clean.sh
 在这些模板中，只有`FrameworkTemplate.xcprivacy`会根据 API 使用分析结果对`NSPrivacyAccessedAPIType`条目进行调整，以生成新的隐私清单用于 Framework 修复。其他模板保持不变，将直接用于修复。
 
 **重要说明：**
+
 - 特定的 Framework 模板必须遵循命名规范`FrameworkName.xcprivacy`，其中`FrameworkName`需与 Framework 的名称匹配。例如`Flutter.framework`的模板应命名为`Flutter.xcprivacy`。
 - 对于 macOS Framework，应遵循命名规范`FrameworkName.Version.xcprivacy`，额外增加版本名称用于区分不同的版本。对于单一版本的 macOS Framework，`Version`通常为`A`。
 - SDK 的名称可能与 Framework 的名称不完全一致。要确定正确的 Framework 名称，请在构建项目后检查 App 包中的`Frameworks`目录。
@@ -229,7 +236,7 @@ sh Report/report.sh <app_path> <report_output_path>
 |------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------|
 | ![Original App Report](https://img.crasowas.dev/app_privacy_manifest_fixer/20241218230746.png) | ![Fixed App Report](https://img.crasowas.dev/app_privacy_manifest_fixer/20241218230822.png) |
 
-## 💡 重要考量 
+## 💡 重要考量
 
 - 如果最新版本的 SDK 支持隐私清单，请尽可能升级，以避免不必要的风险。
 - 此工具仅为临时解决方案，不应替代正确的 SDK 管理实践。
diff --git a/resources/README.md b/resources/README.md
index a3b9f803..d8290cd3 100644
--- a/resources/README.md
+++ b/resources/README.md
@@ -27,12 +27,14 @@ resources/
 ## Asset Requirements
 
 ### Icon Requirements
+
 - **Format**: PNG
 - **Size**: 1024x1024 pixels minimum
 - **Background**: Transparent or solid color
 - **Content**: App logo/icon
 
 ### Splash Screen Requirements
+
 - **Format**: PNG
 - **Size**: 1242x2688 pixels (iPhone 11 Pro Max size)
 - **Background**: Solid color or gradient
@@ -70,10 +72,11 @@ Asset generation is configured in `capacitor-assets.config.json` at the project
 ## Build Integration
 
 Assets are automatically generated as part of the build process:
+
 - `npm run build:android` - Generates Android assets
 - `npm run build:ios` - Generates iOS assets
 - `npm run build:web` - Generates web assets
 
 **Author**: Matthew Raymer
 **Date**: 2025-01-27
-**Status**: ✅ **ACTIVE** - Asset management system implemented 
\ No newline at end of file
+**Status**: ✅ **ACTIVE** - Asset management system implemented
diff --git a/scripts/README.md b/scripts/README.md
index 71f61de4..f5aaf629 100644
--- a/scripts/README.md
+++ b/scripts/README.md
@@ -31,6 +31,7 @@ All scripts automatically handle environment variables for different build types
 #### Automatic Environment Setup
 
 Each script automatically:
+
 1. **Sets platform-specific variables** based on build type
 2. **Gets git hash** for versioning (`VITE_GIT_HASH`)
 3. **Creates application directories** (`~/.local/share/TimeSafari/timesafari`)
@@ -104,6 +105,7 @@ exit 0
 ## Benefits of Unification
 
 ### Before (Redundant)
+
 ```bash
 # Each script had 50+ lines of duplicate code:
 readonly RED='\033[0;31m'
@@ -121,6 +123,7 @@ export VITE_PWA_ENABLED=false
 ```
 
 ### After (Unified)
+
 ```bash
 # Each script is now ~20 lines of focused logic:
 source "$(dirname "$0")/common.sh"
@@ -133,6 +136,7 @@ print_footer "Script Title"
 ## Usage Examples
 
 ### Running Tests
+
 ```bash
 # Run all tests
 ./scripts/test-all.sh
@@ -189,6 +193,7 @@ export NODE_ENV=production
 ```
 
 ### .env File Support
+
 Scripts automatically load variables from `.env` files if they exist:
 
 ```bash
@@ -199,6 +204,7 @@ CUSTOM_VAR=value
 ```
 
 ### Environment Validation
+
 Required environment variables can be validated:
 
 ```bash
@@ -207,6 +213,7 @@ validate_env_vars "VITE_API_URL" "VITE_DEBUG" || exit 1
 ```
 
 ### Environment Inspection
+
 View current environment variables with the `--env` flag:
 
 ```bash
@@ -277,4 +284,4 @@ To verify the common utilities work correctly:
 - Timing information is automatically collected for all operations
 - Build artifacts are cleaned up automatically
 - No redundant command execution or file operations
-- Environment variables are set efficiently with minimal overhead
\ No newline at end of file
+- Environment variables are set efficiently with minimal overhead
diff --git a/scripts/git-hooks/README.md b/scripts/git-hooks/README.md
index d335b3b2..4f6cb126 100644
--- a/scripts/git-hooks/README.md
+++ b/scripts/git-hooks/README.md
@@ -5,22 +5,26 @@ This directory contains custom Git hooks for the TimeSafari project.
 ## Debug Code Checker Hook
 
 ### Overview
+
 The `pre-commit` hook automatically checks for debug code when committing to protected branches (master, main, production, release). This prevents debug statements from accidentally reaching production code.
 
 ### How It Works
+
 1. **Branch Detection**: Only runs on protected branches (configurable)
 2. **File Filtering**: Automatically skips test files, scripts, and documentation
 3. **Pattern Matching**: Detects common debug patterns using regex
 4. **Commit Prevention**: Blocks commits containing debug code
 
 ### Protected Branches (Default)
+
 - `master`
-- `main` 
+- `main`
 - `production`
 - `release`
 - `stable`
 
 ### Debug Patterns Detected
+
 - **Console statements**: `console.log`, `console.debug`, `console.error`
 - **Template debug**: `Debug:`, `debug:` in Vue templates
 - **Debug constants**: `DEBUG_`, `debug_` variables
@@ -30,6 +34,7 @@ The `pre-commit` hook automatically checks for debug code when committing to pro
 - **Debug TODOs**: `TODO debug`, `FIXME debug`
 
 ### Files Automatically Skipped
+
 - Test files: `*.test.js`, `*.spec.ts`, `*.test.vue`
 - Scripts: `scripts/` directory
 - Test directories: `test-*` directories
@@ -38,49 +43,61 @@ The `pre-commit` hook automatically checks for debug code when committing to pro
 - IDE files: `.cursor/` directory
 
 ### Configuration
+
 Edit `.git/hooks/debug-checker.config` to customize:
+
 - Protected branches
 - Debug patterns
 - Skip patterns
 - Logging level
 
 ### Testing the Hook
+
 Run the test script to verify the hook works:
+
 ```bash
 ./scripts/test-debug-hook.sh
 ```
 
 ### Manual Testing
+
 1. Make changes to a file with debug code
 2. Stage the file: `git add <filename>`
 3. Try to commit: `git commit -m 'test'`
 4. Hook should prevent commit if debug code is found
 
 ### Bypassing the Hook (Emergency)
+
 If you absolutely need to commit debug code to a protected branch:
+
 ```bash
 git commit --no-verify -m "emergency: debug code needed"
 ```
+
 ⚠️ **Warning**: This bypasses all pre-commit hooks. Use sparingly and only in emergencies.
 
 ### Troubleshooting
 
 #### Hook not running
+
 - Ensure the hook is executable: `chmod +x .git/hooks/pre-commit`
 - Check if you're on a protected branch
 - Verify the hook file exists and has correct permissions
 
 #### False positives
+
 - Add legitimate debug patterns to skip patterns in config
 - Use proper logging levels (`logger.info`, `logger.debug`) instead of console
 - Move debug code to feature branches first
 
 #### Hook too strict
+
 - Modify debug patterns in config file
 - Add more file types to skip patterns
 - Adjust protected branch list
 
 ### Best Practices
+
 1. **Use feature branches** for development with debug code
 2. **Use proper logging** instead of console statements
 3. **Test thoroughly** before merging to protected branches
@@ -88,14 +105,18 @@ git commit --no-verify -m "emergency: debug code needed"
 5. **Keep config updated** as project needs change
 
 ### Integration with CI/CD
+
 This hook works locally. For CI/CD pipelines, consider:
+
 - Running the same checks in your build process
 - Adding ESLint rules for console statements
 - Using TypeScript strict mode
 - Adding debug code detection to PR checks
 
 ### Support
+
 If you encounter issues:
+
 1. Check the hook output for specific error messages
 2. Verify your branch is in the protected list
 3. Review the configuration file
diff --git a/test-playwright/README.md b/test-playwright/README.md
index 38ff5abf..b0a403fa 100644
--- a/test-playwright/README.md
+++ b/test-playwright/README.md
@@ -29,6 +29,7 @@ Tests are organized by feature area and numbered for execution order:
 ## Prerequisites
 
 1. Endorser server running locally (see TESTING.md for setup)
+
    ```bash
    git clone https://github.com/time-endorser/endorser-ch.git
    cd endorser-ch
@@ -37,10 +38,13 @@ Tests are organized by feature area and numbered for execution order:
    cp .env.local .env
    NODE_ENV=test-local npm run dev
    ```
+
 2. Playwright browsers installed:
+
    ```bash
    npx playwright install
    ```
+
 3. For mobile testing:
    - XCode (for iOS)
    - Android Studio or connected Android device
@@ -67,16 +71,19 @@ npx playwright test -c playwright.config-local.ts --trace on test-playwright/40-
 ### Test Environment Options
 
 1. Local Endorser Server (default):
+
    ```bash
    NODE_ENV=test-local npm run dev
    ```
 
 2. Global Test Server:
+
    ```bash
    VITE_DEFAULT_ENDORSER_API_SERVER=https://test-ledger.time.com npm run dev
    ```
 
 3. Minimal Test Data:
+
    ```bash
    rm ../endorser-ch-test-local.sqlite3
    NODE_ENV=test-local npm run flyway migrate
@@ -114,6 +121,7 @@ For more detailed troubleshooting, see TESTING.md.
 ## Contributing
 
 When adding new tests:
+
 1. Follow the existing naming convention
 2. Use testUtils.ts for common operations
 3. Add appropriate comments and documentation
@@ -124,4 +132,4 @@ When adding new tests:
 
 - [TESTING.md](./TESTING.md) - Detailed testing guide
 - [Playwright Documentation](https://playwright.dev/docs/intro)
-- Endorser server documentation for test setup 
\ No newline at end of file
+- Endorser server documentation for test setup
diff --git a/test-playwright/TESTING.md b/test-playwright/TESTING.md
index 7a173c65..3174c895 100644
--- a/test-playwright/TESTING.md
+++ b/test-playwright/TESTING.md
@@ -5,6 +5,7 @@ Start with [README.md](./README.md). This file has more details.
 ## Test User Setup
 
 ### Register New User on Test Server
+
 On the test server, User #0 has rights to register others. Import User #0 with this seed phrase:
 
 ```bash
@@ -18,6 +19,7 @@ This corresponds to: `did:ethr:0x0000694B58C2cC69658993A90D3840C560f2F51F`
 ## Manual Testing Steps
 
 ### Identity Management
+
 1. Create multiple identifiers:
    - Go to "Your Identity" screen
    - Click "Advanced"
@@ -96,10 +98,10 @@ npx playwright test -c playwright.config-local.ts test-playwright/60-new-activit
 ```
 
 This command allows you to:
+
 - **Run a specific test file**: `test-playwright/60-new-activity.spec.ts`
 - **Filter to a specific test**: `--grep "New offers for another user"` runs only tests with that name
 - **See the browser**: `--headed` opens the browser window so you can watch the test execute
 - **Use local config**: `-c playwright.config-local.ts` uses the local configuration file
 
 This is useful when you want to observe the testing process visually rather than running tests in headless mode. It's particularly helpful for debugging test failures or understanding how the application behaves during automated testing.
-