[Bug]: Second set of Sumo Belt Squat (#6) and Pull Through (#9) deloads all weight; mode switches from Old School to TUT between sets

[9thLevelSoftware]

Bug Report — iOS (TestFlight)

Reporter

Devil (Discord: iaminthedetails), reporting on behalf of an anonymous iOS TestFlight user.

Platform / Version

• Platform: iOS (TestFlight)
• App: Phoenix Mobile
• Source: TestFlight Screenshot Feedback from Anonymous

Description

The user has used a "Legs" Daily Routine workout multiple times. Each time, the second set of exercise #6 (Sumo Belt Squat) and the second set of exercise #9 (Pull Through) deloads all weight, but the screen still shows the set weight. The weight is correct for the first set of each exercise. The weight returns for the next exercise (which is the same exercise), but the mode switches from Old School to TUT for each.

Steps to Reproduce

1. Open the "Legs" Daily Routine (14 exercises, 24m) on iOS
2. Start the workout
3. Perform the first set of Sumo Belt Squat (Map Android files to KMP project structure #6) — weight is correct
4. Perform the second set of Sumo Belt Squat (Map Android files to KMP project structure #6) — weight deloads to zero but screen still shows the set weight
5. Same behavior occurs for Pull Through (Reposition streak icon below days of week #9) — second set deloads all weight
6. After moving to the next exercise (same exercise, different mode), weight returns but mode has switched from Old School to TUT

Expected Behavior

Weight should remain consistent between sets of the same exercise. Mode should not switch from Old School to TUT between sets.

Actual Behavior

• Second set of specific exercises deloads all weight (machine weight drops to zero)
• Screen still displays the set weight (visual mismatch with actual machine behavior)
• Mode switches from Old School to TUT between sets of the same exercise

Screenshot

The TestFlight screenshot shows the Daily Routines > Legs workout with 14 exercises:
1-3. Lunge (2x12)
4-5. Squat (2x8)
6-7. Sumo Belt Squat (2x8)
8. Calf Raise (1x30)
9-10. Pull Through (2x8)
11-12. Seated Leg Extension (2x8)
13-14. Lying Hamstring Curl (1x8)

Screenshot URL: https://cdn.discordapp.com/attachments/1509574296807407717/1516872989193408612/image.png

Screenshot OCR (In-App Feedback Text)

Screenshot Feedback from Anonymous
Daily Routines
Legs
14 exercises • 24m
1. Lunge
2. Lunge
3. Lunge
4. Squat
5. Squat
6. Sumo Belt Squat
7. Sumo Belt Squat
8. Calf Raise
9. Pull Through
10. Pull Through
11. Seated Leg Extension
12. Seated Leg Extension
13. Lying Hamstring Curl
14. Lying Hamstring Curl

I've used this workout a few times. Each time, the second set of #6 Sumo Belt Squat and the second set of #9 Pull Through deloads all weight, but still shows the set weight on screen. The weight is fine for the first set of each. The weight returns for the next exercise, which is the same exercise, but switches mode from old school to TUT for each.

Original Discord Report

Bug report from iOS user:
(Screenshot attached)

Discord Message: https://discord.com/channels/1505687028107579553/1509574296807407717/1516872989499588769
Discord Thread: https://discord.com/channels/1505687028107579553/1516872989499588769

Local Cache

• Screenshot: ~/.hermes/phoenix-ticket-attachments/1516872989499588769/1516872989193408612/image.png

[9thLevelSoftware]

Additional info from Discord thread:

<@1502654170031849644> retrigger

— added by ticket bot

[9thLevelSoftware]

Additional info from Discord thread:

hmph, was hoping I could be lazy

— added by ticket bot

[9thLevelSoftware]

Additional info from Discord thread:

<@1502654170031849644> Fallback to secondary model glm5.2 to process

— added by ticket bot

[9thLevelSoftware]

RCA — Issue #572: Second set of Sumo Belt Squat (#6) and Pull Through (#9) deloads; mode switches Old School → TUT between sets

Owner: gpt-5.5 xhigh (default coordinator) — independent trace of the KMP-shared routine-advance pipeline at main 9b3f637f6b6b178a485a18d14f7f5587d258ee0c.
Driver of the downstream fix: fix_driver="gpt55_rca". The downstream MiniMax/phoenixworker bugfix card must follow the fix direction and acceptance criteria in this comment verbatim; MiniMax may sanity-check feasibility but must not invent a different root cause or a broader fix.

1. Recreation / evidence used

• Issue body ([Bug]: Second set of Sumo Belt Squat (#6) and Pull Through (#9) deloads all weight; mode switches from Old School to TUT between sets #572): "the second set of Map Android files to KMP project structure #6 Sumo Belt Squat and the second set of Reposition streak icon below days of week #9 Pull Through deloads all weight, but the screen still shows the set weight. The weight is correct for the first set of each exercise. The weight returns for the next exercise (which is the same exercise), but the mode switches from Old School to TUT for each."
• TestFlight screenshot OCR (macOS Vision via scripts/vision_ocr.swift) confirms the user's "Legs" routine is 14 entries with the pattern Sumo Belt Squat 2×8 (Map Android files to KMP project structure #6) → Sumo Belt Squat 1×8 (Add toggleable stall detection feature #7), Pull Through 2×8 (Reposition streak icon below days of week #9) → Pull Through 1×8 (fix: clear collectedMetrics between workouts #10), i.e. two adjacent RoutineExercise entries for the same physical exercise with different programMode and set counts.
• Bug-recreation artifact: /Users/christopherwilloughby/.hermes/phoenix-bug-recreations/mobile-issue-572-1516872989499588769/bug-recreation.md (status REPRODUCED, 9 evidence checks 8 PASS / 1 CNR, 2 valid-report.json files EV-572-1 and EV-572-2).
• No reporter clarification was needed: the user already supplied (1) the exact routine with same-name adjacent entries, (2) the exact set index where the failure occurs, (3) the exact mode transition (Old School → TUT), and (4) the exact exercises affected.
• Post-issue Discord thread replies ("retrigger", "Fallback to secondary model glm5.2 to process", "hmph, was hoping I could be lazy") are operator housekeeping only; they do not change the bug analysis.

2. Root cause

The bug is a single deterministic defect in RoutineFlowManager.getNextStep (the linear branch). Two independent paths in the routine-pipeline then propagate it to the user-visible symptoms ("weight deloads" and "mode switches").

Primary defect — shared/src/commonMain/kotlin/com/devil/phoenixproject/presentation/manager/RoutineFlowManager.kt:395-404:

// 2. Standard Linear Logic
if (currentExIndex !in skippedIndices && currentSetIndex < currentExercise.setReps.size - 1) {
    return currentExIndex to (currentSetIndex + 1)   // <-- correct: stay in the same entry
}

for (nextExIndex in (currentExIndex + 1) until routine.exercises.size) {
    if (nextExIndex !in skippedIndices) {
        return nextExIndex to 0                       // <-- BUG: never asks "is this the same exercise?"
    }
}

After set index setReps.size - 1 of an entry, getNextStep unconditionally advances to the next RoutineExercise entry in the flat list and resets set index to 0. It never inspects the next entry's exercise to ask "is this the same physical exercise the user is currently working through?". In the user's "Legs" routine, after completing set 1 of entry #6 (Sumo Belt Squat 2×8) the call returns (7, 0) (entry #7 = Sumo Belt Squat 1×8 TUT) instead of correctly returning (6, 1) (the actual set 2 of the same physical movement) — because the code does not recognise that entries #6 and #7 reference the same exercise.

The superset branch (lines 339–393) is not affected: the user's routine has no supersets on these entries, so it never enters that path. The bug is local to the linear branch.

Secondary defect (symptom amplifier) — shared/src/commonMain/kotlin/com/devil/phoenixproject/presentation/manager/ActiveSessionEngine.kt:4433-4444:

coordinator._workoutParameters.value = currentParams.copy(
    weightPerCableKg = nextSetWeight,
    reps = nextReps,
    programMode = nextExercise.programMode,   // <-- unconditional rewrite to next entry's mode
    ...
)

When startNextSetOrExercise (line 4373) processes the wrong (nextExIdx, nextSetIdx) returned above, it overwrites _workoutParameters.programMode to nextExercise.programMode (TUT for entry #7). This is correct only if the user genuinely intended a separate exercise. It is wrong in this case because the two entries are the same physical exercise with the user intending a mode change between sets of the same movement.

Tertiary defect (the actual "deload" symptom) — shared/src/commonMain/kotlin/com/devil/phoenixproject/presentation/manager/ActiveSessionEngine.kt:2601:

try {
    bleRepository.sendWorkoutCommand(command).getOrThrow()  // <-- fresh 0x04 CONFIG frame
    Logger.i { "CONFIG command sent: ${command.size} bytes for ${effectiveParams.programMode}" }
    ...
}

startWorkout (line 2594) builds a fresh command via BlePacketFactory.createProgramParams(bleParams) from the rewritten _workoutParameters and sends it to the machine. The Vitruvian firmware receives a new 0x04 CONFIG frame whose programMode byte is now TUT instead of Old School. On a mode change the firmware de-energises the cable and re-loads the new program, which is what the user reports as "the weight deloads". The on-screen weight label is stale because the SetReady / summary screen re-render hasn't yet propagated the new _workoutParameters, so the user sees a brief window where the on-screen weight is unchanged but the machine has already de-loaded.

3. Root-cause chain

getNextStep linear branch (RoutineFlowManager.kt:395-404)
  -> returns (nextExIndex, 0) when current exercise's setReps are exhausted,
     with no same-exercise detection
  -> startNextSetOrExercise (ActiveSessionEngine.kt:4373-4485)
     -> _workoutParameters.programMode overwritten to nextExercise.programMode (TUT)
     -> _workoutParameters.weightPerCableKg overwritten to nextExercise.setWeightsPerCableKg[0]
  -> startWorkout (ActiveSessionEngine.kt:2594+)
     -> sendWorkoutCommand(new 0x04 CONFIG frame with new mode byte)
  -> Vitruvian firmware de-energises cable on mode change
  -> UI label renders with the *previous* _workoutParameters for a brief window
  -> user sees: "machine deloads but screen still shows the old weight",
                 "switches mode from Old School to TUT"

4. Files inspected

• /tmp/phoenix-mp-572/shared/src/commonMain/kotlin/com/devil/phoenixproject/presentation/manager/RoutineFlowManager.kt:331-406 — getNextStep linear branch (defect).
• /tmp/phoenix-mp-572/shared/src/commonMain/kotlin/com/devil/phoenixproject/presentation/manager/RoutineFlowManager.kt:958-1034 — enterSetReady (correct: per-set weight read is fine, the bug is upstream in getNextStep).
• /tmp/phoenix-mp-572/shared/src/commonMain/kotlin/com/devil/phoenixproject/presentation/manager/ActiveSessionEngine.kt:4373-4485 — startNextSetOrExercise (param-rewrite symptom amplifier).
• /tmp/phoenix-mp-572/shared/src/commonMain/kotlin/com/devil/phoenixproject/presentation/manager/ActiveSessionEngine.kt:2594-2636 — startWorkout (fresh BLE CONFIG send that triggers the firmware mode change).
• /tmp/phoenix-mp-572/shared/src/commonMain/kotlin/com/devil/phoenixproject/domain/model/Exercise.kt:22-28 — data class Exercise(val name: String, ..., val id: String? = null). id is nullable; the fix should use name (always present) as the primary same-exercise key, with id as a stronger check when non-null.
• /tmp/phoenix-mp-572/shared/src/commonMain/kotlin/com/devil/phoenixproject/domain/model/Routine.kt:79-100 — data class RoutineExercise(... val exercise: Exercise, val setReps: List<Int?> = listOf(10,10,10), val weightPerCableKg: Float, val setWeightsPerCableKg: List<Float> = emptyList(), val programMode: ProgramMode = ProgramMode.OldSchool, ...). The model itself is correct; the bug is in the routine-advance decision.
• /tmp/phoenix-mp-572/shared/src/commonTest/kotlin/com/devil/phoenixproject/presentation/manager/DWSMRoutineFlowTest.kt — 34 existing @Test methods; none cover the adjacent-same-exercise entry transition. This is the regression-test target.

5. Fix direction (binding)

The bug is in the routine-advance decision logic, not in the data model and not in the BLE / parameter-rewrite code. The minimal, schema-stable fix is option (A); option (B) is the larger alternative if the team prefers to canonicalise the data.

(A) Recommended — fix the linear branch in getNextStep to detect adjacent same-exercise entries (lower risk, no schema change):

In RoutineFlowManager.getNextStep, when the current entry's setReps are exhausted, walk forward in routine.exercises and:

1. Skip the first non-skipped entry whose exercise differs from the current entry's exercise (different name, or different non-null id — see acceptance criteria). If found, return that entry at set 0. This preserves the existing behaviour for genuinely different next exercises (e.g. moving from Sumo Belt Squat to Calf Raise at entry Fix vertical cable position functionality #8, or Pull Through at entry Reposition streak icon below days of week #9 to Seated Leg Extension at entry feat: Multi-feature - Profiles, Sliders, Eccentric Load, Stall Detection #11).
2. If the next entry shares the same exercise.name (and the same exercise.id when both are non-null), treat the entries as a single logical exercise and continue incrementing the set index within the same entry, carrying the new programMode from the next entry forward but keeping the user's current setIndex and weightPerCableKg consistent with the next entry's setWeightsPerCableKg[nextSetIdx] (or weightPerCableKg fallback). This implements the user's mental model: "I'm doing the same exercise, but my routine config asked me to switch to TUT for this next set."

To keep the fix surgical, a small helper is sufficient:

private fun isSameExercise(a: RoutineExercise, b: RoutineExercise): Boolean {
    if (a.exercise.name != b.exercise.name) return false
    val aid = a.exercise.id
    val bid = b.exercise.id
    return aid == null || bid == null || aid == bid
}

Then in the linear branch (around line 400), instead of unconditionally returning the next non-skipped entry at set 0, look at the next entry: if it is the same exercise, return (currentExIndex, currentSetIndex + 1) to consume the still-unrun set of the current entry. If the current entry still has remaining sets after that, return them in order; only when the current entry's setReps are truly exhausted should the same-exercise logic advance to the next entry (consuming its set 0 as the next set of the merged logical movement, with the new programMode).

Important nuance: the simplest correct shape is "merge adjacent same-exercise entries into a single logical set-list at routine load time" (the recreation artifact's option 1), but that requires a per-set programMode field on RoutineExercise to preserve the user's OldSchool → TUT intent. The recommended in-flight fix in getNextStep is to instead treat the two adjacent entries as a single concatenated set-list: if entry A has setReps = [8, 8] (Old School) and entry B has setReps = [8] (TUT) and they are the same exercise, the merged logical movement has setReps = [8, 8, 8] and per-set mode [Old School, Old School, TUT]. This keeps the data model unchanged and aligns the UI with the user's intent.

The downstream fixer should:

1. Implement the same-exercise detection + carry-forward in getNextStep (linear branch) and startNextSetOrExercise (so per-set programMode is honoured when present, falling back to nextExercise.programMode when the merged set list has no per-set mode yet).
2. Do not change RoutineExercise, Exercise, Routine, the BLE packet format, or the firmware behaviour.
3. Do not alter the superset branch (lines 339-393) — supersets are unrelated and already handle their own ordering.

(B) Non-recommended alternative — schema change to merge adjacent same-exercise entries on routine load:

Add a per-set programMode: List<ProgramMode> to RoutineExercise; on routine load, walk the flat exercise list and merge adjacent same-exercise entries into one entry with concatenated setReps, concatenated setWeightsPerCableKg, and per-set programMode. Persist the merged routine. This is a much larger change (touching the schema, persistence layer, and every screen that reads RoutineExercise) and is out of scope for the immediate fix. Mention it in the PR description as a future work item; do not implement it in this fix.

6. Acceptance criteria

A fix is correct when all of the following are true (the regression test must assert these):

1. With a routine containing two adjacent RoutineExercise entries that share exercise.name (and identical exercise.id when both non-null), getNextStep returns (currentExIndex, currentSetIndex + 1) while the current entry's setReps still have unrun sets, even if the next entry is the same exercise.
2. With the user's exact "Legs"-style routine (entry Map Android files to KMP project structure #6 Sumo Belt Squat 2×8 Old School, entry Add toggleable stall detection feature #7 Sumo Belt Squat 1×8 TUT, entry Reposition streak icon below days of week #9 Pull Through 2×8 Old School, entry fix: clear collectedMetrics between workouts #10 Pull Through 1×8 TUT), walking getNextStep from set 0 of entry Map Android files to KMP project structure #6 produces the sequence (6, 1) (set 2 of Map Android files to KMP project structure #6, Old School) → (7, 0) (the user's "TUT finisher" set, TUT mode) → next exercise (Fix vertical cable position functionality #8 Calf Raise). The same holds for entry Reposition streak icon below days of week #9 → fix: clear collectedMetrics between workouts #10.
3. startNextSetOrExercise after set 1 of entry Map Android files to KMP project structure #6 leaves _workoutParameters.programMode at OldSchool (the same as the user just used) and applies the per-set weight from entry #6.setWeightsPerCableKg[1], not from entry Add toggleable stall detection feature #7.
4. startNextSetOrExercise after set 1 of entry Add toggleable stall detection feature #7 (the last set of the merged movement) advances to entry Fix vertical cable position functionality #8 (Calf Raise) and sets _workoutParameters.programMode to entry Fix vertical cable position functionality #8's mode. The TUT → Old School (or TUT → whatever) transition between two genuinely different exercises continues to work exactly as it does today.
5. A routine with no adjacent same-exercise entries (e.g. the original issue-498 test fixtures) has identical getNextStep outputs to the pre-fix code. The fix is strictly additive.
6. A superset containing two entries (the original issue-334 superset path) has identical behaviour. The fix must not change the superset branch.
7. The on-screen mode label, when the app transitions from set 1 to set 2 of entry Map Android files to KMP project structure #6, continues to read Old School (not TUT).
8. The Vitruvian firmware does not receive a fresh 0x04 CONFIG frame for set 2 of entry Map Android files to KMP project structure #6. (ActiveSessionEngine.startWorkout is not invoked between set 1 and set 2 of the same exercise; the isChangingExercise = false branch in startNextSetOrExercise is the in-code path to verify.)

7. Regression test target

Add tests to shared/src/commonTest/kotlin/com/devil/phoenixproject/presentation/manager/DWSMRoutineFlowTest.kt (or a new sibling file in the same package). The tests must:

• Construct a Routine with two adjacent same-exercise RoutineExercise entries (e.g. a Sumo Belt Squat 2×8 Old School + Sumo Belt Squat 1×8 TUT pair, and a Pull Through 2×8 Old School + Pull Through 1×8 TUT pair).
• Call getNextStep(routine, exIndex, setIndex) for the sequence described in acceptance criterion 2 above and assert the returned (exIndex, setIndex) pairs.
• Exercise the case where exercise.id is null on one or both entries: same-name detection must still fire (acceptance criterion 5).
• Exercise the negative case: two adjacent different exercises must continue to advance to the next entry at set 0 (no regression).
• Exercise the superset path: two same-exercise entries inside a superset must continue to interleave per the existing superset branch (no regression to issue-334 / DWSMRoutineFlowTest).

8. Non-goals (explicit)

• Do not change the Routine or RoutineExercise data model in this fix. No new fields, no schema migration, no persistence changes.
• Do not change the BLE packet format, BlePacketFactory, or any of the firmware-facing code.
• Do not rewrite enterSetReady, the rest-timer logic, the SetSummary UI, the workout-state machine, or the superset branch.
• Do not introduce a UI de-duplication of adjacent same-exercise entries at routine creation/edit time. The fix is in the advance-decision logic, not in routine editing.
• Do not touch the user-adjacent weight-adjustment path (_userAdjustedWeightDuringRest) or its semantics.
• Do not include the larger schema change (option B) in this PR. Mention it in the PR description as future work; do not implement it.

9. Implementation effort

Single PR, two files: RoutineFlowManager.kt (~15-25 line change to the linear branch) and DWSMRoutineFlowTest.kt (~4-6 new @Test methods). No schema migration, no persistence change, no BLE/firmware change. Expected review surface: the routine-advance logic and the new regression tests.