Label set types in workout UI: Calibration Reps, Warm-up Sets, Working Sets

[9thLevelSoftware]

Summary

Distinguish the three different set types in the workout UI with clear labels, so users can tell at a glance whether they are doing the 3 pre-set ROM Calibration Reps, optional Warm-up Sets, or the routine's Working Sets.

Reporter

• Discord user: stugotz0955_50891
• Source: #feature-requests thread 1525152789725188258
• Repo: 9thlevelsoftware/project-phoenix-mp (mobile)

Motivation

Today the workout UI does not visually differentiate between:

1. The 3 ROM reps that run before every set (currently unnamed in the UI — reporter calls these "Calibration Reps").
2. The optional Warm-up Sets that can be enabled when configuring an exercise.
3. The routine's normal sets — reporter wants these labeled Working Sets.

The reporter notes they frequently forget they have Warm-up Sets enabled on some exercises (especially when a prior compound movement already warmed up the target muscle groups), because the UI does not flag the difference.

Requested Behavior

When a set starts, label it in the workout UI so the user can tell which kind of set they are about to perform:

• The 3 pre-set ROM reps → display as "Calibration Reps".
• Sets from an exercise with the Warm-up Sets option enabled → display as "Warm-up Sets".
• Normal routine sets → display as "Working Sets".

The labels should be visible enough that the user can recognize them mid-workout without reading the small text.

Suggested Scope (non-binding)

• A small set-type tag/badge on the per-set header (or equivalent surface) in the active-workout screen.
• Tag color or weight can follow the existing Phoenix theme — no new design system required.
• Touch only the mobile UI; no protocol, BLE, or backend change is implied.

Expected Behavior

Each set in the active workout is clearly labeled "Calibration Reps", "Warm-up Set(s)", or "Working Set(s)" so the user always knows what kind of set is next.

Actual Behavior (today)

All sets look the same in the UI. The 3 ROM reps are not labeled, Warm-up Sets are not visually distinct from Working Sets, and the reporter regularly forgets Warm-up Sets are enabled.

Impact

• Reduces confusion mid-workout.
• Makes Warm-up Sets (which the reporter often forgets are on) self-evident.
• No firmware / hardware impact.

Attachments

• No Discord attachments on the original report.

Original Discord Report

<@1502654170031849644> Thoughts on distinguishing between the different type of sets on the UI so the current 3 ROM reps before every set is labeled as Calibration Reps, then if "Warm-up Sets" are activated when configuring exercises those are displayed as "Warm-up Sets" and then Normal sets within a routine are labeled "Working Sets".  I frequently forget I have Warm-up Sets enabled for some sets (only if a prior compound exercise didn't already warm-up those muscle groups) and the UI doesn't currently distinguish between those 3 ROM calibration reps and warm-up sets.

[9thLevelSoftware]

Feasibility — accept

UI-only label change in the mobile repo. No protocol, BLE, schema, or backend impact.

Scope

• Active-workout set header / per-set card label only.
• Three labels: Calibration Reps (the 3 pre-set ROM reps), Warm-up Sets (when the exercise config flag is on), Working Sets (routine normal sets).

Assumptions

1. The exercise config already exposes a Warm-up Sets toggle.
2. The workout engine already distinguishes ROM reps from working reps internally (no new state needed to label them).
3. The three labels are final as proposed.
4. Mobile-only.

Risks

• Low. Residual: the label source must be pinned to the same authoritative discriminator the engine uses, so labels can't drift from runtime behavior. Architecture stage will verify.

Effort

• Architecture + prototype: ~30–60 min. Implementation: small. Tests: light.

Next
Advancing to the architecture stage. Artifact: ~/.hermes/phoenix-enhancements/issue-646-1525152789725188258/feasibility.md.

[9thLevelSoftware]

Architecture — accept

UI-only label patch in mobile repo. No protocol, BLE, schema, backend, or DB impact.

Single source of truth — three existing engine signals map 1:1 to the three labels (so labels can't drift from runtime behavior):

• Calibration Reps: repCount.warmupReps < 3 && !repCount.isWarmupComplete (firmware pre-set ROM/calibration buffer)
• Warm-up Set N: coordinator.currentWarmupSetIndex.value >= 0 (variable warm-up phase in progress)
• Working Set: else

Surface — new SetTypeBadge composable in two call sites:

• WorkoutHud.kt:499-507 (active-workout set header, next to the existing "Set X / Y")
• SetReadyScreen.kt:384-401 (Set Ready header, so the user knows what kind of set they're about to start)

Just Lift is naturally excluded by the existing !isJustLift guard at WorkoutHud.kt:486.

Strings (i18n-additive, no existing keys changed):

• set_type_calibration → "Calibration Reps"
• set_type_warmup → "Warm-up Set %1$d"
• set_type_working → "Working Set"

Acceptance: 1) First 3 reps show "Calibration Reps"; 2) currentWarmupSetIndex >= 0 shows "Warm-up Set N"; 3) otherwise "Working Set"; 4) Just Lift hides all three; 5) Set Ready carries the same label; 6) no hard-coded strings; 7) existing tests pass + one small composable test for the three states.

Non-goals: no BLE / protocol change, no set-completion change, no rename of the existing "REP"/"WARMUP" rep-counter labels (those label the current rep phase, not the set type — both labels co-exist).

Artifact: ~/.hermes/phoenix-enhancements/issue-646-1525152789725188258/architecture.md.

Advancing to integration model.

[9thLevelSoftware]

Integration model — accept

Bounded to 6 files. UI-only patch, no state/DB/BLE/protocol changes.

Surface

• WorkoutHud.kt — add currentWarmupSetIndex: Int = -1 param; render label inside existing !isJustLift && exerciseName != null guard, under "Set X / Y".
• WorkoutTab.kt — pass currentWarmupSetIndex through to WorkoutHud (1-line).
• SetReadyScreen.kt — add viewModel.currentWarmupSetIndex.collectAsState(); render "Warm-up Set N" / "Working Set" next to the existing "Set X of Y" picker.
• 6 × strings.xml (en + de/es/fr/it/nl) — add set_type_calibration, set_type_warmup (%1$d), set_type_working.
• 1 new test: SetTypeLabelTest.kt (pure Kotlin helper).

Architecture corrections (worth flagging before implementation)

1. Architecture said WorkoutHud "already collects currentWarmupSetIndex" — it doesn't; needs a new param. WorkoutState.Active is an object, not a data class, so it can't carry the index.
2. Architecture said SetReadyScreen needs "no extra plumbing" — it currently has no warm-up signal. Needs one collectAsState + a showCalibrationLabel=false flag at that call site (calibration reps run during the active set, not at SetReady — the buffer hasn't happened yet).

Acceptance

1. :shared:test green.
2. Routine w/ Warm-up Sets: SetReady + active HUD both show "Warm-up Set 1/N" for warmups, "Working Set" after.
3. Routine w/o Warm-up Sets: active HUD shows "Calibration Reps" for first 3 reps, then clears.
4. Just Lift: no set-type label.

Artifact: ~/.hermes/phoenix-enhancements/issue-646-1525152789725188258/integration-model.md.

Advancing to prototype / implementation.

[9thLevelSoftware]

Prototype ready for review — issue #646

Three set-type labels (Calibration Reps / Warm-up Set N / Working Set) wired into the active workout header and SetReady header, no new design tokens. UI mockup attached.

Live preview (renders inline in browser): https://gist.github.com/9thLevelSoftware/5bf123a90c87aef44337aaad58dfc6a7

What the prototype shows

• Active workout (WorkoutHud) — three label states:
  • amber Calibration Reps during the firmware 3-rep pre-buffer
  • cyan Warm-up Set 1 of 2 when currentWarmupSetIndex >= 0
  • orange Working Set for normal routine sets
• SetReady header — compact chip next to the existing "Set X of Y" picker ("Warm-up" / "Working"). Calibration chip is intentionally suppressed at this screen (rom reps run during the active set, not at SetReady — see integration-model.md §Edge cases Mirror parent app homescreen design #3).
• Just Lift control — no label (rides the existing !isJustLift guard).

Design decisions (no new tokens)

• New label uses the same titleLarge/labelLarge + onSurfaceVariant weight as the existing "Set X / Y" — no new typography, no new color, no new shape.
• Colors map to existing theme: PhoenixOrangeDark (primary), AshBlueDark (tertiary), SignalWarning amber (calibration), on primary container text on the SetReady orange header.
• Strings will live in shared/src/commonMain/composeResources/values/strings.xml (set_type_calibration, set_type_warmup with %1$d, set_type_working) + 5 locale mirrors.

Signoff

A 👍 / +1 / thumbs-up on this comment or on the Discord prototype message counts as acceptance. A reply with requested changes routes back to a new prototype pass.

Local PNG (final emulator capture is still owed at implementation stage): /Users/christopherwilloughby/.hermes/phoenix-enhancements/issue-646-1525152789725188258/prototype/prototype-overview.png (1300×2900)

Artifacts

• prototype/index.html — source
• prototype/prototype-overview.png — render
• prototype/visual-notes.md — source files + theme tokens that informed the mockup
• prototype/prototype-gate.md — acceptance criteria mapping

Next stage

Advance to implementation (bounded file list in integration-model.md). PR will land on a feature branch, capture final emulator visuals, then request review.

[9thLevelSoftware]

Implementation plan (signoff approved)

Bounded UI-only patch — no BLE/protocol/DB/backend change.

Scope (3 screen files + 6 locale strings + 1 helper + 1 test):

• shared/src/commonMain/kotlin/.../screen/WorkoutHud.kt — add currentWarmupSetIndex: Int = -1 param; render label under existing "Set X / Y" inside the !isJustLift guard.
• shared/src/commonMain/kotlin/.../screen/SetReadyScreen.kt — viewModel.currentWarmupSetIndex.collectAsState(); render label next to the "Set X of Y" picker with showCalibrationLabel = false (calibration reps run during the active set, not at SetReady).
• shared/src/commonMain/kotlin/.../screen/WorkoutTab.kt — pass currentWarmupSetIndex into WorkoutHud(...).
• New shared/src/commonMain/kotlin/.../util/SetTypeLabel.kt — pure-Kotlin helper returning Calibration | Warmup(n) | Working. No @Composable, locale-free, trivially testable.
• 6× values*/strings.xml — add set_type_calibration, set_type_warmup (%1$d), set_type_working.
• New shared/src/commonTest/kotlin/.../SetTypeLabelTest.kt — pure-Kotlin test for all 4 helper outcomes.

Helper logic (single source of truth):

when {
  showCalibrationLabel && repCount.warmupReps < 3 && !repCount.isWarmupComplete -> Calibration
  currentWarmupSetIndex >= 0 -> Warmup(currentWarmupSetIndex + 1)
  else -> Working
}

Labels ride the existing MaterialTheme.colorScheme.onSurfaceVariant / tertiary typography. No new color/typography/shape tokens. Just Lift excluded by the existing guard.

Forbidden scope (PR will be rejected with scope drift): ActiveSessionEngine.kt, RoutineFlowManager.kt, WorkoutCoordinator.kt, BLE/protocol code, DB schema/migrations, SetSummaryCard.kt, phoenix-portal.

Visual evidence (UI-involved gate): 7 emulator PNGs (1080×2400) captured on the phoenix_phantom_api36 AVD before PR hardening — Calibration, Warm-up Set 1, Warm-up Set 2, Working, SetReady warm-up, SetReady working, Just Lift control. Stored under final-visuals/<branch>/android/ and linked from the PR body.

Acceptance: ./gradlew :shared:test green; manual smoke for warm-up-on/warm-up-off/Just-Lift; PR body contains Fixes #646; gh pr checks green.

Full spec + acceptance criteria + visual QA packet: /Users/christopherwilloughby/.hermes/phoenix-enhancements/issue-646-1525152789725188258/implementation-spec.md
User-facing notes + release-note draft: /Users/christopherwilloughby/.hermes/phoenix-enhancements/issue-646-1525152789725188258/user-instructions.md