---
status: diagnosed
trigger: "Controls and stems appear before JamTrack is synchronized"
created: 2026-02-25T10:00:00Z
updated: 2026-02-25T10:20:00Z
---

## Current Focus

hypothesis: CONFIRMED - The stems rendering condition at line 1406 includes 'idle' as a valid state, and downloadState.state defaults to 'idle'. Since handleJamTrackSelect dispatches UI state immediately without triggering loadJamTrack, the state never transitions from 'idle' to 'packaging', so stems render immediately.
test: Verified by reading code flow
expecting: N/A - root cause confirmed
next_action: Document resolution

## Symptoms

expected: Stems and controls should only appear AFTER JamTrack is synchronized with backend
actual: Stems appear immediately in session screen when JamTrack is selected, before backend processing completes
errors: None reported - visual UI issue
reproduction: Select a JamTrack in session screen - stems immediately appear before server processing
started: Existing behavior - partially fixed in 26-02 for player popup but not for session screen stems

## Eliminated

- hypothesis: The rendering condition at line 1406 doesn't check downloadState
  evidence: It DOES check downloadState, but checks for 'synchronized' OR 'idle' - the problem is 'idle' is the default state
  timestamp: 2026-02-25T10:15:00Z

## Evidence

- timestamp: 2026-02-25T10:00:00Z
  checked: Research document .planning/research/JAMTRACK-LOADING.md
  found: Research already identified handleJamTrackSelect() at line 1165-1190 immediately dispatches setSelectedJamTrack(), setJamTrackStems(), setJamTrackData() without waiting for backend
  implication: UI state is set immediately causing premature rendering

- timestamp: 2026-02-25T10:10:00Z
  checked: JKSessionScreen.js line 1405-1406
  found: Condition IS checking downloadState but allows both 'synchronized' AND 'idle': (jamTrackDownloadState.state === 'synchronized' || jamTrackDownloadState.state === 'idle')
  implication: 'idle' means "not yet checked/synced" but is being treated as "ready to display"

- timestamp: 2026-02-25T10:12:00Z
  checked: mediaSlice.js initial state (line 369-383)
  found: downloadState.state initial value is 'idle'
  implication: When JamTrack is selected, downloadState remains 'idle' until user clicks Play, which then triggers loadJamTrack which changes state to 'packaging'

- timestamp: 2026-02-25T10:15:00Z
  checked: JKSessionScreen.js handleJamTrackSelect (line 1165-1190)
  found: Function only fetches metadata and dispatches UI state (setSelectedJamTrack, setJamTrackStems, setJamTrackData). It does NOT call loadJamTrack, so downloadState never transitions from 'idle'.
  implication: The fix must either: (1) remove 'idle' from valid render states, OR (2) change handleJamTrackSelect to trigger loadJamTrack BEFORE dispatching UI state

- timestamp: 2026-02-25T10:17:00Z
  checked: JKSessionJamTrackPlayer.js line 680
  found: Player controls also use same condition: (downloadState.state === 'idle' || downloadState.state === 'synchronized')
  implication: 26-02 fix addressed this by adding condition at line 680, but the same logical error exists - 'idle' should NOT be treated as ready

## Resolution

root_cause: Two-part issue: (1) handleJamTrackSelect() dispatches UI state (setSelectedJamTrack, setJamTrackStems) immediately without triggering backend sync. (2) The rendering condition at line 1406 treats 'idle' as valid for showing stems, but 'idle' means "backend not yet checked" not "ready to display". Initial downloadState.state is 'idle', and it only changes to 'packaging'/'downloading'/'synchronized' when loadJamTrack is called (which happens on Play button click, not on selection).
fix:
verification:
files_changed: []
