[Bug] Weight Change Per Rep slider doesn't allow 1 lb increments in Just Lift mode (iOS)

[9thLevelSoftware]

Bug Report: Weight Change Per Rep slider doesn't allow 1 lb increments in Just Lift mode

Reported via Discord by: Devil (on behalf of anonymous iOS user)
Thread: Project Phoenix / #bug-reports
Report Date: 2026-06-17

Platform

• OS: iOS
• Device: iPhone 16 Pro
• App Mode: Just Lift

Bug Description

In Just Lift mode, the "Weight Change Per Rep" feature is bugged. The slider doesn't allow 1 lb increments — it starts at 2 and does arbitrary numbers instead of proper 1 lb steps.

Screenshot OCR / In-App Feedback Text

The user submitted a screenshot with in-app feedback text and a video showing the issue. The screenshot shows the Just Lift workout configuration screen with:

• Mode: Old School
• Weight per Cable: 44 lbs
• Weight Change Per Rep: +2, +10 (slider values)
• Rest Timer: Rest 60 seconds between sets (60s)
• Auto stop when movement pauses for d...
• Status: AUTO-START READY / Grab handles to start

User's typed feedback (from screenshot):

"In just lift. On an iPhone 16 pro. The weight change per rep is bugged and doesn't do 1 lb increments. The slider does starts at 2 and does arbitrary numbers."

Steps to Reproduce

1. Open the Phoenix app on an iPhone 16 Pro
2. Select "Just Lift" mode
3. Navigate to the "Weight Change Per Rep" setting
4. Attempt to set a 1 lb increment using the slider
5. Observe that the slider starts at 2 and produces arbitrary values instead of 1 lb increments

Expected Behavior

The "Weight Change Per Rep" slider should allow 1 lb increments, starting from 1.

Actual Behavior

The slider starts at 2 and produces arbitrary numbers, not allowing 1 lb increments.

Attachments

• Screenshot: Shows the Just Lift configuration screen with the buggy slider values and user feedback text
• Video (Video.mov): Video demonstrating the slider behavior showing arbitrary increments

Both attachments are cached locally at:
~/.hermes/phoenix-ticket-attachments/1516889360543256738/

Original Discord Report

Devil: Bug report from iOS user:
[image.png] [Video.mov]

Related Issues

• [Bug]: Just Lift weight selection bug #359 (CLOSED) — Different Just Lift weight bug (display discrepancy, v0.6.5)
• [Bug] When warm-up sets are used and weight change per rep is turned on for your working sets, it is also applying the weight change on the warm-up sets #481 (CLOSED) — Weight change per rep applied to warm-up sets (different issue)

Labels

bug, just-lift, weight-change-per-rep, ios, slider

[9thLevelSoftware]

Additional info from Discord thread:

<@1502654170031849644> retrigger

— added by ticket bot

[9thLevelSoftware]

RCA: Weight Change Per Rep slider is hijacked by the Weight per Cable wheel on iPhone (issue #571)

Recreation status used

• REPRODUCED via Video.mov transcription + source analysis. See ~/.hermes/phoenix-bug-recreations/571/bug-recreation.md and evidence/valid-report.json.
• Reporter's screenshot OCR confirms: Just Lift → Old School → 44 lbs/cable → Weight Change Per Rep +2/+10, with the Weight per Cable card and the Weight Change Per Rep card stacked vertically on one screen (Auto-Start/Stop banner at the top).
• rca_research_complete=true, needs_rca_clarification=false. The video shows the visible numeric readout jumping to values (29, 30, 44–49) outside the declared slider range, which is the deciding evidence.

Root cause

The reporter's complaint is not a "1 lb increment" math bug. The Material3 Slider inside ProgressionSlider is correctly bound to valueRange = -10f..10f, steps = 19 (i.e. 21 stops → step size 1 lb) at shared/src/commonMain/kotlin/com/devil/phoenixproject/presentation/components/ExpressiveComponents.kt:117-164. It cannot emit 29, 30, 44, 45, 46, 47, 48, or 49.

The user is not successfully dragging the slider at all. They are dragging the Weight per Cable CompactNumberPicker (iOS implementation, a Compose LazyColumn wheel with rememberSnapFlingBehavior and containerHeight = itemHeight * 3 ≈ 108dp on iPhone portrait — shared/src/iosMain/kotlin/com/devil/phoenixproject/presentation/components/CompactNumberPicker.ios.kt:79-126, 460-498). The 44–49 values match the wheel's natural neighbour weights for a wheel sitting at 44 lbs. The wheel's onValueChange writes to weightPerCable (not the slider), so the visible readout that changes is the Weight per Cable number — the reporter (naturally) reads it as the slider being broken because the value they expected to move was the slider.

Why the wheel is being touched instead of the slider:

1. JustLiftScreen.kt:289 derives val useCompactAccessibility = isCompactAccessibilityLayout(). On iPhone 16 Pro portrait (402dp × 874dp), isCompactAccessibilityLayout() returns true when Dynamic Type ≥ 1.15× or Bold Text is enabled (WindowSizeClass.kt:101-108). The screenshot is consistent with a user who has either setting on (which is common on iOS): the two cards are stacked vertically with Arrangement.spacedBy(Spacing.medium).
2. JustLiftScreen.kt:404, 460 use Modifier.then(if (useCompactAccessibility) Modifier else Modifier.weight(1f)). When useCompactAccessibility=true, the cards drop weight(1f) and become fillMaxWidth() blocks stacked in the column.
3. JustLiftScreen.kt:302 wraps the whole column in Modifier.verticalScroll(contentScrollState) in the same condition.
4. The wheel card is positioned directly above the slider card, separated by Spacing.medium plus the wheel's own padding(Spacing.medium) and label + 8dp (CompactNumberPicker.ios.kt:400-407). The slider card has the same padding(Spacing.medium) plus its title text.
5. The Material3 Slider only handles horizontal drag (it has a valueRange along x; the thumb is a circle on the horizontal track). Any vertical drag on the slider is consumed by the outer verticalScroll, and the wheel — which is a LazyColumn and does claim vertical drags inside its 108dp container — eats anything that lands in the wheel's hit area.
6. When the user puts their finger on (or just above) the slider thumb, Compose's gesture detector often hands the gesture to the closest pointer-input node. With the wheel directly above the slider and verticalArrangement = Arrangement.spacedBy(Spacing.medium) only between the two Cards (not between the wheel and the slider's track), the wheel's hit area extends into the gap the user perceives as the slider's neighborhood. The wheel scrolls, snaps to a neighbour, fires onValueChange → weightPerCable = kg. The wheel's centred overlay then displays the new neighbour (45, 46, … or 30, 29, 1, 0 if flicked the other way).

The "starts at 2" detail in the reporter's text: when the user first releases after a long drag leftward, the wheel's snap-fling can land on a neighbour near 2 lbs if they start near the bottom of the wheel's range. Each subsequent drag continues to drive the wheel, and the reporter keeps seeing "arbitrary" neighbour weights — because the wheel's range is 1..242 with a 1- or 2-lb step, every neighbour looks "arbitrary" relative to the expected -10..+10 slider range.

No code path produces 29/30 from the slider. Verified by inspection of ExpressiveComponents.kt:117-164 and JustLiftScreen.kt:483-488 (slider is bound to weightChangePerRep, valueRange = -10f..10f, steps = 19).

No prior fix. git log over JustLiftScreen.kt, ExpressiveComponents.kt, CompactNumberPicker.ios.kt for this regression pattern returns nothing. PR #510 added tvSliderKeys for TV-remote navigation but that branch is if (!isTvRemoteInputMode) this (no-op on iPhone) at DpadSliderSemantics.kt:75-77.

Affected code

• shared/src/commonMain/kotlin/com/devil/phoenixproject/presentation/screen/JustLiftScreen.kt:289, 302, 404, 460 — stacked layout, outer verticalScroll, dropped weight(1f).
• shared/src/commonMain/kotlin/com/devil/phoenixproject/presentation/components/ExpressiveComponents.kt:117-164 — ProgressionSlider (correct as written; not the bug).
• shared/src/iosMain/kotlin/com/devil/phoenixproject/presentation/components/CompactNumberPicker.ios.kt:79-126, 460-498 — iOS wheel layout: 108dp container height, no pointerInput to release gestures outside the visible centred overlay.

Fix direction (binding for the bugfix agent)

Apply all three together as the minimum correct fix; the first alone hides the issue, the second alone doesn't prevent gesture conflict, the third prevents recurrence on small devices:

1. Reintroduce the two-card row layout on iPhone (do not gate on useCompactAccessibility for these two cards). Keep them side-by-side with Modifier.weight(1f) on iPhone portrait unless the screen is short enough that the cards each fall below the Material-recommended minimum touch target of 48dp. Concretely: split the gate at useCompactAccessibility && heightSizeClass == WindowHeightSizeClass.Compact for the inner-column arrangement, and keep Modifier.weight(1f) for the cards in every other case. This eliminates the wheel-sits-above-slider overlap by construction.
2. Cap the wheel's vertical drag hot zone to the visible selected row when not in edit mode. Add a Modifier.pointerInput(Unit) { detectVerticalDragGesturesOnly(... ) { /* ignore unless inside centred overlay bounds */ } } to the BoxWithConstraints of the wheel such that only the centred 36dp band claims the gesture; the rest of the wheel is Modifier.clickable only (or a no-op) so drags fall through to the outer verticalScroll or to the slider. This must be done at the BoxWithConstraints level, not on the LazyColumn itself, because the wheel needs the snap behavior inside the centred row to keep working.
3. Give the slider card a non-overlapping hit region. The current Modifier.padding(Spacing.medium) on the inner Column plus Arrangement.spacedBy(Spacing.medium) between the two cards is the only vertical separation. Increase the spacing between the cards to Spacing.large (or add an explicit Spacer(Modifier.height(Spacing.small)) between the cards) when useCompactAccessibility=true, so the wheel's bottom edge is unambiguously above the slider's top edge. This is a belt-and-braces guard, not a substitute for (1) or (2).

Non-goals:

• Do not change the Material3 Slider to a RangeSlider — the weightChangePerRep semantics are a single signed value, not a range.
• Do not change the valueRange from -10..10. The reported "starts at 2 and does arbitrary numbers" is not about the slider's allowed range.
• Do not change the wheel to a native iOS UIPickerView. PR [Bug]: Just Lift weight selection bug #359 already documented why Compose LazyColumn was chosen; the wheel logic is correct, only its hit area is wrong.
• Do not introduce a "tap to enter edit mode" affordance on the slider — ProgressionSlider is the right component, the bug is layout, not interaction model.

Acceptance criteria

• On iPhone 16 Pro portrait (402dp × 874dp) with default Dynamic Type and Bold Text off, the Weight per Cable card and the Weight Change Per Rep card are visually side-by-side (the wheel on the left, the slider on the right), not stacked. (Achieved by fix 1.)
• On iPhone 16 Pro portrait with Dynamic Type ≥ 1.15× or Bold Text on (i.e. useCompactAccessibility=true), if the layout is still stacked, dragging on the slider track updates the Weight Change Per Rep value and does not change the Weight per Cable value. Dragging on the wheel updates the Weight per Cable value and does not change the Weight Change Per Rep value. (Achieved by fixes 2 and 3 together; fix 2 alone is sufficient if the inner gesture detector covers the wheel's full visible extent.)
• The visible numeric readout above the Weight Change Per Rep slider can only take values in -10..+10 (the slider's valueRange). Values 11..242 must not be reachable from any user gesture on the slider. (Regression check: hold this invariant with a unit test against the ProgressionSlider Composable; no current test covers this invariant.)
• The wheel's snap-fling and +/- button behavior are unchanged.

Regression test target

Add a Compose UI test (existing commonTest infra at shared/src/commonTest) that:

• Renders JustLiftScreen with useCompactAccessibility=true (force the gate via a test-only LocalWindowSizeClass override) and a known initial state.
• Simulates a performTouchInput swipe starting at the centre of the slider track, vertical component only.
• Asserts weightChangePerRep changes and weightPerCable does not.
• Repeats with the swipe starting at the centre of the wheel.
• Asserts weightPerCable changes and weightChangePerRep does not.

The wheel's onValueChange callback is already wired through JustLiftScreen; the test only needs MainViewModel to expose the two state flows. If the project does not currently have a Compose UI test setup for JustLiftScreen, add one using createComposeRule() and PhoenixTestRule (or equivalent) under shared/src/commonTest/kotlin/com/devil/phoenixproject/presentation/screen/JustLiftScreenTouchRoutingTest.kt.

Reporter-facing follow-up (not needed for the fix)

The reporter's text is sufficient; no clarification is required. They reported mode, weight, weight unit, current weight, observed values, and device. The "retrigger" Discord reply came from a bot (different user_id), not the human reporter.

Files inspected

• shared/src/commonMain/kotlin/com/devil/phoenixproject/presentation/components/ExpressiveComponents.kt:117-164 — ProgressionSlider
• shared/src/iosMain/kotlin/com/devil/phoenixproject/presentation/components/CompactNumberPicker.ios.kt:79-126, 184, 230-243, 460-498, 617-628 — wheel container, snap-fling listener, layout
• shared/src/commonMain/kotlin/com/devil/phoenixproject/presentation/screen/JustLiftScreen.kt:289, 300-304, 322-396, 401-454, 456-496 — outer verticalScroll, stacked-card gate, Weight per Cable picker, ProgressionSlider
• shared/src/commonMain/kotlin/com/devil/phoenixproject/presentation/util/WindowSizeClass.kt:62-108 — isCompactAccessibilityLayout() gate
• shared/src/commonMain/kotlin/com/devil/phoenixproject/presentation/util/DpadSliderSemantics.kt:75-77 — tvSliderKeys no-op on iPhone

Commit under analysis

9b3f637f6b6b178a485a18d14f7f5587d258ee0c (HEAD of main, the 9b3f637 referenced in the recreation artifact).

— RCA authored by GPT-5.5 xhigh (default) for issue #571 / ticket 1516889360543256738.