diff --git a/.planning/.continue-here.md b/.planning/.continue-here.md
new file mode 100644
index 000000000..57be66699
--- /dev/null
+++ b/.planning/.continue-here.md
@@ -0,0 +1,204 @@
+---
+phase: 11-chat-finalization
+status: paused_for_investigation
+blocker: repeated_api_requests
+last_updated: 2026-01-31
+---
+
+
+**Phase 11 UAT PAUSED** - Critical performance issue discovered during manual testing.
+
+**Issue:** Repeated API requests being made continuously after session screen loads (before clicking chat button). Same requests that occur on initial page load are repeating indefinitely.
+
+**Context:**
+- P0 bug fixed: session_id → music_session parameter (commit 5b940ae)
+- Code verified complete by gsd-verifier
+- Automated tests timing out (P2 - test infrastructure issue, not code)
+- During manual UAT, user discovered repeated request issue affecting session screen performance
+
+**Status:** Milestone v1.1 chat feature technically complete, but cannot approve UAT until repeated request issue is resolved.
+
+
+
+## Phase 11: Chat Finalization
+
+- ✅ Plan 11-01: Error Handling, Accessibility & Polish (3 tasks) - COMPLETE
+ - Comprehensive error handling (red/yellow displays, retry button)
+ - Full accessibility (ARIA attributes, keyboard navigation, focus management)
+ - Edge case handling (empty states, validation, disconnection)
+
+- ✅ Plan 11-02: UAT & Final Integration Testing (2 of 3 tasks) - PAUSED
+ - Task 1: UAT checklist prepared (50+ test cases across 9 categories)
+ - Task 2: P0 bug fixed (session_id → music_session)
+ - Task 3: Manual UAT IN PROGRESS - paused due to repeated request issue
+
+## All Phases 6-10: COMPLETE
+- Phase 6: Session Chat Research & Design (2/2 plans)
+- Phase 7: Chat Infrastructure & State Management (3/3 plans)
+- Phase 8: Chat Window UI & Message Display (3/3 plans)
+- Phase 9: Message Composition & Sending (2/2 plans)
+- Phase 10: Read/Unread Status Management (1/1 plans)
+
+
+
+## Immediate: Fix Repeated Request Issue
+
+**Priority:** P0 - Blocks milestone completion
+
+**Steps:**
+1. Diagnose repeated request pattern
+ - Capture HAR file or network log showing repeated requests
+ - Identify which API endpoints are being called repeatedly
+ - Determine request frequency and what triggers them
+ - Check if requests start immediately or after delay
+
+2. Investigate root cause
+ - Check if chat feature introduced polling/intervals
+ - Review useEffect hooks in JKSessionScreen for dependencies
+ - Check WebSocket reconnection logic
+ - Look for Redux thunks that auto-dispatch
+ - Check if existing session features (Backing Track, JamTrack, Metronome) have polling that's misbehaving
+
+3. Fix the issue
+ - Stop repeated requests
+ - Ensure fix doesn't break existing functionality
+ - Test all session features still work (chat, Backing Track, JamTrack)
+
+4. Complete Phase 11 UAT
+ - Verify repeated requests stopped
+ - Complete manual UAT checklist (50+ test cases)
+ - Verify no regressions
+ - Approve milestone
+
+## After Fix: Complete Milestone v1.1
+
+- Update STATE.md with "Phase 11 COMPLETE"
+- Update ROADMAP.md progress table
+- Verify all verification criteria met
+- Mark milestone v1.1 as SHIPPED
+
+
+
+## Phase 11 Decisions
+
+1. **Pause UAT for performance fix**: Repeated requests affect user experience and must be fixed before production approval
+2. **P0 bug fix successful**: session_id → music_session parameter corrected, chat messages now send successfully
+3. **Test infrastructure P2**: Playwright tests timing out is a test environment issue, not blocking deployment (manual UAT sufficient)
+4. **Manual UAT approach**: Given test infrastructure issues, comprehensive manual testing is primary validation method
+
+## Investigation Scope Decision
+
+**Scope:** Fix repeated request issue in session screen (may or may not be chat-related)
+
+**Out of scope (defer):**
+- Test infrastructure fixes (Playwright timeout issues)
+- Server-side read/unread tracking
+- File attachments, message editing, typing indicators
+- Other deferred features from Phase 6 design
+
+
+
+## P0: Repeated API Requests
+
+**Symptom:** After session screen loads, API requests repeat continuously (same requests as initial page load)
+
+**Discovery:** User noticed during manual UAT - occurred without clicking chat button
+
+**Impact:**
+- Performance degradation on session screen
+- Unnecessary backend load
+- Cannot approve milestone until resolved
+
+**Unknown:**
+- Which specific API endpoints are repeating
+- Request frequency (every second? every 500ms?)
+- Whether chat feature introduced this or exposed existing bug
+- Whether this affects only chat sessions or all sessions
+
+**Next Steps:**
+1. User to provide network HAR file or describe which requests repeat
+2. Investigate session screen component lifecycle
+3. Check for runaway polling/intervals
+4. Fix root cause
+5. Resume UAT
+
+
+
+## Mental State
+
+**What we were doing:**
+- Completing Phase 11 UAT (final validation before milestone approval)
+- Found and fixed P0 bug (parameter name mismatch causing 404 errors)
+- Started manual testing to validate the fix works
+- Discovered new P0 performance issue (repeated requests)
+
+**The vibe:**
+- Chat feature code is complete and verified
+- One critical bug fixed successfully
+- Very close to milestone completion
+- New blocker discovered during final testing (classic)
+- Need to pause and fix properly before proceeding
+
+**Key insight:**
+This repeated request issue may have existed before chat feature (chat just made it noticeable), or chat feature may have introduced it. Need to investigate whether:
+1. Chat components are polling unnecessarily
+2. Chat feature changed session screen render cycle
+3. Existing session features (Backing Track/JamTrack) have buggy polling
+4. WebSocket reconnection logic is broken
+
+## Technical Context
+
+**Files likely involved:**
+- `jam-ui/src/components/client/JKSessionScreen.js` - Main session container
+- `jam-ui/src/components/client/JKSessionChatWindow.js` - Chat window (if chat-related)
+- `jam-ui/src/hooks/useSessionWebSocket.js` - WebSocket connection
+- Any components with useEffect + setInterval/setTimeout
+- Redux thunks that auto-dispatch on state changes
+
+**Patterns to check:**
+- useEffect with missing dependencies → infinite re-renders
+- setInterval not cleaned up → multiple timers running
+- Redux thunk that dispatches itself → infinite loop
+- WebSocket reconnect logic → repeated connection attempts
+- Polling logic with wrong conditions → never stops polling
+
+**Testing approach:**
+1. Open DevTools Network tab
+2. Load session screen
+3. Don't interact with anything
+4. Watch for repeated requests
+5. Note which endpoints, frequency, and timing
+
+
+
+**When resuming:**
+
+1. **Start with diagnosis:**
+ ```
+ Ask user: "Can you describe which API requests are repeating?
+ - Which endpoints? (e.g., /api/sessions/X, /api/chat, /api/users/me)
+ - How often? (every second, every 500ms, constant?)
+ - Do they start immediately on page load or after a delay?
+ - Can you share a network HAR file or screenshot?"
+ ```
+
+2. **Once diagnosis is clear:**
+ - Use Grep to find setInterval/setTimeout in session screen components
+ - Check useEffect hooks for missing dependencies or cleanup
+ - Review chat component initialization for accidental polling
+ - Look for Redux thunks that re-dispatch on state changes
+
+3. **Fix pattern:**
+ - Identify root cause
+ - Apply minimal fix (stop the repeating)
+ - Test manually (verify requests stop)
+ - Verify no regressions (chat, Backing Track, JamTrack still work)
+ - Commit fix: `fix: stop repeated API requests on session screen`
+
+4. **Resume UAT:**
+ - Complete manual UAT checklist
+ - Approve Phase 11
+ - Complete milestone v1.1
+
+**Command to resume:** Just start the conversation by asking the user about the repeated requests.
+