AMRAP routine: warmup reps not counted (no sound), set won't auto-end

[9thLevelSoftware]

Bug Report: ROM Error When Set to AMRAP — Warmup Reps Not Counting, Set Won't Auto-End

Reporter: evulnater (Discord)
Type: Bug
Repo: Mobile (project-phoenix-mp)
Channel: #bug-reports (Discord thread 1540545440380882984)

---

Summary

When a routine exercise is set to AMRAP mode, warmup reps are not counted (no sound plays), and after 3 warmup reps the working weight kicks in but the set never auto-ends — the user must manually tap "Stop Set". The user references a prior reported "ROM error when set to AMRAP" with the same phone, Android version, and app version.

Steps to Reproduce

1. Open a Routine workout mode
2. Add exercises (user reports: bicep curl, skull crusher, calf raise, seated cable row, etc.)
3. Edit the routine and set each exercise to AMRAP mode
4. Start the workout and begin the warmup set
5. Perform warmup reps — observe that no sound plays and reps are not counted
6. After 3 warmup reps, the working weight kicks in automatically
7. Continue performing reps and then stop — the set does NOT auto-end after a few seconds of inactivity
8. The user must manually tap "Stop Set" to end the set

Expected Behavior

• Warmup reps should be counted with audio feedback (sound plays on each rep)
• After stopping reps for a few seconds, the set should automatically end (standard auto-end behavior)

Actual Behavior

• Warmup reps are not counted — no sound plays during warmup
• After 3 warmup reps, the working weight activates
• The set never auto-ends even after the user stops performing reps
• The user must manually tap "Stop Set" to end the set

Impact

This bug affects routine workouts with AMRAP configuration across all exercises the user tested. It prevents normal workout flow and forces manual intervention to end sets.

Additional Context

The reporter states they have the same phone, Android version, and app version as a prior reporter of a "ROM error when set to AMRAP" bug. No specific version numbers were provided.

---

Original Discord Report

<@1502654170031849644> I'm having the same issue as the person before who put in the "ROM error when set to AMRAP". I have the same phone, android version, and app version that they did

Recreation steps/details provided in thread after bot follow-up:
1. Routine
2. All, including bicep curl, skull crusher, calf raise, seated cable row, ect.
3. I edited the routine and set it per exercise
4. I just noticed that the warmup reps weren't counting as no sound was playing, but then the weight kicks in after 3 warmup reps, and doesn't stop til I hit "stop set"
5. I expected what normally happens, I stop doing reps for a few seconds and the set to automatically end

[9thLevelSoftware]

RCA Analysis: Warmup reps not counted, set won't auto-end in AMRAP mode

Root Cause Hypothesis

The missing warmup sound and set-not-auto-ending are a single app-side failure chain, not separate bugs:

• Warmup sound is only emitted after a processed warmup rep event (ActiveSessionEngine.kt:5007-5022)
• AMRAP auto-stop remains disabled until isWarmupComplete is true (ActiveSessionEngine.kt:5741-5761)
• If the app receives or accepts no usable rep notification that transitions the warmup, both symptoms follow

The machine can advance resistance (increase weight) after three warmup reps while the app believes warmup is incomplete.

What We Know

1. PR fix: exempt AMRAP leases from rep freshness gate (#700) #701 (merged 2026-08-16) fixed a known AMRAP freshness-gate defect where 0xFF unlimited targets were dropped as TARGET_MISMATCH — but fix: exempt AMRAP leases from rep freshness gate (#700) #701 post-dates the public v0.9.6 release (2026-07-16)
2. Even on v0.9.6-with-fix: exempt AMRAP leases from rep freshness gate (#700) #701, fallback paths (directional counter, working-rep counter) should handle warmup completion, making the exact upstream cause unproven without BLE-level evidence

What We Need From You

To narrow this down, could you please reply with:

1. Exact app version and build number from Settings/About — and whether it was installed from the regular Play Store or a beta/test build? This tells us whether the AMRAP rep-handling fix (PR fix: exempt AMRAP leases from rep freshness gate (#700) #701) was in your installed build.

2. When the machine switches to working weight after the third warmup rep, what does the app show for warmup progress — 0 of 3, 3 of 3/complete, or no warmup count at all? And is there still no sound for any of those three reps?

3. Does this happen every time for a routine exercise set to AMRAP, including after you pause with handles fully returned to the resting position? A short screen recording of one affected set (from start through the pause) would be very helpful to distinguish missing rep registration from an auto-stop gating issue.

[9thLevelSoftware]

Reporter clarification requested - Three follow-up questions posted in the Discord thread for evulnater:

1. Exact app version/build number and installation source (Play Store vs beta)
2. Warmup display (0/3, 3/3, or no count) when working weight engages, and whether sound plays
3. Whether this reproduces every time, including after a full-pause rest

Awaiting reply before proceeding with the full root cause analysis.

[9thLevelSoftware]

Architecture review — changes requested

Ticket 1540545440380882984 / issue #712 is eligible (rca_complete=true, rca_notified=true), but it is not implementation-ready.

What is architecturally sound

The two symptoms are one app-side chain, not separate timer bugs:

• Warmup audio is emitted only after a processed WARMUP_COMPLETED event (ActiveSessionEngine.kt:5007-5022).
• AMRAP auto-stop stays closed until _repCount.isWarmupComplete (ActiveSessionEngine.kt:5741-5751, 6293).
• Routine AMRAP is encoded as unlimited 0xFF (BlePacketFactory.kt:160-170) while the lease working target is 0.
• Current main (c8d60cac1adc) already contains the PR fix: exempt AMRAP leases from rep freshness gate (#700) #701 exemption in RepNotificationFreshnessGate.kt:59-75. That file does not exist on public v0.9.6 (ca94d61b4d99). Compare v0.9.6...57d47d48 is ahead-only.

Reporter clarification now closes the version question: public v0.9.6, warmup UI stays 0/3 with no sound, reproduces every time. That matches a pre-#701 / unreleased-#701 build, not a new firmware-only ROM defect. repsRomCount == 0 alone is not a valid new root cause: RepCounterFromMachine.kt:524-575 already has directional-counter and working-rep fallbacks.

No portal, Supabase schema, or edge-function change is indicated. Scope must stay mobile-only.

Why this is not approved

Canonical ticket state still has:

• rca_fix_direction = null
• rca_acceptance_criteria = null
• rca_owner / rca_model / fix_driver unset

The GitHub comment at #712 (comment) is a pre-clarification hypothesis, not a binding implementation RCA. The formal RCA card skipped as stale and did not post a post-clarification contract. Approving that would send a fixer to invent a new patch against code that is already fixed on main.

Required RCA rewrite before any bugfix PR

Please post an updated RCA comment and persist these fields:

1. Root cause: public v0.9.6 never received PR fix: exempt AMRAP leases from rep freshness gate (#700) #701 (57d47d48). Unlimited AMRAP notifications (repsSetTotal=252) can be rejected before warmup counting, so isWarmupComplete stays false and both sound and auto-stop stay off.
2. Fix direction: do not open a new engine/firmware/auto-stop redesign PR. Ship / promote the next public release that contains 57d47d48. Only reopen a code change if a build that already contains fix: exempt AMRAP leases from rep freshness gate (#700) #701 still reproduces.
3. Non-goals: firmware ROM patches, relaxing the warmup auto-stop gate, portal/Supabase work, re-implementing fix: exempt AMRAP leases from rep freshness gate (#700) #701 on a duplicate branch.
4. Acceptance: reporter on a post-fix: exempt AMRAP leases from rep freshness gate (#700) #701 public/TestFlight build hears warmup cues, warmup UI leaves 0/3, and AMRAP auto-end works after a few seconds of rest without tapping Stop Set.
5. Set rca_owner="gpt-5.6-terra-xhigh", rca_model="gpt-5.6-terra", fix_driver="gpt56_terra_rca", plus non-null rca_fix_direction and rca_acceptance_criteria.

Architecture review status: changes_requested.

[9thLevelSoftware]

Updated RCA — binding implementation contract

This replaces the earlier pre-clarification hypothesis. It is the implementation contract for ticket 1540545440380882984 / issue #712.

Determined cause and release containment

The reporter is on the current public release, v0.9.6 (ca94d61b4d99, published 2026-07-16), where the unlimited-AMRAP freshness-gate fix was not present. PR #701 merged later as 57d47d48bdf353e7f483ad67e5821b41664cd3f5 (2026-08-16) and is contained in current main (c8d60cac1adc). Its RepNotificationFreshnessGate change exempts unlimited AMRAP (lease.isAmrap && workingRepTarget == 0) from TARGET_MISMATCH; that source file is absent from v0.9.6.

That pre-#701 release gap explains the reporter's reproducible chain: the app can reject unlimited-AMRAP notifications before warmup counting, leaving warmup at 0/3. Warmup cues only follow WARMUP_COMPLETED, and AMRAP automatic stop is intentionally gated by warmup completion, so both the missing cue and the requirement to tap Stop Set follow from the same uncompleted warmup state.

This is not a new engine or firmware-ROM root cause. A missing repsRomCount alone is not a valid patch target because existing RepCounterFromMachine directional-counter and working-rep fallbacks already cover it.

Fix direction

Release containment: ship the next public/TestFlight build containing 57d47d48. Do not open a duplicate code PR for #701. Reopen code investigation only if a build demonstrably containing #701 still reproduces the issue.

Acceptance criteria

On a post-#701 public/TestFlight build:

1. Warmup rep cues play.
2. The warmup UI leaves 0/3.
3. An AMRAP set automatically ends after rest without tapping Stop Set.

Explicit non-goals

• Firmware ROM patches.
• Relaxing or redesigning the warmup auto-stop gate.
• Portal or Supabase work.
• Re-implementing fix: exempt AMRAP leases from rep freshness gate (#700) #701 on a new branch.

The next operational action is release verification with a build that contains #701, not a new source-code change.

[9thLevelSoftware]

Correction: post-PR #701 TestFlight builds were shipped

The earlier release-containment update was incorrect because it treated the marketing version (0.9.6) as proof that no newer build had shipped. That is not valid for this project: TestFlight build numbers advance independently while the marketing version can remain 0.9.6.

Verified release evidence:

• App Store Connect shows valid, non-expired TestFlight build 2026081611, uploaded 2026-08-16.
• The corresponding Git tag is testflight/2026081611, explicitly labeled TestFlight build 2026081611, at commit 57d47d48 — PR fix: exempt AMRAP leases from rep freshness gate (#700) #701 itself.
• App Store Connect also shows valid, non-expired builds 2026081712 and 2026081913.
• Their corresponding tags also contain PR fix: exempt AMRAP leases from rep freshness gate (#700) #701.
• The builds retain marketing version 0.9.6; that version string does not mean they predate PR fix: exempt AMRAP leases from rep freshness gate (#700) #701.

Therefore the previous statement that the fix had not shipped to TestFlight users was wrong. The remaining question is not whether a build was cut, but why the affected device still reports the issue on a build that should contain #701: confirm the installed TestFlight build number and investigate whether the installed binary matches the tagged build / whether a separate post-#701 path is involved.

No duplicate code PR should be opened from the current evidence. The issue remains open pending installed-build confirmation and reproduction on a verified post-#701 build.

[9thLevelSoftware]

Confirmed: affected build is post-PR #701

The reporter has identified the installed build as 81913, which maps to TestFlight build 2026081913.

We verified that build is:

• Valid and non-expired in App Store Connect
• Tagged in GitHub as testflight/2026081913
• Built from commit c1202a1ecda608d5877ff3bfc4d60a351606a37a
• A descendant of PR fix: exempt AMRAP leases from rep freshness gate (#700) #701 commit 57d47d48bdf353e7f483ad67e5821b41664cd3f5

This confirms #712 is not explained by the fix simply missing from the tester's build. The previous release-containment conclusion is superseded.

We are reopening this as a post-#701 investigation. The next analysis will trace why the issue remains on this build, including the fallback rep-counter and BLE ingress/drop paths. We will not open a duplicate PR for #701; any new code change must be supported by a distinct, verified cause and a regression test or documented hardware-only evidence.

[9thLevelSoftware]

Phantom validation evidence: standard-set auto-stop path

During Phantom Android emulator validation for the drop-set flow, the app emitted reps, then the simulator injected RELEASE_HANDLES / zero-position metrics. The captured log showed checkAutoStop being called repeatedly while the standard-set run did not complete the expected auto-stop transition.

This is valid evidence for the related stall/drop-set behavior. However, the captured run reported isAMRAP=false, so it is not by itself a faithful reproduction of issue #712's routine-AMRAP warmup 0/3 path. A correctly configured Routine AMRAP Phantom reproduction is being run separately for #712.

No issue closure or fixed conclusion is implied by this evidence.

[9thLevelSoftware]

Post-#701 RCA: build 2026081913 source is confirmed; no new code fix is justified yet

This supersedes the earlier release-containment conclusion. The reporter’s TestFlight alias 81913 maps to build 2026081913, and the release lineage is now independently confirmed:

• annotated tag testflight/2026081913 resolves to c1202a1ecda608d5877ff3bfc4d60a351606a37a;
• git merge-base --is-ancestor 57d47d48bdf353e7f483ad67e5821b41664cd3f5 c1202a1ecda608d5877ff3bfc4d60a351606a37a succeeds, so PR fix: exempt AMRAP leases from rep freshness gate (#700) #701 is included;
• Release All (Existing) run 32198759083 completed on that SHA, including its successful ios-testflight / build-and-upload job, TestFlight upload, test-group addition, and tag step;
• the same SHA’s CI run 32198740515 completed shared unit tests and iOS test-target compilation.

So this is not explained by #701 being absent from the tagged TestFlight source, and there is no source/tag workflow divergence found. A Settings/About screenshot remains useful only to rule out a physical-device stale-install mismatch.

Exact post-fix path

• AMRAP serializes the unlimited 0xFF sentinel (BlePacketFactory.kt:160-170).
• The fix: exempt AMRAP leases from rep freshness gate (#700) #701 gate is present at the build commit: unlimited AMRAP (workingRepTarget == 0) bypasses target mismatch, and AMRAP does not treat repsSetCount as terminal (RepNotificationFreshnessGate.kt:59-95; regression cases at RepNotificationFreshnessGateTest.kt:200-252).
• After an accepted notification, RepCounterFromMachine can complete warmup from: (1) repsRomCount, (2) directional up fallback while both reported counts are zero, or (3) any advancing repsSetCount, which force-completes warmup (RepCounterFromMachine.kt:498-607).
• Warmup events emit the sound (ActiveSessionEngine.kt:464-525). The same isWarmupComplete gate controls AMRAP auto-stop (ActiveSessionEngine.kt:1216-1237, 1700-1820). Therefore 0/3 warmup plus no audio plus no auto-end is one expected chain when the app gets no usable warmup transition.

Correct classification

No separate post-#701 app defect is demonstrated, and this is not firmware-only on current evidence. The missing discriminator is an affected device’s BLE event trace:

1. Connection Log entries for each warmup and first working rep: REP_RECEIVED or WORKOUT_REP_REJECTED, including source, packet size, legacy flag, up/down, repsRomCount/repsRomTotal, repsSetCount/repsSetTotal, timestamp, and rejection reason.
2. repEventsDropped / no-subscriber or buffer-full diagnostics.
3. App warmup state plus handle position/velocity during the rest interval; machine model and firmware version.

That capture can distinguish a freshness-gate drop, a missing/malformed/lost event, and a valid packet that still fails all three counter paths. The recent emulator/Phantom assertion supplies none of that AMRAP packet evidence and cannot justify a separate auto-stop change for #712.

Fix direction

Do not open a duplicate #701 PR. Do not relax the warmup auto-stop gate. If the device trace yields a repeatable source defect, first add an end-to-end DWSMWorkoutLifecycleTest using the captured AMRAP packet sequence: assert warmup completes, warmup audio events occur, and rest-position auto-stop reaches SetSummary; then add the smallest focused counter or freshness-gate regression for the failed predicate.

[9thLevelSoftware]

Correction: Phantom evidence separated from AMRAP RCA

The Phantom run documented in the earlier comment is valid evidence of an auto-stop failure, but its captured log includes isAMRAP=false and came from drop-set validation. It therefore exercises the standard-set stall path, not the routine-AMRAP warmup path in this issue.

What the Phantom evidence does establish:

• Phantom emitted reps and then injected handle release / zero-position metrics.
• checkAutoStop was called repeatedly.
• The standard-set run did not complete its expected auto-stop transition.

That is useful evidence for the related drop-set/stall behavior, but it does not by itself prove that the AMRAP 0/3 warmup transition failed. We are correcting the investigation rather than discarding the evidence: the next reproduction will run Phantom with a Routine AMRAP configuration and capture warmup state, rep events, audio transition, and auto-stop outcome. No issue closure or “fixed” conclusion is warranted yet.

[9thLevelSoftware]

TestFlight evidence cluster for issue #712

The TestFlight monitor found six screenshot-feedback submissions between 2026-08-19 and 2026-08-20 that match the warmup/repetition failure family. They were incorrectly marked seen without being linked to a Phoenix ticket because the monitor's generic duplicate search treated TestFlight/feedback as sufficient duplicate evidence.

Submission	Date	Device / OS	Tester report
AJTYiH4LDJSvkgW5lmKrDM8	2026-08-20 19:41Z	iPhone14_8 / iOS 26.6	Custom supersets: ROM reps did not update, resistance started, reps/timed countdown did not count, sets had to be cancelled, history was incomplete.
AGPiM3JKkaWC2nAeyeoSofY	2026-08-20 10:54Z	iPhone16_2 / iOS 26.6	Warmup and main reps loaded but were not counted, risking heavy load with no easy deload.
AKZhisFUCG2sV3eqZoZF0WM	2026-08-20 10:40Z	iPhone16_2 / iOS 26.6	The workout did not move forward with reps; tester called it dangerous.
ACpaiCCVta4PcgQW26xle34	2026-08-20 01:33Z	iPhone15_2 / iOS 26.6	Warmup counter never registered, weight ramped after three reps, and reps still did not count.
ABz00rmUB3oQdOnRjFl-Qew	2026-08-19 14:36Z	iPhone17_1 / iOS 26.6	Routine Echo first set stayed at warmup 3 reps while weight became live; Just Lift worked.
AIA1xr0Jh-ugMDCulEk0elQ	2026-08-19 00:55Z	iPhone15_2 / iOS 26.6	Calf raises did not count warmup or working reps despite resistance being present.

These are linked TestFlight evidence for existing issue #712, not six new duplicate GitHub issues.

[9thLevelSoftware]

Faithful Android Phantom Routine-AMRAP rerun — BLOCKED

I ran a new single-exercise Routine configured with a three-rep warmup and an AMRAP/unlimited working target. This deliberately excludes the earlier standard-set (isAMRAP=false) stall capture.

What the Android run establishes:

• runtime setup was AMRAP: isAMRAP=true, warmupReps=3, isJustLift=false; activation used the unlimited AMRAP marker;
• the live UI remained at warmup 0/3 while Phantom monitor metrics arrived;
• no rep-notification event was delivered into the captured app path, so there was no accepted/rejected rep record, no working-set transition, and no valid auto-stop observation;
• the run was manually ended, so the zero-rep persistence/teardown is not evidence that AMRAP auto-stop failed.

This is not a reproduction and does not establish a new source or firmware root cause. The Android package was a debug build without TestFlight build-81913 attestation, and the Phantom harness did not emit the required rep-notification sequence.

Next evidence needed: an affected physical-device trace on an attested release build, with sanitized REP_RECEIVED or WORKOUT_REP_REJECTED details for the three warmups and first working rep; alternatively, a clearly labeled synthetic AMRAP rep-notification fixture. The issue remains open pending that evidence.

[9thLevelSoftware]

Harness blocker identified in the AMRAP Phantom rerun

The rerun did configure the Routine AMRAP state correctly (isAMRAP=true, three warmup reps, unlimited marker), but the missing rep event is now explained by a Phantom harness defect—not by a proven app or firmware defect.

In the Android Phantom repository:

• sendWorkoutCommand() decodes and stores the production workout command in workoutParams.
• It logs the decoded AMRAP configuration.
• It does not start startMetrics(activeWorkout = true) or startRepSimulation(...) on that production command path.
• The direct startWorkout(params) method starts those jobs, but the Routine command path uses sendWorkoutCommand().

That is why the rerun received monitor metrics but no production RepNotification, leaving the UI at 0/3. The manual zero-rep teardown was correctly rejected as auto-stop evidence.

A harness-only fix is now queued to make the decoded production command start the deterministic metric and rep-notification simulation, with focused tests for AMRAP warmup progression and the unlimited marker. No production AMRAP change or duplicate PR #701 is authorized until the corrected harness reaches RepCounterFromMachine and the app path is rerun.

[9thLevelSoftware]

Harness fixed; #712 rerun queued

The prior AMRAP Phantom rerun was blocked by a confirmed harness defect: decoded production workout commands did not start the Phantom RepNotification simulation.

That harness issue is now fixed and verified:

• Decoded AMRAP commands start the production-path metric and rep simulation.
• Warmup progression test passes: 1/3 → 2/3 → 3/3, followed by a working transition.
• The AMRAP unlimited sentinel is preserved as repsSetTotal=252.
• Duplicate command jobs and stop-command cancellation are covered.
• Android host Phantom tests and compile checks pass.
• No production AMRAP/auto-stop code was changed.

A dependent Kanban rerun is now queued to exercise issue #712 through the corrected harness. The issue remains open; no product fix is being claimed until that rerun produces valid app-path evidence.