docs: add critical new requirements - edge docking and touch-through

NEW REQUIREMENTS:
- Soft dock to screen edges (snap when dragged within 50px of edge)
- Touch-through for underlying apps (user must interact with Pokemon GO)
- Only FAB intercepts touches, everything else passes to underlying app

TECHNICAL IMPLICATIONS:
- Activity approach now problematic (captures touches in window bounds)
- WindowManager + Views approach now RECOMMENDED (precise touch control)
- Window must be sized exactly to FAB, not fullscreen
- FLAG_NOT_TOUCH_MODAL critical for touch pass-through

Updated recommendation: Option B (Enhanced WindowManager + Material Views)

🤖 Generated with [Claude Code](https://claude.ai/code)

Co-Authored-By: Claude <noreply@anthropic.com>

UI_MODERNIZATION_TASKS.md

@@ -211,14 +211,104 @@ FloatingActionButtonUI (Compose)
 **Sprint 4 (Week 7-8)**: Enhanced UX patterns
 **Sprint 5+ (Future)**: Advanced features as needed
 
+## 🎯 Critical User Requirements (UPDATED)
+
+### **Core Floating Behavior**
+- ✅ **"Floating Action Button"** - Not basic Button, actual FAB with Material 3 design
+- ✅ **"Truly floating"** - Like CalcIV, draggable anywhere on screen
+- ✅ **"Not bringing up navigation bar"** - System UI completely hidden
+- ✅ **"Show underlying apps"** - Transparent background, no window blocking content
+- ❌ **"Blocky static developer UI"** - Must be polished, smooth, professional
+
+### **🆕 NEW Requirements (Critical for Implementation)**
+- 🎯 **"Soft dock to screen edges"** - When dragged within ~50px of left/right edge, animate to snap against edge
+- 🎯 **"Touch-through for underlying apps"** - User must be able to interact with Pokemon GO UI:
+  - Scroll through Pokemon lists
+  - Tap buttons, menus, items
+  - Pinch to zoom, swipe gestures
+  - Only FAB itself should intercept touches, everywhere else passes through
+
+### **Technical Implications of New Requirements**
+
+#### **Edge Docking Implementation**
+```kotlin
+// Pseudo-code for edge snapping:
+onDragEnd { finalPosition ->
+    val screenWidth = getScreenWidth()
+    val snapThreshold = 50.dp.toPx()
+    
+    val targetX = when {
+        finalPosition.x < snapThreshold -> 0f // Snap to left edge
+        finalPosition.x > screenWidth - snapThreshold -> screenWidth - fabWidth // Snap to right edge  
+        else -> finalPosition.x // Stay where dropped
+    }
+    
+    animateToPosition(targetX, finalPosition.y)
+}
+```
+
+#### **Touch-Through Requirements**
+This is the **most complex requirement** and changes our approach significantly:
+
+**Option A Issues**: Activity approach likely won't work - Activities capture all touches within their bounds
+
+**WindowManager Requirements**:
+```kotlin
+// Window must have precise touch handling:
+WindowManager.LayoutParams(
+    WRAP_CONTENT, WRAP_CONTENT, // Only FAB size, not fullscreen
+    TYPE_APPLICATION_OVERLAY,
+    FLAG_NOT_TOUCH_MODAL or  // Don't capture outside touches
+    FLAG_LAYOUT_NO_LIMITS,   // Allow positioning anywhere
+    PixelFormat.TRANSLUCENT
+)
+
+// FAB must be exactly positioned with minimal window size
+// Everything outside FAB boundaries must pass through to underlying app
+```
+
+### **Revised Option Analysis**
+
+#### **Option A: Activity Approach** - ⚠️ **PROBLEMATIC**
+- **Major Issue**: Activities have window boundaries that may interfere with touch-through
+- **Edge Docking**: Possible with window positioning
+- **Touch-Through**: Very difficult - Activity windows tend to capture touches
+
+#### **Option B: WindowManager + Views** - ⭐ **BEST FOR TOUCH-THROUGH**
+- **Touch-Through**: Excellent - Window can be sized exactly to FAB dimensions
+- **Edge Docking**: Perfect control with WindowManager.updateViewLayout()
+- **Polish**: Need to ensure Material 3 styling with Views
+
+#### **Option C: Advanced Compose** - ❓ **RESEARCH NEEDED**
+- **Touch-Through**: Unknown if ComposeView can be made touch-through
+- **Edge Docking**: Would work if lifecycle issues solved
+- **Complexity**: High due to lifecycle issues
+
+### **RECOMMENDED APPROACH: Option B Enhanced**
+Given the new requirements, **WindowManager + Views** is now the clear winner:
+
+1. **Precise Touch Handling**: Window sized exactly to FAB, everything else passes through
+2. **Edge Snapping**: Full control over window positioning and animations  
+3. **No Lifecycle Issues**: Views work perfectly in overlay context
+4. **Material 3 Polish**: Use `com.google.android.material.floatingactionbutton.FloatingActionButton`
+
+```kotlin
+// Implementation approach:
+class EnhancedFloatingFAB {
+    // Material 3 FloatingActionButton with proper theming
+    // ObjectAnimator for smooth edge snapping
+    // WindowManager for precise positioning
+    // Touch handling only within FAB bounds
+}
+```
+
 ## Success Metrics
 
-- **User Experience**: Smooth 60fps animations, <100ms interaction response
+- **Touch Behavior**: FAB interactive, underlying app fully usable
-- **Functionality**: All current features preserved + new capabilities
+- **Edge Snapping**: Smooth 300ms animation to screen edges
-- **Performance**: No degradation in detection accuracy or speed
+- **Visual Polish**: Indistinguishable from Compose Material 3 FAB
-- **Accessibility**: WCAG 2.1 AA compliance
+- **Performance**: 60fps animations, no interference with underlying app
-- **Code Quality**: Maintainable Compose architecture
 
 ---
 
-**Note**: This is a living document that will be updated as features are implemented and new requirements emerge.
+**UPDATED STATUS**: Option B (WindowManager + Material Views) now recommended due to touch-through requirements. Ready to implement enhanced version with edge snapping and precise touch handling.