Echo VBT state accumulates across progressive sets and stops later sets unexpectedly (related to #649)

[9thLevelSoftware]

Summary

New recurrence of premature VBT-related set termination during progressively harder sets. The report is related to resolved issue 649, but the sequence is different: failure appears to accumulate across sets as difficulty increases and may indicate stale or cumulative VBT state or numeric overflow.

Reporter context

• Discord reporter/context: Devil
• Source thread: 1526367469340459039
• Environment/version: not provided in this follow-up

Relationship to resolved issue 649

Issue 649 (Echo Hardest AMRAP: VBT verbal encouragement cut off, set ends prematurely on 3rd of 3) was resolved by merged PR 650. Its RCA identified an AMRAP auto-stop interaction that could end a set after a VBT verbal cue even when Auto-End on Velocity Loss was disabled.

This report should be investigated as a new regression or related failure rather than assumed to be the same path: the observed behavior progresses across consecutive sets and may involve cumulative VBT values or overflow. Preserve issue 649 as prior-fix context and compare the new code path against PR 650.

Reported sequence

1. First set: difficulty set to Hard; all 10 reps completed and VBT did not trigger.
2. Second set: difficulty set to Harder; the set stopped at rep 6.
3. Third set: difficulty set to Hardest; VBT failed after approximately rep 3.
4. The user does not have the setting enabled to stop sets when VBT thresholds are reached.

Expected behavior

• Each set should evaluate VBT using the current set's valid measurements and configured behavior.
• Increasing difficulty across sets should not cause earlier sets to contaminate later VBT calculations or cause an unconfigured VBT threshold to stop a set.
• A VBT measurement failure should fail safely without prematurely ending the workout set.

Actual behavior

• Later sets stop progressively earlier as difficulty increases.
• The third set reports VBT failure after approximately three reps.
• The user reports no configuration to stop sets when VBT thresholds are reached.

Investigation hypothesis (not established root cause)

The recurrence and consistency pattern (third set, approximately third rep) suggests cumulative VBT values, stale per-set state, or a numeric overflow or invalid-value path. Confirm or reject this by tracing per-set reset, accumulation, threshold, and failure handling. Do not treat the hypothesis as proof.

Acceptance direction for RCA

• Identify whether VBT state, counters, samples, thresholds, or failure flags survive across set boundaries.
• Verify numeric ranges and invalid or overflow handling for the progressive Hard to Harder to Hardest sequence.
• Compare the affected path with the 649/650 fix and prove whether the prior guard is bypassed or incomplete.
• Define a targeted regression test that runs multiple consecutive sets with increasing difficulty and verifies no premature stop when VBT auto-end is disabled.

Original Discord report

Something similar happened today, on my first set it was set to hard, did all 10 without VBT kicking in. set 2 set to harder, it made it to 6 reps and stopped the set, then 3rd set on hardest and it VBT failed after like 3 reps? I do not have it configured to stop sets when hitting VBT thresholds.

[9thLevelSoftware]

RCA research found that the disabled Auto-End on Velocity Loss setting gates the two-rep VBT auto-end branch, while separate stall and position auto-stop paths can still request set completion. Before binding the fix, reporter clarification was requested on the exact Echo/exercise sequence, whether the UI showed normal set completion versus a VBT or connection error, and whether Stall Detection was enabled. This distinguishes the stop path and fixes regression-test acceptance criteria.

[9thLevelSoftware]

RCA: enabled Stall Detection — not accumulated VBT state — ended the fixed-rep Echo sets

Evidence used

• Original report: fixed target of 10 reps, manually changed Echo difficulty Hard -> Harder -> Hardest, later sets ended at roughly reps 6 and 3, and VBT Auto-End was disabled.
• Reporter clarification: the level changes were manual; there was no VBT/connection error; Stall Detection was enabled. The configured duration text in the reply is malformed, but the product setting is a fixed five seconds.
• Recreation packet: marked REPRODUCED at code-path level on main@0f00f4b; physical Pixel/trainer replay was unavailable. The packet proves the stall path exists, not that the user's disabled VBT setting should suppress it.
• Prior context: Echo Hardest AMRAP: VBT verbal encouragement cut off, set ends prematurely on 3rd of 3 #649 / PR fix: defer AMRAP/stall auto-stop after verbal VBT cue when autoEndOnVelocityLoss=false (#649) #650 addressed an AMRAP/verbal-cue race. This report has no VBT error or confirmed verbal-cue overlap.

Root cause

No cumulative VBT state or numeric-overflow defect is present in the traced path:

1. Per-set Echo selection is propagated independently. RoutineFlowManager.updateSetReadyEchoLevel() updates only the active echoLevel; ActiveSessionEngine.startWorkout() validates and sends the current target rep count and Echo level in the 0x4E command (RoutineFlowManager.kt:1234-1239, ActiveSessionEngine.kt:2505-2514, 2776-2802). Changing Hard to Harder/Hardest does not rewrite the 10-rep target.
2. Set completion resets the VBT baseline and one-shot state: BiomechanicsEngine.reset() clears firstRepMcv, rep results, and the latest result; ActiveSessionEngine.handleSetCompletion() clears that engine plus velocityThresholdAlertEmitted, consecutiveThresholdReps, the verbal-cue defer deadline, and rep boundaries. startWorkout() also resets both auto-stop timers/flags (BiomechanicsEngine.kt:183-192, ActiveSessionEngine.kt:964-974, 2491-2514, 4030-4035). Later sets cannot inherit the prior set's velocity-loss baseline or stop counters.
3. The VBT threshold branch honors the disabled setting. checkVelocityThreshold() can call handleSetCompletion() only after two threshold reps and autoEndOnVelocityLoss == true (ActiveSessionEngine.kt:1325-1383). With the reporter's setting off, this branch cannot end the set.
4. A fixed-rep Echo set is not AMRAP/Just Lift/timed cable, so the separate 2.5-second position auto-stop is excluded by shouldRunPositionBasedAutoStop() (ActiveSessionEngine.kt:993-1009, 1513-1551).
5. The enabled per-exercise Stall Detection setting is the remaining configured completion path. After warm-up and a working rep, near-zero cable velocity while the handles remain in use starts the five-second timer; a trainer DELOAD_OCCURRED event can start the same timer. Expiry calls requestAutoStop() -> triggerAutoStop() -> handleSetCompletion() (ActiveSessionEngine.kt:400-435, 1012-1055, 1472-1511). Harder/Hardest Echo levels make a failed or paused rep more likely earlier, matching the reported 10 -> 6 -> 3 progression.

This is the documented Stall Detection safety behavior: the exercise editor says “Auto-stop set when movement pauses for 5 seconds.” Issue #256 specifically required an enabled stall detector to end a failed heavy lift. autoEndOnVelocityLoss controls threshold-based VBT completion; it does not disable the separately enabled failed-lift safety stop.

Binding fix direction

No production-code change or PR is justified for #652 from the available evidence. The reporter configured the path that ended the sets. To prevent this behavior for the exercise, disable its Stall Detection toggle.

Do not add the recreation packet's proposed !autoEndOnVelocityLoss guard to checkAutoStop(). That would silently override the explicit per-exercise Stall Detection setting and regress the failed-lift protection restored by #256. PR #650's verbal-cue defer should also remain scoped to a cue in flight; broadening it does not address this no-cue report.

Close/resolve this report as configured behavior. Reopen only if it reproduces with stallDetectionEnabled=false, or if device logs show a completion source other than the five-second stall path. Such a recurrence must capture the sent Echo target/level and the surrounding rep events, DELOAD_OCCURRED, stall countdown, and triggerAutoStop() logs before changing policy.

Acceptance criteria / regression target

• No engine change and no bugfix PR for Echo VBT state accumulates across progressive sets and stops later sets unexpectedly (related to #649) #652 on the current evidence.
• With stallDetectionEnabled=true, a standard fixed-rep set after a completed working rep still reaches SetSummary after a valid five-second active-position stall (existing DWSMWorkoutLifecycleTest contract for [Bug]: auto-stop no longer working #256).
• With autoEndOnVelocityLoss=false, threshold reps alone still do not auto-end (VbtAutoEndTest).
• VBT state reset still establishes a fresh first-rep baseline for the next set (VbtThresholdTest).
• PR fix: defer AMRAP/stall auto-stop after verbal VBT cue when autoEndOnVelocityLoss=false (#649) #650's verbal-cue defer remains bounded and per-set (VerbalEncouragementAutoStopDeferTest).
• If a future report reproduces with Stall Detection off, first add one failing DWSMWorkoutLifecycleTest that drives the exact logged completion source; do not speculate from rep counts.

Fresh verification on main@0f00f4b: focused Android-host runs passed 129/129 tests (63 lifecycle, 9 VBT auto-end, 8 verbal-defer, 38 VBT engine, 11 VBT threshold), with 0 failures/errors/skips. Working tree remained clean.

Non-goals

• Do not couple or merge the VBT Auto-End and Stall Detection settings.
• Do not remove failed-lift auto-stop protection.
• Do not change Echo difficulty, target-rep encoding, audio, or BLE behavior without device evidence.

RCA owner: se-engineer / gpt-5.6-sol (openai-codex, xhigh).

[9thLevelSoftware]

Additional info from Discord thread:

<@1502654170031849644> Disagree, further evaluation is necessary. Considering confirmation of stall detection being enabled, focus new RCA on stall detection logic to identify failure points, as stall detection logic has not been refined since cable position logic has been enhanced.

— added by ticket bot

[9thLevelSoftware]

RCA re-opened: stall detection requires deeper evaluation

Maintainer direction supersedes the prior no-code disposition pending a focused re-audit. Confirmation that Stall Detection was enabled proves which path is eligible; it does not prove that the path still behaves correctly after subsequent cable-position logic enhancements.

New RCA scope: trace every cable-position/velocity/rep/de-load signal into stall timer arm/reset and set completion; compare stall assumptions against git history for later cable-position changes; test false-positive pauses/turnarounds, harder Echo states, DELOAD_OCCURRED, timer cancellation, set transitions, and PR #650 interaction; then produce a failure-point matrix and focused test evidence.

No production fix is authorized until that re-audit establishes the shared root cause. Tracking task: t_cbdf10b9 under GPT-5.6 Sol xhigh.

[9thLevelSoftware]

RCA re-audit: confirmed stale stall countdown survives a completed working rep

This supersedes the prior “configured Stall Detection; no code change” disposition. Enabling Stall Detection makes the path eligible, but the current path can remain armed after the athlete has demonstrably resumed movement.

Binding disposition

Confirmed stall-detection defect. A velocity- or DELOAD_OCCURRED-armed stall countdown is reset by a metric above 10 mm/s, but not by a completed working-rep notification. The same completed-rep boundary already clears PR #650’s verbal-cue defer because it “proves the user is back in motion.” Consequently, a countdown started at a turnaround, brief pause, or firmware de-load can survive a subsequent valid rep and later call requestAutoStop() → triggerAutoStop() → handleSetCompletion().

Current source audited at origin/main@0f00f4b28856bfc3dd6536340390ec01b2c3ea03.

Code and history evidence

• Both stall sources share WorkoutCoordinator.stallStartTime:
  • firmware DELOAD_OCCURRED: ActiveSessionEngine.kt:400-435;
  • near-zero absolute cable velocity: ActiveSessionEngine.kt:1472-1511.
• Velocity cancellation occurs only when maxVelocity > STALL_VELOCITY_HIGH (10 mm/s) at ActiveSessionEngine.kt:1485-1487. The 2.5–10 mm/s hysteresis band deliberately preserves the current timer.
• Rep completion is authoritative at ActiveSessionEngine.kt:1096-1113, but it clears only deferAutoStopDeadlineMs; it does not call resetStallTimer().
• PR fix: defer AMRAP/stall auto-stop after verbal VBT cue when autoEndOnVelocityLoss=false (#649) #650’s own contract and mirror test explicitly say a completed working rep proves resumed motion (VerbalEncouragementAutoStopDeferTest.kt:35-39, 88-106). Production applies that invariant only to the cue defer, not to the stall timer.
• git log -S/-G and blame show the stale assumptions:
  • the five-second/two-threshold stall detector predates the later cable model;
  • position precision/danger-zone and rep-phase logic evolved through c11ee33a, 6415549a, and 1edd782a;
  • metric velocity switched to authoritative, EMA-smoothed firmware velocity in 6694b2a9 (MonitorDataProcessor.kt:164-217);
  • later stall changes (834adddf, 5f52b559, 9c46c4e6, 90e68051, bdad56d5) refined eligibility, ROM/warm-up, and pending-rep behavior but never added a completed-rep reset;
  • PR fix: defer AMRAP/stall auto-stop after verbal VBT cue when autoEndOnVelocityLoss=false (#649) #650 (0f00f4b) added only verbal-cue deferral.

Failing regression evidence

A single test-only characterization was added on a disposable local branch (51bcaab8), with no production edit:

Issue 652 - completed Echo rep cancels an armed stall timer

Scenario: fixed-rep Echo HARDER, Stall Detection on, first working rep complete, DELOAD_OCCURRED arms the timer, then the second working rep completes. Expected: timer cleared and workout remains Active. Actual on main:

64 tests completed, 1 failed
A completed working rep proves motion resumed and must cancel the stale stall countdown
expected:<null> but was:<1783989200633>

The required existing suite still passes 80/80 (63 lifecycle + 9 VBT auto-end + 8 verbal-defer). That green suite proves intended five-second completion and isolated mirror state machines; it had no case asserting that a real completed rep cancels an already armed production stall timer.

Failure-point matrix

Signal / state	Stale assumption	Observed consequence	Location / evidence	Confidence
Near-zero velocity at turnaround / between reps	A later sample will exceed 10 mm/s and cancel the timer	Timer can remain armed across a valid completed rep	ActiveSessionEngine.kt:1474-1495; RED test	High
Resumed motion in 2.5–10 mm/s hysteresis band	Mid-band motion should preserve prior state	Slow Harder/Hardest motion does not cancel an existing countdown	WorkoutCoordinator.kt:61-69; ActiveSessionEngine.kt:1485-1487	High (code), medium (report attribution)
DELOAD_OCCURRED	Firmware de-load remains a valid stall until a high-velocity metric arrives	Completed rep does not invalidate the firmware-armed timer	ActiveSessionEngine.kt:400-435; RED test	High
Valid pause / isometric hold with no completed rep	Five seconds without movement is a stall	Enabled setting intentionally stops after five seconds; not this defect	ActiveSessionEngine.kt:1489-1507	High
Hard → Harder → Hardest manual changes	Absolute thresholds are mode-independent and sufficient	Higher resistance can increase low/mid-band windows, explaining earlier exposure without cross-set accumulation	RoutineFlowManager.kt:1234-1239; shared thresholds	Medium
Warm-up / first working rep	Warm-up gate plus pending-rep protection separates setup from a failed lift	Current gate is correct; #256 pending first-rep protection must remain	ActiveSessionEngine.kt:988-1026; existing #256 tests	High
Timer cancellation after resumed movement	>10 mm/s is the only authoritative recovery signal	A completed rep can coexist with stale stallStartTime / isCurrentlyStalled	ActiveSessionEngine.kt:1096-1113; RED test	High
Per-set reset and manual Echo-level changes	Possible cumulative VBT/stall state	startWorkout() / completion reset state; manual level only updates echoLevel; no cross-set accumulation found	ActiveSessionEngine.kt:964-974, 2505-2514, 4030-4035; RoutineFlowManager.kt:1234-1239	High
PR #650 verbal-cue defer	Completed rep recovery was implemented for all auto-stop state	It clears only the defer deadline, leaving the shared stall countdown untouched	ActiveSessionEngine.kt:1096-1103, 1451-1466; mirror test lines 35-39	High
Position-based auto-stop	Fixed-rep Echo might use the 2.5-second position path	shouldRunPositionBasedAutoStop() excludes fixed-rep Echo; not the #652 path	ActiveSessionEngine.kt:993-1009, 1513-1516	High

Minimal shared fix direction

In ActiveSessionEngine.handleRepNotification(), inside if (repCountAfter > repCountBefore) (ActiveSessionEngine.kt:1096-1113), call resetStallTimer() alongside the existing deferAutoStopDeadlineMs = 0L.

That is the narrow shared fix because both low-velocity and DELOAD_OCCURRED arms use the same timer. It does not couple Stall Detection to VBT Auto-End, change thresholds, disable the user’s setting, or weaken issue #256: a failed pending rep has not completed, so its timer remains armed.

Acceptance criteria

1. The RED Echo/DELOAD characterization passes: a completed working rep clears stallStartTime, clears isCurrentlyStalled, and leaves the workout Active.
2. Issue [Bug]: auto-stop no longer working #256 remains intact: a pending first working rep can still arm and expire the five-second timer.
3. A real stall after the most recent completed rep still calls set completion after five seconds.
4. Warm-up gating, per-set reset, and PR fix: defer AMRAP/stall auto-stop after verbal VBT cue when autoEndOnVelocityLoss=false (#649) #650 verbal-cue defer tests remain green.
5. autoEndOnVelocityLoss remains independent; no new VBT/stall coupling.
6. Run the full Android-host suite before PR handoff.

No production code or PR was created by this RCA task.

RCA owner: se-engineer / gpt-5.6-sol (openai-codex, xhigh).

[9thLevelSoftware]

Implemented the binding GPT-5.6 RCA fix as PR #653 (Fixes #652).

Production change (one line, in ActiveSessionEngine.handleRepNotification):

if (repCountAfter > repCountBefore) {
    deferAutoStopDeadlineMs = 0L
    resetStallTimer()   // <-- Issue #652: same boundary already proves resumed motion
    ...
}

Both stall arms (low-velocity at ActiveSessionEngine.kt:1472-1511 and firmware DELOAD_OCCURRED at ActiveSessionEngine.kt:400-435) write to the shared coordinator.stallStartTime, so a single shared reset at the completed-rep boundary clears both.

TDD evidence:

• RED characterization (Issue 652 - completed Echo rep cancels an armed stall timer) reproduced on main@0f00f4b: expected:<null> but was:<1783989200633>.
• GREEN after the fix.
• Focused suite (DWSM + VbtAutoEnd + VerbalEncouragementAutoStopDefer): 81 tests, 0 failures.
• Full :shared:testAndroidHostTest: 2442 tests, 0 failures, 0 errors, 0 skipped.
• Issue [Bug]: auto-stop no longer working #256 pending-first-rep stall tests (deload starts stall timer even with pending rep, velocity stall auto-stops with pending rep after timer expires) remain GREEN.

Untouched: Stall Detection thresholds (2.5/10 mm/s), per-set reset, warm-up gating, AMRAP position auto-stop, VBT Auto-End, autoEndOnVelocityLoss semantics, and any file outside ActiveSessionEngine.kt + DWSMWorkoutLifecycleTest.kt. Stall Detection remains independent from VBT Auto-End - no coupling introduced.

PR: #653
Awaiting CI + review. No auto-merge per project policy.