chore: removing extraneous documentation

2025-08-18 10:04:53 +00:00
parent b9b583a14e
commit 142c0c0e64
3 changed files with 0 additions and 1369 deletions
--- a/docs/development/performance-analysis-60-new-activity-test.md
+++ b/docs/development/performance-analysis-60-new-activity-test.md
@@ -1,881 +0,0 @@
 # Performance Analysis: 60-New-Activity Test
 **Date**: August 1, 2025 10:26:23 AM UTC
 **Test File**: `test-playwright/60-new-activity.spec.ts`
 **Analysis Type**: Performance Bottleneck Identification
 ## Executive Summary
 The 60-new-activity test revealed significant performance bottlenecks, with the
 `add-contact` action consuming 26.2% of total test time (4.21 seconds). Network
 requests totaled 1,088 calls during the test run, indicating potential
 optimization opportunities.
 **✅ MEASURED IMPROVEMENT**: After implementing batched feed updates with `nextTick()`, the test now completes in:
 - **Chromium**: 23.7s (48% improvement from 45+ seconds)
 - **Firefox**: 18.0s (60% improvement from 45+ seconds)
 **⚠️ PREDICTION**: The performance improvement is hypothesized to be due to reduced Vue reactivity triggers, but this has not been directly measured.
 ## Key Performance Metrics
 | Metric | Value | Impact |
 |--------|-------|--------|
 | **Total Test Duration** | 16.05 seconds | Baseline |
 | **Average Navigation Time** | 256ms | Acceptable |
 | **Network Requests** | 1,088 | High |
 | **Slowest Action** | add-contact (4.21s) | Critical |
 ## Detailed Performance Breakdown
 ### 🚨 Critical Performance Issues
 #### 1. **Add-Contact Action (4.21s, 26.2% of total time)**
 **Root Cause Analysis:**
 - Multiple network requests during contact validation
 - Complex DID parsing and validation
 - UI state management overhead
 - Database operations
 **Specific Bottlenecks:**
 ```typescript
 // From ContactsView.vue - addContact method
 private async addContact() {
  // 1. DID parsing and validation (slow)
  const did = this.parseDidFromInput();
  // 2. Database insert operation
  await this.$insertContact(did);
  // 3. Network request for visibility
  await setVisibilityUtil(did, true);
  // 4. UI state updates and re-renders
  this.updateContactList();
 }
 ```
 **Network Requests During Add-Contact:**
 - `POST /api/report/canSeeMe` - 150ms
 - `POST /api/report/cannotSeeMe` - 120ms
 - Database operations - 200ms
 - UI rendering - 300ms
 #### 2. **Switch-User Action (3.06s, 19.0% of total time)**
 **Root Cause Analysis:**
 - Authentication state management
 - Database queries for user data
 - UI component re-initialization
 - Network requests for user validation
 #### 3. **Import-User-Account Action (1.85s, 11.5% of total time)**
 **Root Cause Analysis:**
 - File system operations
 - DID validation and parsing
 - Database import operations
 - UI state synchronization
 ## Network Request Analysis
 ### 🔍 **Where the 1,088 Requests Come From**
 The performance collector tracks **ALL** network responses, not just API calls. Here's the breakdown:
 | Request Category | Count | Percentage | Impact |
 |------------------|-------|------------|--------|
 | **Network Responses** | 887 | 81.5% | High frequency, low impact |
 | **Database Operations** | 312 | 28.6% | Medium frequency, medium impact |
 | **API Calls** | 70 | 6.4% | Low frequency, **HIGH IMPACT** |
 | **Development Tools** | 68 | 6.2% | Development only |
 | **Static Assets** | 32 | 2.9% | Cached after first load |
 | **External Resources** | 7 | 0.6% | Third-party dependencies |
 **⚠️ Note**: The "UI Updates (Vue Reactivity)" categorization is an estimation, not a measured metric. The performance collector does not track Vue-specific reactivity triggers.
 ### 🎯 **Detailed Breakdown**
 #### **API Calls (The ones we care about)**
 - **`/api/report/canSeeMe`** - 25 calls (35.7% of API calls)
 - **`/api/report/cannotSeeMe`** - 20 calls (28.6% of API calls)
 - **`/api/contacts`** - 15 calls (21.4% of API calls)
 - **`/api/users`** - 10 calls (14.3% of API calls)
 #### **Database Operations**
 - **`indexeddb://contacts`** - 156 operations (50.0% of DB calls)
 - **`indexeddb://users`** - 89 operations (28.5% of DB calls)
 - **`indexeddb://offers`** - 67 operations (21.5% of DB calls)
 #### **UI Updates (Vue Reactivity)**
 - **`vue://component-update`** - 887 updates (100% of UI calls)
 ### 🚨 **Key Insights**
 1. **UI reactivity is the biggest culprit** - 887 Vue component updates
 2. **Database operations are frequent** - 312 IndexedDB operations
 3. **API calls are low frequency but high impact** - Only 70 calls but cause major delays
 4. **Development tools add noise** - 68 requests from hot reload, etc.
 ## Vue Reactivity Analysis
 ### 🔍 **Components Involved in the Test**
 Based on the test flow, these components are responsible for the 887 UI updates:
 #### **Primary Components (High Reactivity)**
 1. **`HomeView.vue`** - Main container component
   - **Reactive Properties**: `feedData`, `activeDid`, `isFeedLoading`, `numNewOffersToUser`
   - **Update Triggers**: Feed loading, user switching, offer creation
   - **Estimated Updates**: ~300 updates during test
 2. **`ActivityListItem.vue`** - Individual activity display
   - **Reactive Properties**: `record`, `lastViewedClaimId`, `activeDid`
   - **Update Triggers**: Record changes, user switching, offer status updates
   - **Estimated Updates**: ~200 updates (multiple items in feed)
 3. **`ContactsView.vue`** - Contact management interface
   - **Reactive Properties**: `contacts`, `contactInput`, `contactsSelected`, `givenByMeDescriptions`
   - **Update Triggers**: Contact addition, selection changes, give amounts
   - **Estimated Updates**: ~150 updates during contact operations
 #### **Secondary Components (Medium Reactivity)**
 4. **`ContactListItem.vue`** - Individual contact display
   - **Reactive Properties**: `contact`, `isSelected`, `showActions`, `givenAmounts`
   - **Update Triggers**: Selection changes, give amount updates
   - **Estimated Updates**: ~100 updates
 5. **`ContactInputForm.vue`** - Contact input interface
   - **Reactive Properties**: `modelValue`, `isRegistered`, `inputValidation`
   - **Update Triggers**: Input changes, validation updates
   - **Estimated Updates**: ~50 updates
 6. **`OfferDialog.vue`** - Offer creation dialog
   - **Reactive Properties**: `isOpen`, `offerData`, `validationState`
   - **Update Triggers**: Dialog state, form validation
   - **Estimated Updates**: ~50 updates
 #### **Utility Components (Low Reactivity)**
 7. **`QuickNav.vue`** - Navigation component
 8. **`TopMessage.vue`** - Message display
 9. **`OnboardingDialog.vue`** - Onboarding flow
 10. **`GiftedDialog.vue`** - Gift creation interface
 ### 🎯 **Specific Reactivity Issues Identified**
 #### **1. HomeView.vue - Feed Data Reactivity**
 ```typescript
 // Current: Highly reactive feed data with individual push operations
 for (const record of records) {
  const processedRecord = await this.processRecord(record);
  if (processedRecord) {
    this.feedData.push(processedRecord); // Triggers reactivity for each push
  }
 }
 // Optimized: Batched updates with nextTick
 const processedRecords: GiveRecordWithContactInfo[] = [];
 for (const record of records) {
  const processedRecord = await this.processRecord(record);
  if (processedRecord) {
    processedRecords.push(processedRecord);
  }
 }
 // Single reactivity trigger for all records
 await nextTick(() => {
  this.feedData.push(...processedRecords);
 });
 ```
 #### **2. ActivityListItem.vue - Record Reactivity**
 ```typescript
 // Current: Deep reactive record object
@Prop() record!: GiveRecordWithContactInfo;
 // Problem: Any change to record triggers component re-render
 // Solution: Use computed properties for derived data
 get displayName() {
  return this.record.issuer.displayName;
 }
 ```
 #### **3. ContactsView.vue - Contact List Reactivity**
 ```typescript
 // Current: Reactive contact arrays and objects
 contacts: Array<Contact> = [];
 givenByMeDescriptions: Record<string, string> = {};
 // Problem: Contact updates trigger cascading re-renders
 // Solution: Use shallowRef and computed properties
 contacts = shallowRef<Array<Contact>>([]);
 ```
 #### **4. ContactListItem.vue - Selection Reactivity**
 ```typescript
 // Current: Reactive selection state
 :is-selected="contactsSelected.includes(contact.did)"
 // Problem: Array operations trigger re-renders
 // Solution: Use Set for efficient lookups
 const selectedSet = computed(() => new Set(contactsSelected.value));
 ```
 ### 🚀 **Vue Reactivity Optimization Strategies**
 #### **1. Use `shallowRef` for Large Objects**
 ```typescript
 // Before: Deep reactive objects
 const feedData = ref<GiveRecordWithContactInfo[]>([]);
 // After: Shallow reactive arrays
 const feedData = shallowRef<GiveRecordWithContactInfo[]>([]);
 ```
 #### **2. Implement `v-memo` for Expensive Components**
 ```vue
 <!-- Before: Always re-renders -->
 <ActivityListItem
  v-for="record in feedData"
  :key="record.jwtId"
  :record="record"
 />
 <!-- After: Memoized re-renders -->
 <ActivityListItem
  v-for="record in feedData"
  :key="record.jwtId"
  v-memo="[record.jwtId, record.issuerDid, record.recipientDid]"
  :record="record"
 />
 ```
 #### **3. Use Computed Properties Efficiently**
 ```typescript
 // Before: Inline computed values
 const displayName = record.issuer.displayName;
 // After: Cached computed properties
 const displayName = computed(() => record.issuer.displayName);
 ```
 #### **4. Batch DOM Updates with `nextTick`**
 ```typescript
 // Before: Multiple synchronous updates
 this.feedData.push(newRecord);
 this.isFeedLoading = false;
 this.numNewOffersToUser++;
 // After: Batched updates
 await nextTick(() => {
  this.feedData.push(newRecord);
  this.isFeedLoading = false;
  this.numNewOffersToUser++;
 });
 ```
 #### **5. Use `v-once` for Static Content**
 ```vue
 <!-- Before: Always reactive -->
 <h1>{{ AppString.APP_NAME }}</h1>
 <!-- After: Static content -->
 <h1 v-once>{{ AppString.APP_NAME }}</h1>
 ```
 ## ✅ **Implemented Optimization**
 ### **HomeView.vue Feed Data Batching**
 **Problem**: The `processFeedResults` method was triggering Vue reactivity for each individual record push:
 ```typescript
 // Before: Individual reactivity triggers
 for (const record of records) {
  const processedRecord = await this.processRecord(record);
  if (processedRecord) {
    this.feedData.push(processedRecord); // Triggers reactivity for each push
  }
 }
 ```
 **Solution**: Batched updates using `nextTick()` to reduce reactivity triggers:
 ```typescript
 // After: Single reactivity trigger
 const processedRecords: GiveRecordWithContactInfo[] = [];
 for (const record of records) {
  const processedRecord = await this.processRecord(record);
  if (processedRecord) {
    processedRecords.push(processedRecord);
  }
 }
 // Single reactivity trigger for all records
 await nextTick(() => {
  this.feedData.push(...processedRecords);
 });
 ```
 **Impact**:
 - **✅ Measured**: Test completion time improved by 48-60% (23.7s vs 45+ seconds)
 - **✅ Measured**: Eliminated timeout issues in both Chromium and Firefox
 - **❌ Predicted**: Reduced Vue reactivity triggers from individual `push()` operations to batched updates
 - **⚠️ Note**: Vue reactivity metrics not captured by current performance collector
 ## 🔍 **Measurement Gaps & Next Steps**
 ### **What We Actually Measured vs. What We Predicted**
 #### **✅ Measured Data (Real Evidence)**
 1. **Test Duration Improvement**:
   - Before: 45+ seconds (timeout)
   - After: 23.7s (Chromium), 18.0s (Firefox)
   - **Source**: Playwright test execution times
 2. **Timeout Elimination**:
   - Before: Tests consistently timed out
   - After: Tests complete successfully
   - **Source**: Test execution logs
 3. **Network Request Counts**:
   - Total: 1,088 network responses
   - **Source**: Performance collector network tracking
 #### **❌ Predicted Data (Hypotheses)**
 1. **Vue Reactivity Reduction**:
   - Claim: "887 individual updates reduced to 1 batch update"
   - **Status**: Estimation based on code analysis, not measured
   - **Source**: Code review of `nextTick()` implementation
 2. **Component Re-render Reduction**:
   - Claim: Reduced component updates in ActivityListItem
   - **Status**: Predicted, not measured
   - **Source**: Vue reactivity theory
 #### **What We Need to Measure**
 To confirm the Vue reactivity impact, we need to add specific metrics to the performance collector:
 #### **1. Vue Reactivity Metrics**
 ```typescript
 // Add to PerformanceCollector
 private vueMetrics = {
  componentUpdates: 0,
  reactivityTriggers: 0,
  watcherExecutions: 0,
  computedPropertyRecomputations: 0
 };
 ```
 **Implementation Strategy**:
 - Inject Vue DevTools hooks into the page
 - Track `beforeUpdate` and `updated` lifecycle hooks
 - Monitor `watch` and `computed` property executions
 - Count reactive property changes
 #### **2. DOM Mutation Tracking**
 ```typescript
 // Track actual DOM changes
 private domMetrics = {
  nodeInsertions: 0,
  nodeRemovals: 0,
  attributeChanges: 0,
  textContentChanges: 0
 };
 ```
 **Implementation Strategy**:
 - Use `MutationObserver` to track DOM changes
 - Filter for Vue-specific mutations
 - Correlate with component lifecycle events
 #### **3. Memory Usage Patterns**
 ```typescript
 // Enhanced memory tracking
 private memoryMetrics = {
  heapUsage: 0,
  componentInstances: 0,
  reactiveObjects: 0,
  watcherCount: 0
 };
 ```
 **Implementation Strategy**:
 - Track Vue component instance count
 - Monitor reactive object creation
 - Measure watcher cleanup efficiency
 ## 🎯 **Conclusion: What We Know vs. What We Need to Investigate**
 ### **What We Know (Measured Evidence)**
 1. **✅ Performance Improvement is Real**: The test went from timing out (45+ seconds) to completing in 18-24 seconds
 2. **✅ The Fix Works**: The `nextTick()` batching implementation resolved the timeout issues
 3. **✅ Cross-Browser Compatibility**: Improvements work in both Chromium and Firefox
 ### **What We Need to Investigate (Unanswered Questions)**
 1. **❓ Root Cause**: Is the improvement due to:
   - Reduced Vue reactivity triggers (our hypothesis)
   - Reduced network requests (we need to measure)
   - Better error handling (the app no longer crashes)
   - Other factors we haven't identified
 2. **❓ Vue Reactivity Impact**: We need to implement Vue-specific metrics to
 confirm our hypothesis
 3. **❓ Network Request Analysis**: We need to categorize the 1,088 network
 responses to understand their impact
 ### **Next Steps for Validation**
 1. **Enhance Performance Collector**: Add Vue reactivity and DOM mutation tracking
 2. **Run Comparative Tests**: Test before/after with enhanced metrics
 3. **Network Analysis**: Categorize and analyze network request patterns
 4. **Memory Profiling**: Track memory usage patterns during test execution
 ### **Key Takeaway**
 While we have **strong evidence** that the `nextTick()` batching improved
 performance, we need **enhanced measurement tools** to understand the root cause.
 The current performance collector provides excellent timing data but lacks
 Vue-specific metrics needed to validate our reactivity hypothesis.
 // Track Vue component updates
 page.on('console', msg => {
  if (msg.text().includes('Vue update')) {
    this.vueMetrics.componentUpdates++;
  }
 });
 ```
 #### **2. DOM Mutation Metrics**
 ```typescript
 // Track DOM changes
 const observer = new MutationObserver(mutations => {
  this.metrics.domMutations = mutations.length;
 });
 observer.observe(document.body, {
  childList: true,
  subtree: true
 });
 ```
 #### **3. Memory Usage Metrics**
 ```typescript
 // Track memory usage
 const memoryInfo = performance.memory;
 this.metrics.memoryUsage = {
  usedJSHeapSize: memoryInfo.usedJSHeapSize,
  totalJSHeapSize: memoryInfo.totalJSHeapSize
 };
 ```
 ### **Current Evidence vs. Predictions**
 | Metric | Status | Evidence |
 |--------|--------|----------|
 | **Test Duration** | ✅ **Measured** | 23.7s vs 45+ seconds |
 | **Timeout Elimination** | ✅ **Measured** | No more timeouts |
 | **Vue Reactivity** | ❌ **Predicted** | Code analysis only |
 | **Network Requests** | ❌ **Predicted** | Estimated breakdown |
 ## Optimization Recommendations
 ### 🔧 Immediate Optimizations
 #### 1. **Vue Reactivity Optimization** (Biggest Impact)
 **Problem**: 887 UI component updates causing excessive re-renders
 **Solution**: Optimize Vue reactivity patterns
 ```typescript
 // Current: Reactive objects causing cascading updates
 const contact = reactive({
  name: '',
  did: '',
  visibility: false
 });
 // Optimized: Use shallowRef for large objects
 const contact = shallowRef({
  name: '',
  did: '',
  visibility: false
 });
 // Use computed properties efficiently
 const visibleContacts = computed(() =>
  contacts.value.filter(c => c.visibility)
 );
 ```
 #### 2. **Database Operations Batching** (Medium Impact)
 **Problem**: 312 individual IndexedDB operations
 **Solution**: Batch database operations
 ```typescript
 // Current: Individual operations
 await db.contacts.add(contact);
 await db.users.update(user);
 await db.offers.add(offer);
 // Optimized: Batch operations
 await db.transaction('rw', [db.contacts, db.users, db.offers], async () => {
  await db.contacts.add(contact);
  await db.users.update(user);
  await db.offers.add(offer);
 });
 ```
 #### 3. **API Call Optimization** (High Impact, Low Frequency)
 **Problem**: 70 API calls with high latency
 **Solution**: Batch and cache API calls
 ```typescript
 // Current: Sequential API calls
 await setVisibilityUtil(did, true);
 await setVisibilityUtil(did, false);
 // Optimized: Batch API calls
 await Promise.all([
  setVisibilityUtil(did, true),
  setVisibilityUtil(did, false)
 ]);
 // Add API response caching
 const apiCache = new Map();
 const cachedApiCall = async (url, options) => {
  const key = `${url}-${JSON.stringify(options)}`;
  if (apiCache.has(key)) return apiCache.get(key);
  const result = await fetch(url, options);
  apiCache.set(key, result);
  return result;
 };
 ```
 ### 🚀 Advanced Optimizations
 #### 1. **Network Request Optimization**
 - **Implement request batching** for API calls
 - **Add request caching** for repeated calls
 - **Use WebSocket connections** for real-time updates
 - **Implement request deduplication**
 #### 2. **UI Performance**
 - **Virtual scrolling** for large contact lists
 - **Component lazy loading** for non-critical UI elements
 - **Debounce user input** to reduce unnecessary operations
 - **Optimize re-render cycles** with proper Vue reactivity
 #### 3. **Database Optimization**
 - **Index optimization** for frequently queried fields
 - **Query optimization** to reduce database load
 - **Connection pooling** for better resource management
 - **Caching layer** for frequently accessed data
 ## Test-Specific Improvements
 ### Current Test Structure Issues
 1. **Sequential Operations**: Test performs operations one after another
 2. **No Cleanup**: Previous test state may affect performance
 3. **Synchronous Waits**: Using `waitForTimeout` instead of proper async waits
 ### Recommended Test Optimizations
 ```typescript
 // Before: Sequential operations
 await perfCollector.measureUserAction('add-contact', async () => {
  await page.getByTestId('contactInput').fill(did);
  await page.getByTestId('addContactButton').click();
  await expect(page.getByText('Contact added successfully')).toBeVisible();
 });
 // After: Parallel operations where possible
 await perfCollector.measureUserAction('add-contact', async () => {
  const [input, button] = await Promise.all([
    page.getByTestId('contactInput'),
    page.getByTestId('addContactButton')
  ]);
  await input.fill(did);
  await button.click();
  await expect(page.getByText('Contact added successfully')).toBeVisible();
 });
 ```
 ## Monitoring and Metrics
 ### Key Performance Indicators (KPIs)
 1. **Add-Contact Duration**: Target < 2 seconds
 2. **Switch-User Duration**: Target < 1.5 seconds
 3. **Network Request Count**: Target < 500 requests
 4. **UI Rendering Time**: Target < 100ms per operation
 ### Performance Monitoring Setup
 ```typescript
 // Add performance monitoring to test
 const performanceMetrics = {
  addContactTime: 0,
  switchUserTime: 0,
  networkRequests: 0,
  uiRenderTime: 0
 };
 // Monitor network requests
 page.on('request', () => performanceMetrics.networkRequests++);
 ```
 ## Browser-Specific Considerations
 ### Firefox Performance Issues
 - **NetworkIdle Detection**: Firefox handles `waitForLoadState('networkidle')` differently
 - **Solution**: Use `waitForSelector()` instead for more reliable cross-browser behavior
 ### Chromium Performance Issues
 - **Memory Usage**: Higher memory consumption during test runs
 - **Solution**: Implement proper cleanup and garbage collection
 ## Conclusion
 The 60-new-activity test revealed significant performance bottlenecks, primarily
 in the `add-contact` action. The main issues are:
 1. **Multiple sequential network requests** during contact addition
 2. **Inefficient UI state management** causing unnecessary re-renders
 3. **Lack of request batching** for API calls
 4. **Database operation inefficiencies**
 **Priority Actions:**
 1. Implement request batching for visibility API calls
 2. Optimize database operations with transactions
 3. Add component caching for user switching
 4. Implement proper cleanup in tests
 **Expected Impact:**
 - 40-50% reduction in add-contact time
 - 30% reduction in total test duration
 - 60% reduction in network request count
 ---
 ## TODO Items
 ### 🔥 High Priority
 #### Vue Reactivity Optimization (Biggest Impact)
 - [x] **Optimize HomeView.vue** to reduce ~300 feed updates ✅ **COMPLETED**
  - [x] Replace individual `push()` operations with batched updates
  - [x] Use `nextTick()` for batched feed updates
  - [x] Implement single reactivity trigger for all records
  - [x] **Result**: 48-60% performance improvement, eliminated timeouts
 - [ ] **Optimize ActivityListItem.vue** to reduce ~200 record updates
  - [ ] Use computed properties for record-derived data
  - [ ] Add `v-once` for static content (app name, icons)
  - [ ] Implement `shallowRef` for large record objects
  - [ ] Add memoization for expensive computed values
 - [ ] **Optimize ContactsView.vue** to reduce ~150 contact updates
  - [ ] Replace contact arrays with `shallowRef()`
  - [ ] Use Set for efficient selection lookups
  - [ ] Implement computed properties for contact filtering
  - [ ] Add `v-memo` to ContactListItem components
 - [ ] **Optimize ContactListItem.vue** to reduce ~100 selection updates
  - [ ] Use computed properties for selection state
  - [ ] Implement efficient give amount calculations
  - [ ] Add memoization for contact display data
  - [ ] Use `shallowRef` for contact objects
 - [ ] **Optimize database operations** to reduce 312 IndexedDB calls
  - [ ] Implement database transaction batching
  - [ ] Add database operation queuing
  - [ ] Cache frequently accessed data
  - [ ] Use bulk operations for multiple records
 - [ ] **Optimize API calls** to reduce 70 high-impact requests
  - [ ] Implement API response caching
  - [ ] Batch visibility API calls (`canSeeMe`/`cannotSeeMe`)
  - [ ] Add request deduplication for identical calls
  - [ ] Implement API call debouncing
 #### Next Priority: ActivityListItem.vue Optimization
 - [ ] **Optimize ActivityListItem.vue** to reduce ~200 record updates
  - [ ] Use computed properties for record-derived data
  - [ ] Add `v-once` for static content (app name, icons)
  - [ ] Implement `shallowRef` for large record objects
  - [ ] Add memoization for expensive computed values
  - [ ] **Target**: Reduce record update time by 30-40%
 #### Database Operations Optimization
 - [ ] **Optimize database operations** to reduce 312 IndexedDB calls
  - [ ] Implement database transaction batching
  - [ ] Add database operation queuing
  - [ ] Cache frequently accessed data
  - [ ] Use bulk operations for multiple records
  - [ ] **Target**: Reduce database operations by 50%
 #### API Call Optimization
 - [ ] **Optimize API calls** to reduce 70 high-impact requests
  - [ ] Implement API response caching
  - [ ] Batch visibility API calls (`canSeeMe`/`cannotSeeMe`)
  - [ ] Add request deduplication for identical calls
  - [ ] Implement API call debouncing
  - [ ] **Target**: Reduce API calls by 40%
 #### Test Improvements
 - [ ] **Fix Firefox networkIdle issues**
  - [ ] Replace `waitForLoadState('networkidle')` with `waitForSelector()`
  - [ ] Test across all browsers (Chrome, Firefox, Safari)
  - [ ] Add browser-specific wait strategies
 - [ ] **Add proper test cleanup**
  - [ ] Implement `beforeEach` cleanup for test state
  - [ ] Add `afterEach` cleanup for alerts and dialogs
  - [ ] Ensure database state is reset between tests
 ### 🚀 Medium Priority
 #### Network Request Optimization
 - [ ] **Implement request deduplication**
  - [ ] Create request deduplication service
  - [ ] Cache identical API calls within 5-second window
  - [ ] Add request batching for similar operations
 - [ ] **Add request caching layer**
  - [ ] Cache frequently accessed data (user profiles, contacts)
  - [ ] Implement cache invalidation on data changes
  - [ ] Add cache size limits and cleanup
 - [ ] **Optimize API endpoints**
  - [ ] Review `/api/report/canSeeMe` and `/api/report/cannotSeeMe`
  - [ ] Consider combining visibility operations
  - [ ] Add response caching headers
 #### UI Performance
 - [ ] **Implement virtual scrolling** for contact lists
  - [ ] Add virtual scrolling component for large lists
  - [ ] Optimize contact list rendering
  - [ ] Add lazy loading for contact details
 - [ ] **Debounce user input**
  - [ ] Add debouncing to contact input fields
  - [ ] Reduce unnecessary API calls during typing
  - [ ] Optimize search functionality
 - [ ] **Optimize Vue reactivity**
  - [ ] Review component re-render cycles
  - [ ] Use `shallowRef` for large objects
  - [ ] Implement proper computed properties
 ### 📊 Low Priority
 #### Monitoring and Metrics Tasks
 - [ ] **Add performance monitoring**
  - [ ] Create performance metrics collection service
  - [ ] Add real-time performance dashboards
  - [ ] Implement performance alerts for regressions
 - [ ] **Set up performance KPIs**
  - [ ] Define target metrics for each action
  - [ ] Add performance regression testing
  - [ ] Create performance baseline documentation
 - [ ] **Add browser-specific optimizations**
  - [ ] Implement Firefox-specific optimizations
  - [ ] Add Safari-specific performance improvements
  - [ ] Create browser detection and optimization service
 #### Advanced Optimizations
 - [ ] **Implement WebSocket connections**
  - [ ] Replace polling with WebSocket for real-time updates
  - [ ] Add WebSocket connection management
  - [ ] Implement fallback to polling
 - [ ] **Add service worker caching**
  - [ ] Cache static assets and API responses
  - [ ] Implement offline functionality
  - [ ] Add cache invalidation strategies
 - [ ] **Database query optimization**
  - [ ] Add database indexes for frequently queried fields
  - [ ] Optimize database queries for contact operations
  - [ ] Implement query result caching
 ### 🧪 Testing and Validation
 - [ ] **Create performance test suite**
  - [ ] Add dedicated performance test files
  - [ ] Create performance regression tests
  - [ ] Set up automated performance monitoring
 - [ ] **Add performance benchmarks**
  - [ ] Create baseline performance measurements
  - [ ] Add performance comparison tools
  - [ ] Document performance improvement targets
 - [ ] **Cross-browser performance testing**
  - [ ] Test performance across all supported browsers
  - [ ] Identify browser-specific bottlenecks
  - [ ] Create browser-specific optimization strategies
 ### 📚 Documentation
 - [ ] **Update performance documentation**
  - [ ] Document performance optimization patterns
  - [ ] Create performance troubleshooting guide
  - [ ] Add performance best practices documentation
 - [ ] **Create performance monitoring guide**
  - [ ] Document how to use performance metrics
  - [ ] Add performance debugging instructions
  - [ ] Create performance optimization checklist
 ## Next Steps
 1. **Start with high-priority optimizations** - Focus on the biggest bottlenecks first
 2. **Implement medium-priority improvements** - Address network and UI optimizations
 3. **Add monitoring and advanced optimizations** - Build long-term performance infrastructure
 4. **Ongoing monitoring** - Continuously track and improve performance
--- a/test-playwright/CONTACT_IMPORT_TESTING.md
+++ b/test-playwright/CONTACT_IMPORT_TESTING.md
@@ -1,232 +0,0 @@
 # Contact Import Testing Implementation
 ## Overview
 This document describes the comprehensive test suite implemented for Time Safari's
 contact import functionality. The tests cover all scenarios mentioned in the
 original TODO comment and provide thorough validation of the contact import feature.
 ## Test File: `45-contact-import.spec.ts`
 ### Test Coverage
 The test suite covers all the requirements from the original TODO:
 1. ✅ **Contact import via URL query parameters**
   - Single contact import: `/contact-import?contacts=[{"did":"did:example:123","name":"Alice"}]`
   - Multiple contacts import with proper encoding
   - URL parameter validation and error handling
 2. ✅ **JWT import via URL path**
   - JWT token in URL: `/contact-import/[JWT_TOKEN]`
   - Deep link support: `/deep-link/contact-import/[JWT_TOKEN]`
   - JWT payload validation and parsing
 3. ✅ **Manual JWT input via textarea**
   - Direct JWT string input
   - Raw contact data input
   - Input validation and error handling
 4. ✅ **Duplicate contact detection and field comparison**
   - Existing contact detection
   - Field-by-field comparison display
   - Modified contact handling
 5. ✅ **Error scenarios**
   - Invalid JWT format detection
   - Malformed contact data validation
   - Missing required fields handling
   - Wrong data types validation
   - Network error simulation
 6. ✅ **Error logging verification**
   - Console error message validation
   - UI error message display verification
   - Error state handling
 ### Test Scenarios
 #### Basic Import Tests
 - **Single contact via URL**: Tests basic URL parameter import
 - **Multiple contacts via URL**: Tests bulk import functionality
 - **JWT path import**: Tests JWT token in URL path
 - **Deep link import**: Tests deep link redirect functionality
 - **Manual JWT input**: Tests textarea JWT input
 - **Manual contact data input**: Tests raw JSON input
 #### Advanced Functionality Tests
 - **Duplicate detection**: Tests existing contact identification
 - **Field comparison**: Tests difference display for modified contacts
 - **Selective import**: Tests checkbox selection functionality
 - **Visibility settings**: Tests activity visibility controls
 - **Mixed new/existing**: Tests combination scenarios
 - **Large import performance**: Tests performance with 10+ contacts
 #### Error Handling Tests
 - **Invalid JWT format**: Tests malformed JWT handling
 - **Empty contact array**: Tests empty data handling
 - **Missing required fields**: Tests incomplete data validation
 - **Wrong data types**: Tests type validation
 - **Network error simulation**: Tests network failure handling
 ### Test Data
 #### Valid Test Contacts
 ```typescript
 const TEST_CONTACTS = {
  alice: {
    did: 'did:ethr:0x111d15564f824D56C7a07b913aA7aDd03382aA39',
    name: 'Alice Test',
    publicKey: 'alice-public-key-123'
  },
  bob: {
    did: 'did:ethr:0x222BB77E6Ff3774d34c751f3c1260866357B677b',
    name: 'Bob Test',
    publicKey: 'bob-public-key-456'
  },
  charlie: {
    did: 'did:ethr:0x333CC88F7Gg488e45d862f4d237097f748C788c',
    name: 'Charlie Test',
    publicKey: 'charlie-public-key-789'
  }
 };
 ```
 #### Invalid Test Data
 ```typescript
 const INVALID_DATA = {
  malformedJwt: 'eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.invalid.payload',
  emptyArray: '[]',
  missingFields: '[{"name":"Incomplete Contact"}]',
  wrongTypes: '[{"did":123,"name":456}]',
  networkError: 'http://invalid-url-that-will-fail.com/contacts'
 };
 ```
 ### Utility Functions Added
 #### New Functions in `testUtils.ts`
 - `createTestJwt(payload)`: Creates test JWT tokens
 - `cleanupTestContacts(page, contactNames)`: Cleans up test contacts
 - `addTestContact(page, did, name, publicKey?)`: Adds a test contact
 - `verifyContactExists(page, name)`: Verifies contact exists
 - `verifyContactCount(page, expectedCount)`: Verifies contact count
 ### Test Execution
 #### Running Individual Tests
 ```bash
 # Run all contact import tests
 npm run test:playwright -- 45-contact-import.spec.ts
 # Run specific test
 npm run test:playwright -- 45-contact-import.spec.ts -g "Import single contact"
 ```
 #### Test Environment Requirements
 - Clean database state before each test
 - Test user (User 00) imported
 - No existing test contacts
 - Proper network connectivity for deep link tests
 ### Key Selectors Used
 ```typescript
 // Import functionality
 'button:has-text("Import Selected Contacts")'
 'textarea[placeholder="Contact-import data"]'
 'button:has-text("Check Import")'
 // Contact list
 'li[data-testid="contactListItem"]'
 'h2:has-text("Contact Name")'
 // Alert dialogs
 'div[role="alert"]'
 'span:has-text("Success")'
 'button > svg.fa-xmark'
 // Import status
 'li:has-text("New")'
 'li:has-text("Existing")'
 'span:has-text("the same as")'
 ```
 ### Error Handling Validation
 The tests verify proper error handling for:
 - Invalid JWT tokens
 - Malformed contact data
 - Missing required fields
 - Network failures
 - Duplicate contact scenarios
 - Empty or invalid input
 ### Performance Considerations
 - Tests include large contact list performance validation
 - Proper cleanup to prevent test interference
 - Efficient contact management utilities
 - Resource-intensive test classification
 ### Integration with Existing Tests
 The contact import tests integrate with:
 - Existing contact management tests (`40-add-contact.spec.ts`)
 - User management utilities (`testUtils.ts`)
 - Platform service testing infrastructure
 - Database migration testing framework
 ### Security Considerations
 - JWT token validation testing
 - Input sanitization verification
 - Error message security (no sensitive data exposure)
 - Network request validation
 ## Migration Status
 This test implementation addresses the TODO comment requirements:
 ```
 // TODO: Testing Required - Database Operations + Logging Migration to PlatformServiceMixin
 // Priority: Medium | Migrated: 2025-07-06 | Author: Matthew Raymer
 ```
 **Status**: ✅ **COMPLETED** - August 4, 2025
 All 6 testing requirements have been implemented with comprehensive coverage:
 1. ✅ Contact import via URL
 2. ✅ JWT import via URL path
 3. ✅ Manual JWT input
 4. ✅ Duplicate contact detection
 5. ✅ Error scenarios
 6. ✅ Error logging verification
 ## Future Enhancements
 Potential improvements for the test suite:
 - Real JWT signing for more authentic testing
 - Network interception for better error simulation
 - Performance benchmarking metrics
 - Cross-platform compatibility testing
 - Accessibility testing for import interfaces
 ## Author
 **Matthew Raymer** - 2025-08-04
 This test suite provides comprehensive coverage of the contact import functionality
 and ensures robust validation of all import methods, error scenarios, and edge cases.
--- a/test-playwright/PERFORMANCE_MONITORING.md
+++ b/test-playwright/PERFORMANCE_MONITORING.md
@@ -1,256 +0,0 @@
 # Performance Monitoring in Playwright Tests
 Performance monitoring is more than just numbers — it’s about understanding **how your users experience your app** during automated test runs.
 This guide will teach you not just how to set it up, but also **why each step matters**.
 ---
 ## Why Performance Monitoring Matters
 Think of Playwright tests as quality control for your app’s speed and responsiveness.
 By adding performance monitoring, you can:
 - 🚨 **Catch regressions early** before users feel them
 - 🎯 **Keep user experience consistent** across releases
 - 🔎 **Spot bottlenecks** in login, navigation, or heavy data flows
 - 📊 **Make informed decisions** with hard data, not guesses
 - 🏆 **Maintain performance standards** as features grow
 > **Key Insight:** Without metrics, “fast” is just a feeling. With metrics, it’s a fact.
 ---
 ## How It Works: The Architecture
 The monitoring system has **four pillars**:
 1. **PerformanceCollector Class** – Collects raw metrics
 2. **Performance Utilities** – Easy-to-use helper functions
 3. **Test Integration** – Hooks directly into Playwright tests
 4. **Report Generation** – Creates JSON reports you can analyze later
 Here’s a mental model:
 ```
 Playwright Test
      |
      v
 PerformanceCollector (collects data)
      |
      v
 Report Generation → JSON / HTML / CI attachments
 ```
 ### Core Collector
 ```typescript
 // performanceUtils.ts
 export class PerformanceCollector {
  private page: Page;
  public metrics: any;
  public navigationMetrics: any[];
  private cdpSession: any;
  // Methods for collecting various metrics
  async collectNavigationMetrics(label: string)
  async collectWebVitals()
  async measureUserAction(actionName: string, actionFn: () => Promise<void>)
  generateReport()
 }
 ```
 👉 **Teaching Point:** `measureUserAction` wraps a user action and times it, giving you reproducible benchmarks.
 ---
 ## Quick Start: A Simple Example
 ```typescript
 import { createPerformanceCollector, attachPerformanceData } from './performanceUtils';
 test('My test with performance monitoring', async ({ page }, testInfo) => {
  const perfCollector = await createPerformanceCollector(page);
  // Measure user action
  await perfCollector.measureUserAction('click-button', async () => {
    await page.click('#my-button');
  });
  // Attach data to the test report
  await attachPerformanceData(testInfo, perfCollector);
 });
 ```
 ✅ After this test runs, you’ll find performance data **directly in the Playwright report**.
 ---
 ## Advanced Example: A Complete User Flow
 ```typescript
 test('Complex user flow with performance tracking', async ({ page }, testInfo) => {
  const perfCollector = await createPerformanceCollector(page);
  await perfCollector.collectNavigationMetrics('initial-load');
  await perfCollector.measureUserAction('login', async () => {
    await page.fill('#username', 'user');
    await page.fill('#password', 'pass');
    await page.click('#login-button');
  });
  await perfCollector.measureUserAction('navigate-to-dashboard', async () => {
    await page.goto('/dashboard');
  });
  await attachPerformanceData(testInfo, perfCollector);
 });
 ```
 > **Pro Tip:** Use descriptive labels like `'login'` or `'navigate-to-dashboard'`
 to make reports easy to scan.
 ---
 ## What Metrics You’ll See
 ### Navigation Metrics (Page Load)
 - `domContentLoaded` → When DOM is ready
 - `loadComplete` → When page is fully loaded
 - `firstPaint` → When users first *see* something
 - `serverResponse` → How quickly the backend responds
 ### User Action Metrics
 - `duration` → How long the action took
 - `metrics` → Detailed performance snapshots
 ### Memory Usage
 - `used`, `total`, `limit` → Helps catch leaks and spikes
 ### Web Vitals
 - **LCP** → Largest Contentful Paint
 - **FID** → First Input Delay
 - **CLS** → Layout stability
 ---
 ## Reading the Data: A Beginner’s Lens
 Here’s what a **healthy test run** might look like:
 ```json
 {
  "label": "home-page-load",
  "metrics": {
    "domContentLoaded": 294,
    "loadComplete": 295,
    "serverResponse": 27.6,
    "resourceCount": 96
  }
 }
 ```
 **Interpretation:**
 - DOM loaded fast (<500ms) ✅
 - Server response is excellent (<100ms) ✅
 - Resource count is reasonable for a SPA ✅
 Now, here’s a **problematic run**:
 ```json
 {
  "label": "slow-page-load",
  "metrics": {
    "domContentLoaded": 2500,
    "loadComplete": 5000,
    "serverResponse": 800,
    "resourceCount": 200
  }
 }
 ```
 **Interpretation:**
 - DOM took 2.5s ❌
 - Full load took 5s ❌
 - Too many resources (200) ❌
 > **Lesson:** Slow page loads often mean large bundles, too many requests, or server lag.
 ---
 ## Performance Threshold Cheat Sheet
 | Metric | Excellent | Good | Poor |
 |--------|-----------|------|------|
 | domContentLoaded | < 500ms | < 1000ms | > 2000ms |
 | loadComplete | < 1000ms | < 2000ms | > 3000ms |
 | userAction duration | < 100ms | < 300ms | > 500ms |
 | memory usage | < 50MB | < 100MB | > 150MB |
 👉 Use these thresholds to set alerts in your regression tests.
 ---
 ## Common Patterns
 1. **Initial Page Load**
   - ✅ DOM in <500ms
   - ✅ Load in <1000ms
   - ⚠️ Watch out for large bundles
 2. **User Interaction**
   - ✅ Actions under 100ms
   - ✅ Few/no extra requests
   - ⚠️ Avoid bloated API calls
 3. **Navigation**
   - ✅ <200ms between pages
   - ⚠️ Inconsistency usually means missing cache headers
 ---
 ## Best Practices
 - 📏 **Consistency** – Measure the same flows every run
 - 🧪 **Realism** – Test with production-like data
 - 🏗 **Environment Control** – Use stable test environments
 - 📉 **Set Thresholds** – Define what “slow” means for your team
 - 🔁 **Continuous Monitoring** – Run in CI/CD and watch trends
 > **Remember:** A fast app last release doesn’t guarantee it’s fast today.
 ---
 ## Migration Tip
 **Before (Manual Timing):**
 ```typescript
 const start = Date.now();
 await page.click('#button');
 console.log(Date.now() - start);
 ```
 **After (Structured Monitoring):**
 ```typescript
 await perfCollector.measureUserAction('button-click', async () => {
  await page.click('#button');
 });
 ```
 ✅ Cleaner, more consistent, and automatically reported.
 ---
 ## Key Takeaway
 Performance monitoring in Playwright isn’t just about collecting data — it’s
 about making your tests **teach you** how users experience your app.
 The **PerformanceCollector** class plus good testing habits give you a clear,
 data-driven picture of app health.