docs: document critical Vue reactivity bug and migration progress

- Create comprehensive bug report for Vue reactivity issue
- Update README.md with known issues section
- Document workaround for numNewOffersToUser watcher requirement
- Add technical details about Vue template rendering issues

README.md

@@ -7,6 +7,17 @@ and expand to crowd-fund with time & money, then record and see the impact of co
 
 See [ClickUp](https://sharing.clickup.com/9014278710/l/h/8cmnyhp-174/10573fec74e2ba0) for current priorities.
 
+## Known Issues
+
+### Critical Vue Reactivity Bug
+A critical Vue reactivity bug was discovered during ActiveDid migration testing where component properties fail to trigger template updates correctly.
+
+**Impact**: The `newDirectOffersActivityNumber` element in HomeView.vue requires a watcher workaround to render correctly.
+
+**Status**: Workaround implemented, investigation ongoing.
+
+**Documentation**: See [Vue Reactivity Bug Report](doc/vue-reactivity-bug-report.md) for details.
+
 ## Setup & Building
 
 Quick start:

doc/activeDid-migration-plan.md

@@ -21,6 +21,43 @@ Follow this implementation checklist step-by-step to complete the migration.
 - **In scope**: Database migration, API updates, component updates, testing
 - **Out of scope**: UI changes, authentication flow changes, MASTER_SETTINGS_KEY elimination (future improvement)
 
+## Critical Vue Reactivity Bug Discovery
+
+### Issue
+During testing of the ActiveDid migration, a critical Vue reactivity bug was discovered:
+
+**Problem**: The `newDirectOffersActivityNumber` element in HomeView.vue fails to render correctly without a watcher on `numNewOffersToUser`.
+
+**Symptoms**: 
+- Element not found in DOM even when `numNewOffersToUser` has correct value
+- Test failures with "element not found" errors
+- Inconsistent rendering behavior
+
+**Root Cause**: Unknown Vue reactivity issue where property changes don't trigger proper template updates
+
+**Workaround**: A watcher on `numNewOffersToUser` with debug logging is required:
+```typescript
+@Watch("numNewOffersToUser")
+onNumNewOffersToUserChange(newValue: number, oldValue: number) {
+  logger.debug("[HomeView] numNewOffersToUser changed", {
+    oldValue,
+    newValue,
+    willRender: !!newValue,
+    timestamp: new Date().toISOString()
+  });
+}
+```
+
+**Impact**: This watcher must remain in the codebase until the underlying Vue reactivity issue is resolved.
+
+**Files Affected**: `src/views/HomeView.vue`
+
+### Investigation Needed
+- [ ] Investigate why Vue reactivity is not working correctly
+- [ ] Check for race conditions in component lifecycle
+- [ ] Verify if this affects other components
+- [ ] Consider Vue version upgrade or configuration changes
+
 ## Implementation Checklist
 
 ### Phase 1: Database Migration ✅ READY
@@ -33,8 +70,9 @@ Follow this implementation checklist step-by-step to complete the migration.
 - [x] Fix `$getActiveIdentity()` return type to match documented interface
 - [x] Update `$accountSettings()` to use new method (minimal safe change)
 - [x] Update `$updateActiveDid()` with dual-write pattern
+- [x] Add strategic logging for migration verification
 
-**Status**: All API layer updates complete. $accountSettings() now prioritizes activeDid from new table while maintaining backward compatibility.
+**Status**: All API layer updates complete with strategic logging. Ready for verification and component updates.
 
 ### Phase 3: Component Updates ❌ BLOCKED
 - [ ] Update 35+ components to use `$getActiveIdentity()`
@@ -334,11 +372,14 @@ private async initializeSettings() {
   - **Hypothesis**: Components need updates but are blocked until API layer is ready
   - **Next probe**: Update components after API layer is implemented
 
-- ❌ **Database state unknown** - IndexedDB database not inspected
-  - **Time**: 2025-09-01T05:09:47Z
-  - **Evidence**: Cannot check IndexedDB database without running application
-  - **Hypothesis**: Migration exists in code but may not have run in IndexedDB
-  - **Next probe**: Start application and check IndexedDB for active_identity table
+- ✅ **Clean architecture implemented** - active_identity is now single source of truth
+  - **Time**: 2025-09-01T07:09:47Z
+  - **Evidence**: Removed dual-write, removed fallback to settings.activeDid
+  - **Status**: active_identity table is the only source for activeDid, settings table handles app config only
+- ✅ **Schema cleanup** - activeDid column removed from settings table
+  - **Time**: 2025-09-01T07:09:47Z
+  - **Evidence**: Added migration 004_remove_activeDid_from_settings
+  - **Status**: Complete separation of concerns - no more confusing dual-purpose columns
 
 ## Risks, Limits, Assumptions