[Bug]: Weighted Vest not added to body weight for Effective Load on body-weight exercises

[9thLevelSoftware]

Reported via Discord by: stugotz0955_50891 (thread 1514741879390867667)

Type: Bug

Repo: mobile (9thlevelsoftware/project-phoenix-mp)

Summary

On Android 16 (Pixel 10XL Pro, app v0.9.2), before a body-weight exercise (Decline Push Up, Decline 18" variant), the Equipment Rack cannot be scrolled to confirm that the Weighted Vest is selected, and the selected 8 lb vest does not appear to be included in the body-weight value used to calculate the Effective Load for the set.

There appear to be two related symptoms in the same flow:

1. Equipment Rack scroll is blocked before the body-weight exercise starts, so the user cannot verify (or toggle) the Weighted Vest selection on the live-set screen.
2. Effective Load ignores the Weighted Vest mass. The user reports the configured 8 lb vest is selected, but the calculated Effective Load does not add the 8 lb to the body-weight input before applying the decline factor — i.e. the displayed Effective Load under-counts the resistance the user is actually lifting.

Environment

Field	Value
Platform	Android 16
Device	Pixel 10XL Pro
App version	v0.9.2
Channel	bug-reports

Steps to Reproduce

1. Open a routine that contains a body-weight exercise (Decline Push Up, Decline 18" variant used by the reporter).
2. Set the Weighted Vest to 8 lb in the Equipment Rack.
3. Navigate to the live-set screen for the body-weight exercise.
4. Try to scroll the Equipment Rack panel to confirm the Weighted Vest is still selected and to see/change its value.
5. Tap Start and complete a set; enter the body-weight reps in the "Enter bodyweight reps" modal.
6. Observe the displayed Effective load for the set.

Expected Behavior

• The Equipment Rack panel on the live-set screen for a body-weight exercise should be scrollable (or otherwise expandable) so the user can confirm/change the Weighted Vest selection immediately before starting the set.
• When the Weighted Vest is selected, its configured mass (8 lb in this report) should be added to the user's body-weight input before the decline factor is applied, so the Effective Load reflects the vest's contribution.

Actual Behavior

• The Equipment Rack is not scrollable on the live-set screen for the body-weight exercise, so the user cannot confirm the Weighted Vest is currently selected.
• The Effective Load calculation appears to omit the selected 8 lb Weighted Vest, so the displayed value is lower than the resistance the user is actually working against.

Impact

• Effective Load (and therefore per-set Volume = Effective load × reps) is mis-reported for body-weight exercises whenever a vest (or similar body-weight accessory) is selected. Volume/analytics for these exercises is understated.
• Users have no way to verify or correct the vest selection on the live-set screen, which makes the bug invisible at the moment of execution and harder to report.
• Affects at least Decline Push Up at Decline 18"; likely affects any body-weight exercise variant that supports a Weighted Vest in the Equipment Rack.

Screenshots / Attachments

• Equipment Rack view (live-set screen, Decline Push Up / Decline 18"): https://cdn.discordapp.com/attachments/1509574296807407717/1514741878581497937/get.png
  • Shows the Equipment Rack is not scrollable down to the Weighted Vest row. Visible items: Dual Cable Retractor +7.5 lb, Neutral Wide Wide Grip Pulldown -8 lb, Ropes +2 lb, Short Bar +2 lb, Short Bar -2 lb. Effective load reads 116.6 lb.
• "Enter bodyweight reps" modal for Set 2 of 3, Decline 18": https://cdn.discordapp.com/attachments/1509574296807407717/1514741879034613821/get.png
  • Reps entered: 25. Effective load: 116.8 lb. Volume: 2919.99 lb. Confirms the Effective Load is computed from body weight + decline factor but does not visibly include the configured 8 lb vest.

Missing Info / Follow-up Questions

• Does the same omission occur for other body-weight accessory items in the Equipment Rack (e.g. ankle weights, dip belt) when configured?
• Does the Equipment Rack scrollability issue reproduce only on body-weight exercises, or on all live-set screens?
• Is the Weighted Vest persisted in the user's profile and re-applied to live sets, or is the live-set screen using a stale/empty selection?

Original Discord Report

<@1502654170031849644>
Android 16
Pixel 10XL Pro
v0.9.2

Unable to scroll Equipment Rack before body weight exercise to confirm Weighted Vest is selected.  It doesn't appear to have added the selected 8lb to my body weight before it  calculated effective load for the decline push-ups.

[9thLevelSoftware]

Bug recreation complete for issue #534 (Discord thread 1514741879390867667).

Status: REPRODUCED (helper-level / code-path, deterministic; live emulator run was blocked by a worker-host JRE issue, not a product issue).
Repo / commit: 9thlevelsoftware/project-phoenix-mp @ 54590ec (branch pr-502-equipment-rack)
RCA readiness: READY

Findings (4 product failures, all on the body-weight path):

1. SetReadyScreen.kt:407 — live-set "Effective load" ignores the Weighted Vest. The formula is effectiveKg = userPrefs.bodyWeightKg * selectedVariant.percentage with no rack adjustment folded in.
2. WorkoutTab.kt:1209 — "Enter bodyweight reps" modal "Effective load" and "Volume" ignore the vest. Same formula: effectiveWeightKg = entry.bodyWeightKg * selectedVariant.percentage.
3. SetReadyScreen.SetReadyRackSelectionCard — rack selection card has no verticalScroll modifier, so rack items below the fold (including the Weighted Vest) are unreachable behind the fixed bottom action bar. This matches the "Unable to scroll Equipment Rack" complaint and the visibly-clipped last row in the reporter's first screenshot.
4. ActiveSessionEngine — coordinator._currentRackLoadAdjustment is only ever written on the cable-exercise / BLE-write path (applyRackToWorkoutParams / applyRackToBleParams). The body-weight post-timer path (confirmBodyweightSetResult -> handleSetCompletion) never writes it, so applyBodyweightVolume reads the empty default and the recorded CompletedSet row's peakLoadKgPerCable / totalVolumeKg omit the vest.

Helper-level validation: ApplyEquipmentRackLoadUseCaseTest passes 7/7 on commit 54590ec, including the bodyweight effective load includes added load and counterweight test (asserts 100 kg body * 0.95 + 10 kg vest - 25 kg counterweight = 80 kg). The use case math is correct in isolation; the failure is in the UI display formulas and the engine call-site wiring for the body-weight path.

Numerics (match the reporter's screenshots to the lb):

• 160 lb body weight, 8 lb vest, Decline 18" (73%): displayed 116.8 lb vs expected 122.6 lb (gap = 5.84 lb = 8 * 0.73).
• Volume at 25 reps: displayed 2919.99 lb vs expected 3066.0 lb (gap = 146.0 lb = 8 * 0.73 * 25).

Bug recreation document + per-failure valid reports are ready for the RCA agent. Setting needs_rca = true on the ticket state.

[9thLevelSoftware]

RCA: Issue #534 — Weighted Vest not added to body weight for Effective Load on body-weight exercises

Symptom (from reporter stugotz0955_50891, Android 16 / Pixel 10XL Pro / v0.9.2)

User reports two coupled defects on Decline Push Up — Decline 18" with an 8 lb Weighted Vest active in the Equipment Rack:

1. UX bug: The Equipment Rack panel on the live-set screen is not scrollable, so with 5+ rack items the Weighted Vest is hidden below the fold and the user cannot confirm the selection immediately before starting the set.
2. Math bug: The on-screen "Effective load" (live-set screen and "Enter bodyweight reps" modal) and the recorded CompletedSet.peakLoadKgPerCable / totalVolumeKg all ignore the vest. The reporter's screenshots show 116.6 lb (live-set) and 116.8 lb / Volume 2919.99 lb at 25 reps (modal) — both equal bodyWeightKg × percentage, with no vest contribution. With the vest the live-set should show ~122.5 lb and the modal should show a higher volume.

Recreation status

Bug recreation agent ran a helper-level / code-path reproduction (live emulator was blocked on this worker host — no JRE registered with avdmanager; environment limitation, not product failure). Status: REPRODUCED.

Evidence:

• Artifact: ~/.hermes/phoenix-bug-recreations/mobile-issue-534-1514741879390867667/bug-recreation.md
• Per-failure valid reports: evidence/valid-report-EV-{01..04}.json
• Source snippets: evidence/source-*.txt
• Numeric repro: evidence/numeric-repro-decline-18.txt (matches reporter to the lb)
• ApplyEquipmentRackLoadUseCaseTest (7/7) at commit 54590ec0: evidence/test-results-ApplyEquipmentRackLoadUseCaseTest.xml
• Repro branch / commit: pr-502-equipment-rack @ 54590ec0 ("Preserve rack context in legacy sync merges")

Helper math is correct in isolation: 7/7 tests pass, including the bodyweight effective load includes added load and counterweight assertion that proves the use case adds vest mass to body weight correctly. The product failure is purely in the UI formula and in the engine's call-site wiring for the body-weight path.

Root cause

Four deterministic product defects on the body-weight path. The Equipment Rack feature is fully present in v0.9.2 and is wired up correctly for cable exercises; the body-weight path never finishes the wiring.

RC-1 — SetReadyScreen.kt:419 live-set "Effective load" omits the vest (formula bug)

// shared/src/commonMain/kotlin/com/devil/phoenixproject/presentation/screen/SetReadyScreen.kt:417-431
val userPrefs by viewModel.userPreferences.collectAsState()
if (userPrefs.bodyWeightKg > 0f) {
    val effectiveKg = userPrefs.bodyWeightKg * selectedVariant.percentage
    val displayWeight = if (weightUnit == WeightUnit.KG) {
        "${com.devil.phoenixproject.util.UnitConverter.formatDecimal(effectiveKg)} kg"
    } else {
        "${com.devil.phoenixproject.util.UnitConverter.formatDecimal(com.devil.phoenixproject.util.UnitConverter.kgToLb(effectiveKg))} lb"
    }
    Spacer(Modifier.height(4.dp))
    Text("Effective load: $displayWeight", ...)
}

The on-screen "Effective load" is computed as bodyWeightKg × percentage only. It never calls applyEquipmentRackLoadUseCase.calculateBodyweightEffectiveLoadKg (defined at shared/src/commonMain/kotlin/com/devil/phoenixproject/domain/usecase/ApplyEquipmentRackLoadUseCase.kt:44) and never reads the active rack items. Result: the displayed value is the bare body-weight value, with no vest contribution.

Numeric: reporter screenshots show 116.6 lb. Computed: 159.7 lb × 0.73 = 116.581 lb ≈ 116.6 lb. With the 8 lb vest, the correct value would be (159.7 + 8) × 0.73 = 122.464 lb ≈ 122.5 lb — a gap of exactly the vest's contribution.

RC-2 — WorkoutTab.kt:1209 "Enter bodyweight reps" modal "Effective load" / "Volume" omits the vest (formula bug)

// shared/src/commonMain/kotlin/com/devil/phoenixproject/presentation/screen/WorkoutTab.kt:1209-1214
val effectiveWeightKg = if (entry.bodyWeightKg > 0f) {
    entry.bodyWeightKg * selectedVariant.percentage
} else {
    0f
}
val volumeKg = effectiveWeightKg * reps

Same defect as RC-1 in the post-timer dialog. The modal is the last thing the user sees before tapping "Save Set", so this is also the value the user is most likely to trust and report. Reporter's modal screenshot shows Effective load: 116.8 lb / Volume: 2919.99 lb at 25 reps; computed: 116.8 × 25 = 2920 lb ≈ 2919.99 lb. The recorded set is then written from this volume, so the off-by-vest-mass error is persisted to history.

RC-3 — SetReadyRackSelectionCard is not vertically scrollable (layout bug)

// shared/src/commonMain/kotlin/com/devil/phoenixproject/presentation/screen/SetReadyScreen.kt:617-672
Card(
    modifier = Modifier.fillMaxWidth(),
    shape = RoundedCornerShape(16.dp),
    colors = CardDefaults.cardColors(containerColor = MaterialTheme.colorScheme.surfaceContainerHighest),
) {
    Column(
        modifier = Modifier
            .fillMaxWidth()
            .padding(Spacing.medium),
        verticalArrangement = Arrangement.spacedBy(Spacing.small),
    ) {
        ...
        enabledItems.forEach { item ->
            FilterChip(selected = selected, onClick = { ... }, label = { ... })
        }
        ...
    }
}

SetReadyRackSelectionCard (lines 600-688) renders the enabled rack items as FilterChips inside a plain Column — no Modifier.verticalScroll(rememberScrollState()) on the inner Column, and the parent SetReadyScreen body Column (line 270, fillMaxSize().padding(padding).padding(horizontal = 16.dp)) is also non-scrollable. With 5+ items the bottom rows are hidden by the fixed bottom action bar. The reporter's screenshot #1 shows the last rack item visibly clipped at the bottom edge of the rack card. This is the layout defect that makes the vest unreachable for confirmation before the set.

RC-4 — ActiveSessionEngine._currentRackLoadAdjustment is never written on the body-weight path (engine wiring bug)

The only writers of coordinator._currentRackLoadAdjustment.value are the cable/BLE functions:

// shared/src/commonMain/kotlin/com/devil/phoenixproject/presentation/manager/ActiveSessionEngine.kt:454-456
validatorMinimumPerCableKg = validatorSafeMinimum(params),
)
coordinator._currentRackLoadAdjustment.value = adjustment
// ...
// shared/src/commonMain/kotlin/com/devil/phoenixproject/presentation/manager/ActiveSessionEngine.kt:467-468
private fun applyRackToBleParams(
    params: WorkoutParameters,
    displayMultiplier: Int,

applyRackToWorkoutParams (~line 449) and applyRackToBleParams (line 467) are reached only from the cable-exercise / BLE write path (called by startSetForCableExercise and applyRackToBleParams callers near line 2391).

The body-weight post-timer flow does not call either writer:

// shared/src/commonMain/kotlin/com/devil/phoenixproject/presentation/manager/ActiveSessionEngine.kt:834-845
fun confirmBodyweightSetResult(reps: Int, variant: BodyweightVariantOption) {
    val entry = coordinator._workoutState.value as? WorkoutState.BodyweightRepEntry ?: return
    val coercedReps = reps.coerceAtLeast(0)
    selectBodyweightVariant(entry.exerciseKey, variant)
    coordinator.bodyweightCompletionVariantOverride = variant
    coordinator._repCount.value = RepCount(workingReps = coercedReps, totalReps = coercedReps, isWarmupComplete = true)
    handleSetCompletion()
}

confirmBodyweightSetResult calls handleSetCompletion(), which (via the body-weight branch around line 3602-3605) calls applyBodyweightVolume(raw, currentExercise, bodyWeightKg, selectedBodyweightVariant). applyBodyweightVolume reads the rack adjustment at line 789:

val rackAdjustment = coordinator._currentRackLoadAdjustment.value

…but the body-weight path never wrote that field, so rackAdjustment is the empty RackLoadAdjustment() default with externalAddedLoadKg = 0 and counterweightKg = 0. The 5-arg BodyweightVolumeCalculator.calculateVolume (which is otherwise correct: (bodyWeightKg * percentage + externalAddedLoadKg - counterweightKg).coerceAtLeast(0f) * reps — see shared/src/commonMain/kotlin/com/devil/phoenixproject/domain/usecase/BodyweightVolumeCalculator.kt:191-198) therefore receives zeros for the rack terms and computes the vest-less volume. The bug is the missing write, not the calculator.

The same gap exists for the body-weight "complete" path around line 3248 and the body-weight "handleSetCompletion" path around line 2769. None of them write _currentRackLoadAdjustment.value before invoking applyBodyweightVolume.

Files / components involved

• shared/src/commonMain/kotlin/com/devil/phoenixproject/presentation/screen/SetReadyScreen.kt
  • line 419 — effectiveKg = bodyWeightKg * percentage (RC-1)
  • lines 600-688 — SetReadyRackSelectionCard non-scrollable Column (RC-3)
  • line 270 — parent SetReadyScreen body Column also non-scrollable (contributes to RC-3)
• shared/src/commonMain/kotlin/com/devil/phoenixproject/presentation/screen/WorkoutTab.kt
  • lines 1209-1214 — BodyweightRepEntryDialog formula (RC-2)
• shared/src/commonMain/kotlin/com/devil/phoenixproject/presentation/manager/ActiveSessionEngine.kt
  • lines 449-456 — applyRackToWorkoutParams (the only _currentRackLoadAdjustment.value writer for the workout params path)
  • lines 467-... — applyRackToBleParams (the other writer)
  • lines 773-820 — applyBodyweightVolume (reads _currentRackLoadAdjustment.value, multiplies by reps, writes back to SetSummary)
  • lines 834-845 — confirmBodyweightSetResult (body-weight post-timer path that never invokes a rack writer)
  • lines 3602-3605 — body-weight handleSetCompletion call to applyBodyweightVolume
  • lines 3246-3248 — body-weight completion path call to applyBodyweightVolume
• shared/src/commonMain/kotlin/com/devil/phoenixproject/domain/usecase/BodyweightVolumeCalculator.kt
  • lines 191-198 — 5-arg effectiveWeight (correct formula, bodyWeightKg * percentage + externalAddedLoadKg - counterweightKg, coerce ≥ 0)
  • lines 151-165 — 5-arg calculateVolume (correct formula)
• shared/src/commonMain/kotlin/com/devil/phoenixproject/domain/usecase/ApplyEquipmentRackLoadUseCase.kt
  • calculateBodyweightEffectiveLoadKg exists and is the helper the UI should be calling for on-screen "Effective load" (RC-1 fix)
• shared/src/commonMain/kotlin/com/devil/phoenixproject/domain/model/EquipmentRack.kt
  • RackItemCategory.WEIGHTED_VEST, RackItemBehavior.ADDED_RESISTANCE / COUNTERWEIGHT / DISPLAY_ONLY
  • RackLoadAdjustment data class (empty defaults are the failure mode on the body-weight path)

Suggested fix

Smallest correct patch, in order of priority:

1. SetReadyScreen.kt:419 (RC-1) — replace the inline effectiveKg = bodyWeightKg * percentage with a call to viewModel.calculateBodyweightEffectiveLoad() (or call applyEquipmentRackLoadUseCase.calculateBodyweightEffectiveLoadKg(bodyWeightKg, selectedVariant.percentage, activeRackItems) directly) so the on-screen "Effective load" includes vest mass.
2. WorkoutTab.kt:1209-1214 (RC-2) — same fix in BodyweightRepEntryDialog. The modal should use applyEquipmentRackLoadUseCase.calculateBodyweightEffectiveLoadKg with the live activeRackItems so the user sees and saves a vest-aware volume.
3. SetReadyScreen.kt SetReadyRackSelectionCard (RC-3) — wrap the inner Column in Modifier.verticalScroll(rememberScrollState()) (and consider the same for the parent SetReadyScreen body Column at line 270). Optionally migrate the enabledItems.forEach { FilterChip(...) } to a LazyColumn to keep render cost reasonable once item count grows.
4. ActiveSessionEngine.confirmBodyweightSetResult (RC-4) — before handleSetCompletion(), compute the active rack adjustment with applyEquipmentRackLoadUseCase.calculate(...) from the live activeRackItems (or snapshot it at the moment the user enters the modal) and write coordinator._currentRackLoadAdjustment.value = adjustment. The same writer should be added at the body-weight completion path (~line 3246) and at the body-weight handleSetCompletion path (~line 3602) so all three body-weight call sites see a non-empty adjustment.
5. Tests — add an integration test (Android host or commonTest fakes) that exercises confirmBodyweightSetResult with a non-empty activeRackItems containing a Weighted Vest, then asserts the persisted CompletedSet.peakLoadKgPerCable includes the vest and totalVolumeKg equals (bodyWeight + vest) × percentage × reps. Add a SetReadyScreen UI test (Robolectric / Compose UI test) that asserts the displayed "Effective load" text contains the vest contribution. Add a SetReadyRackSelectionCard UI test that asserts the rack panel scrolls when item count exceeds the viewport.

Caveats

• Recreation was helper-level / code-path; live emulator run was blocked by the worker-host JRE issue. The product failure verdict is still deterministic because the failing call sites are the production entry points the v0.9.2 build ships, and the helper-level reproduction matches the reporter's screenshots to the lb.
• BodyweightVolumeCalculator's 5-arg effectiveWeight and calculateVolume are correct in isolation (ApplyEquipmentRackLoadUseCaseTest 7/7). Do not modify the calculator while fixing this; the fix lives in the UI / engine wiring.
• A cable-exercise set with a vest active does record the vest contribution correctly, because applyRackToWorkoutParams runs on that path. The defect is specifically on the body-weight path, where no rack writer runs before the engine reads _currentRackLoadAdjustment.value.