Ubisam-MobileGit/tasks/032-repository-list-swipe-direction-fix.md

TASK-032: Fix reversed ALL/FAVORITES swipe direction on the repository list

Status: implemented; all required checks pass; live-installed, awaiting the human product owner's confirmation Owner: Claude Reviewer: Codex

Outcome

The repository list screen's own left/right swipe between its ALL and FAVORITES tabs (RepositoryListScreen.modeSwipeGesture) had its direction inverted relative to this app's own established swipe convention (and relative to BranchDetailScreen's HorizontalPager, which already behaves correctly): swiping right moved ALL -> FAVORITES and swiping left moved FAVORITES -> ALL, the opposite of "content follows the finger." Live-reported as "메인 화면 좌우 탭전환 스와이프가 반대로 되어 있는 것 같다" (the main screen's left/right tab-switch swipe seems reversed) — this is the repository list because it's the app's actual home/first screen after login, distinct from BranchDetailScreen's own Files/Commit tab pager (already correct, and the subject of this session's earlier gesture-conflict fixes).

Scope

• Included: feature/repositories/RepositoryListScreen.kt (modeSwipeGesture's onDragEnd branch conditions only).
• Excluded: BranchDetailScreen's HorizontalPager (unaffected — uses Compose's own built-in drag handling, which already followed the correct convention; verified, not just assumed, before concluding this was a separate, single-screen bug). No change to tap-to-switch (Tab.onClick), the swipe threshold, or any other gesture behavior.

Design notes

• Root cause: RepositoryListScreen doesn't use HorizontalPager for its ALL/FAVORITES tabs (a plain TabRow/Tab pair, tap-switched, plus a separate hand-rolled detectHorizontalDragGestures modifier for swipe) — the comparison signs in that hand-rolled gesture's onDragEnd were backwards relative to the drag-follows-finger convention that Compose's HorizontalPager itself provides automatically (and that BranchDetailScreen already relies on, unmodified, for its own Files/Commit swipe). totalDragX accumulates the raw horizontal drag delta, positive when the finger moves rightward; with ALL as the left-hand tab and FAVORITES as the right-hand tab (confirmed directly from ModeTabs's Tab order and TabRow's selectedTabIndex), a rightward drag should reveal the tab to the left (ALL), and a leftward drag should reveal the tab to the right (FAVORITES) — the previous code had both branches' comparisons swapped from that.
• Fix, not a rewrite: the two when branch conditions were swapped in place (comparison operators and signs only); the drag-accumulation, threshold, and consume-on-horizontal-drag logic were left exactly as they were, since none of that was implicated in the reported bug.

Acceptance criteria

• Swiping left while on ALL now switches to FAVORITES.
• Swiping right while on FAVORITES now switches to ALL.
• Tap-to-switch (the TabRow's Tabs) is unaffected.
• Build, unit tests, and lint pass.
• Live confirmation from the human product owner that the swipe direction now feels correct — the build has been reinstalled on the device but not yet re-tested against this exact gesture in this session.

Required checks

./gradlew compileDebugKotlin compileDebugUnitTestKotlin
./gradlew testDebugUnitTest
./gradlew assembleDebug lintDebug

Evidence

• RepositoryListScreen.kt: modeSwipeGesture's onDragEnd branch conditions swapped (totalDragX < -SwipeThresholdPx && mode == ALL -> onShowFavorites() / totalDragX > SwipeThresholdPx && mode == FAVORITES -> onShowAllRepositories()), with a comment explaining the now-correct convention.
• ./gradlew compileDebugKotlin compileDebugUnitTestKotlin: BUILD SUCCESSFUL.
• ./gradlew testDebugUnitTest: BUILD SUCCESSFUL, all unit tests passing (no dedicated test for this gesture — it's private Compose gesture-handling with no non-UI logic to isolate, the same category as this session's earlier pinch-zoom/pan gesture work).
• ./gradlew assembleDebug lintDebug: BUILD SUCCESSFUL, 0 lint errors.
• Installed on the human product owner's device over wireless adb (adb install -r, streamed install succeeded); not yet re-tested live against the swipe gesture itself in this session.

Known limitations

• No dedicated unit test exists for the gesture direction itself (same category as this app's other pure-Compose gesture code — see Evidence).
• Live confirmation is still pending in this session.

Review findings

None yet — pending Codex/human review.