Drop-set option for Old School mode: negative Weight Change Per Rep on failed reps only

[9thLevelSoftware]

Issue #673 — Drop Sets on Failure (user-prompted) Implementation Plan

Authoritative replacement plan. The earlier automatic deload/cross-set proposal, closed PR #682, and branch enhancement/drop-set-old-school-673 are superseded. For Hermes: implement this plan as three sequential PRs (see “Phasing”). PR 1 and PR 2 are prerequisites for PR 3 but ship independent value. This changes set-advancement behavior, so verify normal routine advancement, superset interleaving, and variable warm-up sets remain unchanged.

GitHub issue: #673
Superseded branch: enhancement/drop-set-old-school-673
PR scope: replace the automatic deload-driven drop set with a user-prompted, rest-screen drop set that restarts the failed set.

Goal

When a set ends because the user failed (stall detection fired), offer them a drop set during the rest screen:

1. Prompt: “Retry this set with a drop set?”
2. If yes, offer negative percentage options (e.g. −10% / −20% / −30%).
3. Restart the set that failed at the reduced weight — not the next set, not the next exercise.
4. Remaining sets of that same exercise inherit the reduced weight.
5. Original programming resumes at the next exercise. The saved routine is never modified.

Background: why the previous approach was abandoned

The first implementation (commits cb93489f..4e606cbe) made drop-set mode replace stall detection and reduce weight automatically on DELOAD_OCCURRED. This is not feasible, for a reason now confirmed from three directions:

• The machine will not accept new set parameters mid-set. ActiveSessionEngine.kt:4847-4855 documents that a CONFIG frame sent mid-movement de-energises the cable (“the user perceives as ‘the set deloads’”). The user has independently observed this failing repeatedly in testing. Load can only change at a stop/start boundary.
• The old design wasn’t a drop set anyway. It stashed dropSetNextWeightKg and applied it at the next set boundary — that is auto-regression between sets, not a drop set.
• Firmware progression/regression cannot express it. The increment field is applied per rep, linearly, open-loop from rep 1. It is blind to failure and produces a continuously decaying ramp, whereas a drop set is a fixed lower weight for a block of reps. There is no cadence field in the protocol to change this (see Appendix A).

The new design accepts the stop/start constraint rather than fighting it. Restarting a set is the only way to express a real drop set on this hardware.

Decisions (settled with maintainer)

#	Decision	Resolution
1	Set numbering	Replay — re-enter the same (exerciseIndex, setIndex). Add attemptNumber to CompletedSet.
2	Supersets	Non-issue by construction — coordinates never move, so getNextStep resumes correctly.
3	Echo mode	Excluded — no prompt, no override.
4	Re-failure	Re-prompt, capped at 2 drops per set; dropSetMinWeightKg is a hard floor.
5	% of PR	Store the override as a multiplier, never a resolved kg — composes with all weight sources.
6	Process death	WorkoutServiceSnapshot carries the failure point and override.
7	Remaining-set weight after multiple drops	Final attempted weight (cumulative multiplier), not the first drop level.

Current state verified in repo

Set completion / advancement

• presentation/manager/ActiveSessionEngine.kt
  • handleSetCompletion() (:3975) — takes no reason parameter; there is currently no way to know why a set ended.
  • showBodyweightRepEntry branch (:4026-4035) — existing precedent for pausing completion awaiting user input (clears setCompletionInProgress, returns early).
  • startRestTimer() (:4420+) — captures completedSetIndex (:4426), pre-loads next-set params (:4487-4499). Does not mutate the set/exercise indices.
  • startNextSetOrExercise() (:4821+) — mutates indices at :4866-4867; weight-precedence ladder at :4877-4891.
  • advanceToNextSetInSingleExercise() — parallel ladder at :4741-4764.
  • startWorkoutOrSetReady() (:4784) — respects the autoplay preference; correct entry point for a restart.
• presentation/manager/RoutineFlowManager.kt
  • getNextStep() (:350) — superset interleaving (A1→B1→A2→B2).
  • Index mutation sites during rest: enterSetReady* (:1051-1052, :1141-1142), skip-to-exercise (:1415-1416).
• presentation/manager/WorkoutCoordinator.kt
  • _userAdjustedWeightDuringRest (:294) — the closest existing analogue: an ephemeral, session-scoped weight override.
  • Drop-set scratch state (:433-439) — to be removed.
  • Stall constants (:63-85).

Stall detection

• data/ble/MonitorDataProcessor.kt (:257-272) — parses and logs DELOAD_WARN / SPOTTER_ACTIVE, but only DELOAD_OCCURRED is surfaced.
• data/repository/BleRepository.kt:143 — deloadOccurredEvents: Flow<Unit>; the status word is discarded at this boundary.
• domain/model/SampleStatus.kt — all 8 firmware flags parsed; bit definitions confirmed correct against the official app.
• docs/audits/2026-07-14-stall-detection-e2e-audit.md — F5 (hysteresis dead band) remains open.

To be removed / corrected

• ActiveSessionEngine.kt:456-473 — deload→auto-reduce block.
• RoutineFlowManager.kt:107-114 — progressionForSetReady bypasses the ±3kg clamp for drop-set mode.
• util/BlePacketFactory.kt:257 — zeroes negative progression; the sole guard preventing an out-of-range increment reaching the wire.
• util/BleConstants.kt:96-99 — offsets 0x58/0x5C are misnamed (see Appendix A).

Architecture

1. Set end reason (PR 1)

enum class SetEndReason {
    TARGET_REPS_REACHED, STALL_FAILURE, CABLE_RELEASED,
    USER_STOPPED, VBT_AUTO_END, TIMER_EXPIRED,
}

Thread through handleSetCompletion(reason: SetEndReason), park on the coordinator for the rest screen, and persist on CompletedSet. Valuable for analytics independent of drop sets (“which sets did I fail”).

2. Failure point snapshot (PR 3)

Captured at handleSetCompletion time — not read live during rest, because skip/navigation paths can move the indices.

data class SetFailurePoint(
    val exerciseIndex: Int,
    val setIndex: Int,
    val routineExerciseId: String,      // assert on re-entry; index alone is fragile
    val originalWeightPerCableKg: Float,
    val attemptNumber: Int,
    val warmupSetIndex: Int,            // >= 0 means warm-up set — do not prompt
)

3. Exercise load override (PR 3)

data class ExerciseLoadOverride(
    val exerciseIndex: Int,
    val multiplier: Float,   // cumulative across drops, e.g. 0.8 then 0.64
    val dropCount: Int,      // cap at 2
)

Held on WorkoutCoordinator. Multiplier, never resolved kg — composes with flat weights, per-set weights, and %-of-PR resolution alike.

Requires no eager clearing: it is only consulted when resolving weight for exerciseIndex, so a superset partner never matches it. Clear on routine end / workout reset only.

Refactor first: four near-duplicate weight-precedence ladders exist (startRestTimer :4487, startNextSetOrExercise :4877, advanceToNextSetInSingleExercise :4741, enterSetReadyWithAdjustments). Extract a single resolveNextSetWeight() before adding a fourth precedence tier — audit finding F7 documents how divergent hand-maintained copies of the same logic have already caused bugs here.

4. Restart is a re-entry, not an advance (PR 3)

The critical architectural point. The retry must not route through getNextStep:

restartSetWithDrop(percent):
    restore indices from SetFailurePoint (assert routineExerciseId matches)
    override = ExerciseLoadOverride(exerciseIndex, cumulativeMultiplier, dropCount + 1)
    weight   = originalWeightPerCableKg * cumulativeMultiplier, floored at dropSetMinWeightKg
    repCounter.resetCountsOnly(); resetAutoStopState()
    startWorkoutOrSetReady()          // respects autoplay

Because the coordinates never move, when the retried set completes, getNextStep(exIdx, setIdx) resumes exactly as if the failure had not happened — A1 fails → retry A1 → completes → getNextStep returns B1. Superset interleaving never learns a retry occurred.

progressionRegressionKg is untouched by this feature. A restarted set applies whatever increment the exercise has configured, ramping from the lower base.

5. Prompt (PR 3)

Shown during WorkoutState.Resting so the failed set still saves and the rest timer still runs. Gated on:
reason == STALL_FAILURE && exercise.dropSetEnabled && programMode is OldSchool && !isEchoMode && warmupSetIndex < 0 && dropCount < 2 && weight > dropSetMinWeightKg

Autoplay must be suspended while the prompt is open, or the rest timer will advance out from under the user mid-decision.

6. Schema (PR 3)

• Add attemptNumber to CompletedSet (default 1). Without it, replay produces two indistinguishable rows at the same (exerciseIndex, setIndex) and set-count math reads 4 for a 3-set exercise.
• Keep and repurpose the already-shipped dropSetEnabled / dropSetMinWeightKg columns (migration 43, SchemaManifest, sync repo, backup, DTOs): dropSetEnabled becomes “offer the drop-set prompt on failure”, dropSetMinWeightKg stays the floor. This preserves the migration and portal parity work.
• WorkoutServiceSnapshot (DefaultWorkoutSessionManager.kt:564) carries SetFailurePoint + ExerciseLoadOverride. Silently losing the override mid-exercise would resume remaining sets at full weight — a surprise heavy set, the worst failure mode.

7. Stall detection rework (PR 2)

The prompt is only as good as the failure signal, and the current detector is unreliable. Two changes:

a. Widen the event to carry the status word. deloadOccurredEvents: Flow<Unit> → Flow<SampleStatus> (or a MachineStatusEvent). The flags are already parsed; only the plumbing discards them.

b. Add the geometric ROM-fraction signal. The official app derived rep position from cable position as a fraction of calibrated ROM, not velocity (Appendix A). Phoenix uses velocity thresholds with position only as a crude > 10mm gate. A user grinding to failure is stuck at a characteristic fraction of their ROM — structurally different from a completed rep at the top or racked handles at the bottom. This addresses audit F5 (the 2.5–10 mm/s dead band where a countdown can neither arm nor cancel) at the root: position answers where they are stuck when velocity cannot answer whether they are stuck.

DELOAD_WARN may be useful as a leading indicator but has no reference implementation (Appendix A) — treat any use of it as novel and validate on hardware before relying on it.

8. Cleanup (PR 1)

• Rename OFFSET_TARGET_WEIGHT → OFFSET_SOFT_MAX, OFFSET_PROGRESSION → OFFSET_INCREMENT (BleConstants.kt:96-99), matching the official field names. “Progression” invited the per-rep/per-set ambiguity that produced the overloaded field.
• Enforce the firmware validation bounds Phoenix currently ignores: softMax <= 100.0f and increment <= 10.0f. The drop-set path currently bypasses the ±3kg clamp (RoutineFlowManager.kt:107-114), so a −20kg config produces an increment of −20 — double the firmware bound, applied per rep. Only BlePacketFactory.kt:257 stops it reaching the wire.
• Delete the deload→auto-reduce block (ActiveSessionEngine.kt:456-473), dropSetNextWeightKg and its consumption ladders, the coordinator scratch state, and the progressionRegressionKg overload.

Phasing

PR	Scope	Independent value
1	SetEndReason plumbing + protocol cleanup + remove old drop-set logic	Set-end reasons in history; closes the increment overrun
2	Status-word flow + geometric ROM-fraction stall detection	Fixes “sets randomly ending”; closes audit F5
3	Prompt + SetFailurePoint + ExerciseLoadOverride + attemptNumber	The feature

Testing

• Restart lands on the same (exerciseIndex, setIndex); getNextStep afterwards returns the same step it would have without the retry.
• Superset A1 fails → retry A1 → next step is B1; B’s weights unmodified.
• Override applies to remaining sets of the overridden exercise and to no other exercise.
• Cumulative multiplier after two drops; third prompt suppressed; floor respected.
• Echo exercises never prompt.
• Warm-up set failure never prompts.
• %-of-PR exercise: override composes multiplicatively.
• Autoplay ON: rest timer does not advance while the prompt is open.
• Process death during rest with a pending prompt, and mid-exercise with an active override.
• Regression: normal advancement, variable warm-up sets, single-exercise mode, bodyweight rep entry.

Non-goals

• Mid-set weight changes. Confirmed impossible; do not attempt a 0x4F force-only frame mid-set.
• Firmware-native drop sets via negative increment. It is a per-rep open-loop ramp, not a drop set.
• Changing progression/regression semantics or the saved routine.

---

Appendix A — Protocol findings from the deobfuscated official app

Source: 9thLevelSoftware/deob, cloned at ../deob (sibling of this repo).

A1. The official app parses but never acts on the deload flags. In Yj/p$j.smali — the only consumer of the flag enum in the entire APK — all eight flags are read but only REP_TOP_READY, REP_BOTTOM_READY and ROM_OUTSIDE_LOW reach the return value. ROM_OUTSIDE_HIGH, ROM_UNLOAD_ACTIVE, SPOTTER_ACTIVE, DELOAD_WARN and DELOAD_OCCURRED are invoked with no move-result — their values are discarded at bytecode level, so this is neither a decompiler artifact nor dead-code elimination.

Implication: Phoenix’s use of DELOAD_OCCURRED to drive auto-stop is an invention, not a port. There is no reference implementation for failure detection to validate against — consistent with it being hit-or-miss.

A2. Rep position was derived geometrically. The official app compares max(left.position, right.position) against rangeTop − pct·(rangeTop − rangeBottom) and rangeBottom + pct·(...), with per-exercise configurable fractions. Position, not velocity.

A3. Full activation packet layout (Ek/N.java, Ek/C1505b.java, Ek/O.java, Ek/M.java, Ek/L.java):

ActivationPacket (0x04):
  RepConfig(
    repCounts: RepCounts(total: byte, baseline: byte = 3, adaptive: byte = 3, pad = 0),
    seedRange: float,
    top:    RepBandConfig(threshold = 5.0, drift = 0.0, inner: RepBand, outer: RepBand),
    bottom: RepBandConfig(threshold = 5.0, drift = 0.0, inner: RepBand, outer: RepBand),
    safety: RepBand(mmPerM: short, mmMax: short))
  ActivationForceConfig(
    concentric: Ramp, eccentric: Ramp,
    forces: ClosedRange<Float>,
    softMax:   float,   // validated <= 100.0  ("Soft max is too high!")
    increment: float)   // validated <= 10.0   ("Increment is too high!")

Serialization order of the trailing block is forces.min, forces.max, softMax, increment, which maps onto Phoenix’s offsets as:

Offset	Phoenix name	Official name
0x50	forceMin	forces.min ✅
0x54	forceMax	forces.max ✅
0x58	targetWeight	softMax
0x5C	progression	increment

A4. No cadence field exists. The only load-stepping parameter in the whole protocol is the single increment float; RegularPacket (0x4F) likewise carries one progression float. The per-rep firing rate is firmware-internal and not exposed. A fixed lower weight for a block of reps therefore requires a stop/restart with increment = 0.

A5. RepCounts(total, baseline = 3, adaptive = 3) — the 3 firmware calibration reps are a protocol-level constant, retroactively justifying Constants.DEFAULT_WARMUP_REPS = 3 (kept deliberately per Issue #411).

Caveat: BLE_PROTOCOL_DEEP_DIVE.md in that repo is partly AI-generated narrative. Its “When Sent” claims (e.g. that RegularPacket adjusts resistance mid-exercise) are unverified and contradicted by field observation. Only the decompiled sources and smali cited above are treated as evidence here.

[9thLevelSoftware]

Feasibility Assessment: Drop-Set Option for Old School Mode

Recommendation: Accept ✅

Summary

Add a drop-set option for Old School mode where a negative Weight Change Per Rep is only activated when the user fails to complete a rep (rather than on every rep).

Technical Approach

• App-side failure detection using existing DELOAD_OCCURRED signals from the machine (already proven in stall detection).
• Conditional weight adjustment: on failed rep, app reduces weight by the configured progressionRegressionKg value, deferred to safe BLE boundaries.
• No firmware change required for initial implementation.
• New dropSetEnabled boolean on RoutineExercise model + DB schema migration.
• UI toggle in ExerciseEditBottomSheet near the existing progression slider.

Effort

• 2–3 weeks (model + DB, UI toggle, ActiveSessionEngine drop-set logic, testing edge cases).

Key Risks

1. BLE timing — mid-set weight changes need per-rep boundary deferral (existing code defers to set boundary).
2. Rep failure detection accuracy — DELOAD_OCCURRED fires on cable release, may need refinement.
3. Multiple consecutive failures — needs a floor weight or max-drop limit.

Open Questions

1. Should drop-set apply to Just Lift mode as well, or routines only?
2. Should there be a minimum weight floor to prevent dropping to zero?
3. Should multiple consecutive failed reps each trigger a separate drop, or a max drops per set?

[9thLevelSoftware]

Architecture Design: Drop-Set Option for Old School Mode

Stage: Architecture ✅

Approach

Path C (Hybrid) — app-side failure detection using existing DELOAD_OCCURRED signals, no firmware change required.

System Shape

1. Data Model: New dropSetEnabled: Boolean and dropSetMinWeightKg: Float fields on RoutineExercise and WorkoutParameters. DB migration 43 (additive ALTER TABLE).

2. BLE Protocol: When drop-set is enabled and progressionRegressionKg < 0, the BLE activation packet sends progressionRegressionKg = 0 (machine does no per-rep adjustment). The app controls weight changes.

3. Failure Detection: The existing deloadOccurredEvents collector in ActiveSessionEngine (collector Audit BLE protocol parity after Kable migration #5) is extended: when dropSetEnabled is true, DELOAD_OCCURRED triggers a weight reduction by abs(progressRegressionKg) instead of arming the stall timer. The new weight is clamped to dropSetMinWeightKg.

4. Weight Application: Weight change is deferred to the next safe BLE boundary (rep boundary or set boundary). Critical implementation risk: mid-set BLE weight updates may fault the machine (existing code defers to set boundary). Implementation must investigate whether a weight-only BLE command exists or fall back to cross-set drops.

5. UI: New "Drop-Set Mode" toggle in ExerciseEditBottomSheet, visible when OldSchool mode + negative Weight Change Per Rep. Optional minimum weight floor field.

Key Decisions

• ADR-001: App-side detection (Path C) over firmware-native (Path A) — no firmware timeline dependency.
• ADR-002: Zero progressionRegressionKg in BLE packet — prevents double adjustment.
• ADR-003: Drop-set disables deload-armed stall timer; velocity-based stall detection remains active.
• ADR-004: Old School mode only for v1; extensible to other modes later.
• ADR-005: Reuse existing progressionKg slider as drop amount — no new field needed.

Compatibility

• Existing routines unaffected (defaults: dropSetEnabled=false, dropSetMinWeightKg=0).
• Backup files forward-compatible (new fields have defaults).
• No portal sync change for v1 (local-only field, same as stallDetectionEnabled).

Risks

Risk	Severity	Mitigation
Mid-set BLE weight update faults machine	Critical	Investigate weight-only BLE command; fall back to set-boundary drops
DELOAD_OCCURRED on deliberate rack vs failed rep	Medium	Acceptable proxy for v1; floor weight prevents runaway drops
Multiple consecutive failures drop too fast	Medium	dropSetMinWeightKg floor; max-drops-per-set in v2

Non-Goals

• Just Lift / Echo / TUT / Pump mode support (v1)
• Firmware-native drop-set (future Path A)
• Within-set drop-set if BLE fault risk can't be mitigated (cross-set fallback)
• Portal UI or sync

Open Questions (non-blocking, defaults chosen)

1. Should drop-set apply to Just Lift mode? → Default: No (v1).
2. Default minimum weight floor? → Default: 0 (user-configurable).
3. Max drops per set? → Default: No limit (floor acts as natural limit).

Full architecture document: architecture.md in the enhancement artifact directory.

Next stage: Integration modelling (mapping changes into existing code paths, state stores, and tests).

[9thLevelSoftware]

This needs to be thoroughly researched, as there are a few potential blockers I can see:

1. This directly conflicts with stall detection logic, so may need to toggle between one option or the other with inability to use both.
2. Per existing hardware requirement, machine does not accept weight changes or adjustments mid-set, as those details are sent in intiation ble packet. Sending additional packets midstream causes machine faults.
3. If we tracked similarly to defined Warm-Up Reps, would require existing set to end (via stall logic), a secondary set to be created with reduced weight, and for user to perform 3 ROM reps to begin new dropset sets.

[9thLevelSoftware]

Integration Model: Drop-Set Option for Old School Mode

Stage: Integration Model ✅

Owner Feedback Integration

All three blockers from the owner comment have been analyzed and integrated:

1. Stall detection conflict — Drop-set and stall detection are mutually exclusive per exercise. When dropSetEnabled=true, the deload collector routes to the drop-set weight-reduction branch instead of arming the stall timer. The UI disables the stall detection toggle when drop-set is on. Velocity-based stall detection (5s < 2.5mm/s) remains active.

2. No mid-set BLE weight changes — Confirmed. The machine cannot accept weight adjustments mid-set. Weight changes are deferred to the next set boundary via the existing pendingWeightChangeKg mechanism. This makes the feature a cross-set drop-set: the weight drop applies to the next set after a failed rep, not the current set. The HUD shows the reduced weight immediately, but the machine changes weight at the next BLE activation packet.

3. Warm-up-style set restart — Documented as a v2 enhancement (Path C-Restart). For v1, the simpler cross-set approach (Path C-Simple) is recommended: it uses the proven pendingWeightChangeKg mechanism with no new lifecycle complexity.

Verified Source Code Mapping

All architecture claims verified against live source (15 source files + 4 test files):

• Domain model: RoutineExercise (line 92) + WorkoutParameters (line 353) — add dropSetEnabled + dropSetMinWeightKg
• DB schema: VitruvianDatabase.sq CREATE TABLE (line 252) + 2 insert queries (lines 1244-1267) — add 2 columns + 2 placeholders each. Migration 43 (new file).
• Repository: SqlDelightWorkoutRepository.kt insert (line 753) + row mapper (line 405). SqlDelightSyncRepository.kt sync mapper (line 1045) + sync insert (line 2284, defaults to 0/0.0 for portal pull).
• Backup: BackupModels.kt (line 166) + DataBackupManager.kt mapping (line 2637). Old backups deserialize with defaults.
• BLE: BlePacketFactory.kt (line 254-258) — conditional zeroing when dropSetEnabled && progressionRegressionKg < 0.
• Runtime: RoutineFlowManager.kt — 4 WorkoutParameters constructions (lines 849, 1106, 1181, 1426) need the 2 new fields.
• Active session: ActiveSessionEngine.kt deload collector (line 428) — gate extended, drop-set branch added before stall-timer arming. WorkoutCoordinator.kt (line 432) — drop-set state vars.
• UI: ExerciseEditBottomSheet.kt (after line 577) — drop-set toggle + min weight field. ExerciseConfigViewModel.kt — state flows, load, save, handlers.

Test Plan

4 test files: BLE packet zeroing test, WorkoutParameters field test, backup serialization compat test, and a new DropSetDeloadHandlerTest for deload routing (weight reduction vs stall timer).

Full integration model document: integration-model.md in the enhancement artifact directory.

Next stage: UI prototype (if UI is required) or human signoff.

[9thLevelSoftware]

In-App Prototype — Drop-Set Mode

The proposed Old School drop-set control rendered in the real Phoenix iOS app running in the Phantom simulator.

Screen: Just Lift / Old School
Mock data: Weight Change Per Rep −5 kg; drop amount 5 kg on failure; floor 15 kg.
Behavior shown: Drop-Set Mode enabled; weight decreases only after a failed rep, with the floor displayed.
Note: Visual mockup only; the final implementation will wire these controls to the routine editor, persisted model, and safe cross-set weight application.

[9thLevelSoftware]

Implementation Spec Complete

The signed-off drop-set feature for Old School mode has been decomposed into 8 bounded implementation packets:

1. Data Model + DB Migration — dropSetEnabled and dropSetMinWeightKg fields on RoutineExercise / WorkoutParameters, migration 43, backup models
2. Repository + Sync — SqlDelight read/write mappings, portal sync defaults (disabled)
3. BLE Packet Factory — Zero progressionRegressionKg when drop-set enabled + negative
4. RoutineFlowManager — Copy drop-set fields to WorkoutParameters at all 4 construction sites
5. ActiveSessionEngine + Coordinator — Deload collector routing (drop-set branch before stall timer), handleDropSetDeload() function, coordinator state vars
6. ViewModel + UI — Drop-set toggle, min weight field, stall detection mutual exclusivity in ExerciseEditBottomSheet
7. Tests — BLE zeroing, backup serialization, deload handler routing (drop-set vs stall), floor enforcement
8. String Resources — UI label strings

Key design decisions (v1, per signoff):

• Cross-set drops only — weight reduction deferred to next set via pendingWeightChangeKg (no mid-set BLE commands)
• Mutual exclusivity — drop-set suppresses deload-based stall at runtime (Approach A); velocity-based stall remains active
• Old School mode only — Echo/Just Lift excluded
• No firmware change — app-side DELOAD_OCCURRED detection, BLE progression zeroed

Non-goals:

Just Lift, Echo, firmware-native drop-set, within-set BLE weight changes, warm-up-style set restart, portal sync, drop-set history/charts, max drops per set

Artifacts: implementation-spec.md and user-instructions.md available in the enhancement artifact directory.

[9thLevelSoftware]

🔄 Enhancement flow restarted — previous proposal superseded

The automatic DELOAD_OCCURRED / cross-set auto-regression approach is abandoned. Closed PR #682 and branch enhancement/drop-set-old-school-673 are historical only and must not be reused as the implementation base.

The issue body now contains the authoritative replacement plan. The key contract is:

• failure is identified by the stall detector and offered as a user prompt during rest;
• accepting a drop replays the failed (exerciseIndex, setIndex) at a reduced multiplier;
• no mid-set CONFIG/0x4F load changes and no negative-increment firmware workaround;
• Echo and warm-up sets do not prompt; at most two cumulative drops per set; floor enforced;
• process-death state, superset interleaving, variable warm-ups, autoplay suspension, and normal advancement are explicit regression requirements;
• implementation is three sequential PRs: (1) set-end reason/protocol cleanup, (2) status-word + geometric ROM-fraction stall detection, (3) prompt/re-entry/override/attempt history.

The Phoenix enhancement pipeline has been reset from feasibility with fresh revision task identities. Earlier feasibility/architecture/integration/prototype/signoff/spec/implementation comments remain visible only as historical context; where they conflict with the issue body, the issue body wins.

[9thLevelSoftware]

Replacement-Plan Feasibility Assessment

This is the feasibility assessment for the revised user-prompted rest-screen retry architecture (authoritative-plan-v2). The earlier automatic deload/cross-set proposal (PR #682) is superseded.

Recommendation: ACCEPT

Key findings

• Hardware constraint confirmed. Load can only change at a stop/start boundary — CONFIG mid-movement de-energises the cable. Restarting the set is the only viable drop-set mechanism.
• Architecture is sound. The re-entry pattern (same exerciseIndex/setIndex, no advance through getNextStep) preserves superset interleaving and is proven by the existing precedent.
• Multiplier, not resolved kg. ExerciseLoadOverride as a cumulative multiplier composes with all weight sources (flat, per-set, %-of-PR).
• Stall detection rework is independently valuable. Widening from Flow to Flow plus geometric ROM-fraction signal addresses the F5 velocity dead band at the root.
• All 10 required validations pass. No mid-set load changes, no negative-increment firmware hack, failed coordinates replayed, supersets/warmups/autoplay/process-death all handled.

Effort: 5–8 days across 3 sequential PRs

PR	Scope	Independent value
1	SetEndReason plumbing + protocol cleanup	Set-end reasons in history; closes increment overrun
2	Status-word flow + geometric stall detection	Fixes unreliable set endings; closes audit F5
3	Prompt + failure point + load override + attemptNumber	The feature

No blocking risks identified.

Full assessment:

[9thLevelSoftware]

Integration Model Complete — Replacement Plan v2

Verified all architecture claims against main@885a2ef. Integration model artifact written to integration-model.md.

Key findings:

• 20 files to modify across 3 PRs (PR1: 10 files, PR2: 8 files, PR3: 20 files including 2 new model files and 2 new test files)
• All schema changes are additive — migration 43 (PR1: set_end_reason) and migration 44 (PR3: dropSetEnabled, dropSetMinWeightKg, attemptNumber) use ALTER TABLE ... ADD COLUMN ... NOT NULL DEFAULT
• 1 discrepancy found: Architecture listed 4 WorkoutParameters construction sites in RoutineFlowManager but only 1 exists there (:836). The remaining sites are in ActiveSessionEngine.kt (:1721, :2443, :2739, :1822/:1833). Implementation spec must account for all 5+ sites.
• No cross-module or portal dependencies for v1 — portal sync carries new fields with defaults
• Weight-precedence ladder refactor confirmed: 4 near-duplicate ladders in ActiveSessionEngine.kt (startRestTimer:4365, startNextSetOrExercise:4737, advanceToNextSetInSingleExercise:4645, enterSetReadyWithAdjustments)
• Process-death persistence needs a new overlay on WorkoutSession (JSON column recommended) since WorkoutServiceSnapshot is transient UI, not persisted

Integration seams:

• All changes within shared module — no cross-module dependencies
• Sync: push DTO (PortalSyncAdapter.kt:583) and pull DTO (PortalSyncDtos.kt:868) need dropSetEnabled/dropSetMinWeightKg fields with defaults
• Backup: RoutineExerciseBackup and CompletedSetBackup need new fields with defaults for old backup compatibility
• 11 handleSetCompletion() call sites confirmed for SetEndReason threading

Open items for implementation spec:

1. Confirm migration numbering (43 for PR1, 44 for PR3)
2. Process-death overlay: JSON column on WorkoutSession vs separate table
3. ROM-fraction calibration timing during warm-up reps
4. Prompt UI implementation approach (inline vs dialog)

Pipeline stage: integration_model_done. Ready for prototype/UI design gate.

[9thLevelSoftware]

In-App Prototype — User-Prompted Failed-Set Replay (v2)\n\nRendered in the real Phoenix iOS app running in the Phantom simulator with the just-lift-connected fixture.\n\n\n\nScreen: Just Lift / Old School setup with the rest-screen failure replay state shown in-context\nVisible behavior: STALL_FAILURE during rest; −10%/−20%/−30% cumulative drop choices; reduced next attempt (48 kg from 60 kg at −20%); 15 kg floor; Retry set / Skip; autoplay pauses until a choice is made; two-drop cap.\nMock data: Back squat, 60 kg, 6 reps.\nNote: Visual mockup only. Final implementation will wire this to SetFailurePoint, ExerciseLoadOverride, attemptNumber, and persisted session state across the three sequential PRs.\n

[9thLevelSoftware]

Prototype asset correction\n\nThe in-app v2 prototype asset is available here:\n\n\n\nThe earlier prototype comment remains historical context from the superseded automatic/cross-set proposal; this screenshot reflects the authoritative replacement plan v2.

[9thLevelSoftware]

🪧 Enhancement Review Request — Signoff Gate

The replacement plan (v2) has completed all pre-signoff pipeline stages:

Feasibility: ACCEPT — user-prompted rest-screen retry architecture is sound within hardware constraints. 3 sequential PRs, 5–8 days estimated, no blocking risks.

Architecture: 3 sequential PRs with 6 ADRs:

1. PR 1 — Set-end reasons and protocol cleanup (1–2 days): Thread SetEndReason through handleSetCompletion, persist on CompletedSet, add firmware validation bounds. ~10 files.
2. PR 2 — Status-word flow and geometric stall detection (2–3 days): Widen Flow<Unit> → Flow<SampleStatus>, add ROM-fraction stall signal. ~8 files.
3. PR 3 — User-prompted failed-set replay (2–3 days): Rest-screen prompt with −10/−20/−30% choices, cumulative multiplier, hard floor, Retry/Skip, autoplay suspension, two-drop cap. ~20 files, new migration 43.

Integration model: All architecture claims verified against main@885a2ef. 20 files total across 3 PRs. All schema changes additive. No cross-module or portal dependencies for v1.

Prototype: In-app Phantom mockup captured at 1206×2622:

---

To approve: Reply with "approved", "looks good", "go ahead", or react with 👍 / +1 / thumbs-up on this comment.

To request changes: Reply with what needs to change.

Full artifacts: Feasibility · Architecture · Authoritative Plan v2