feat: filter exercise pickers to previously completed exercises

[9thLevelSoftware]

Enhancement request

Reporter: stugotz0955_50891 (Discord)
Type: Enhancement
Target repository: 9thlevelsoftware/project-phoenix-mp

Summary

Add a filter that shows only exercises the user has previously completed, so people can find familiar exercises without scrolling through the entire exercise library.

Requested behavior / app locations

Provide an additional filter for previously completed exercises in all of these mobile exercise-selection paths:

1. Single Exercise — while exploring/searching exercises.
2. Routines — while creating a new routine and adding exercises.
3. Profile → Exercise Insights — while searching exercises.

When enabled, the filter should restrict the displayed exercise list to exercises the user has completed before.

Expected behavior

A user can opt into a “previously completed” exercise filter in each listed exercise picker/search flow and quickly locate exercises in their own workout history.

Current behavior / impact

The current exercise library requires the reporter to scroll through the full catalog to locate an exercise they have performed before.

Notes

The enhancement pipeline should define the completion-history source and empty-state behavior during feasibility/architecture work, then keep filtering behavior consistent across the three listed mobile surfaces.

Attachments

No attachments were provided with this Discord request.

Original Discord Request

<@1502654170031849644> Feature request for an additional filter to only show exercises previously completed when exploring exercises when in "Single Exercise", in "Routines" when creating a new routine and adding exercises, in the "Profile" tab and searching exercises in the "Exercise Insights".  This should help from scrolling through the entire exercise library looking for an exercise you've done before.

[9thLevelSoftware]

Feasibility: accept

This is a feasible, mobile-only enhancement with medium effort (about 3–5 engineering days including coverage and emulator checks). The existing shared picker already powers the Routine and Profile paths, while Single Exercise renders the same picker content.

Recommended behavior: add an opt-in Previously completed chip, off by default, that composes with search and the existing filters. Its source must be active-profile workout history: completed, non-deleted sessions with recorded reps. This avoids cross-profile leakage and avoids relying on the catalog timesPerformed field.

No portal or new backend endpoint is required for the proposed scope. Next: architecture should define the smallest shared picker/history contract, exact empty state, and focused test plan.

[9thLevelSoftware]

Architecture: Previously completed exercise filter

The accepted design keeps this mobile-only and local: a new off-by-default Previously completed chip will join the shared picker shelf used by Single Exercise, Routine add-exercise, and Profile → Exercise Insights.

The filter is one shared predicate over the active profile’s history-visible sessions: only non-deleted rows with workingReps > 0 or totalReps > 0 and a non-blank exercise ID qualify. It does not use favorites, routines, PRs, or global catalog counters, so it cannot leak another profile’s history.

No portal work, backend endpoint, schema migration, or saved preference is needed. The implementation must keep the chip composable with search and current filters, preserve existing selection flows, test profile-switch/zero-rep/deleted-row cases, and provide emulator evidence for all three named locations. The next stage is integration modelling, followed by the required visual prototype/signoff gate.

Full design artifact: ~/.hermes/phoenix-enhancements/issue-665-1527694753049874593/architecture.md

[9thLevelSoftware]

Prototype review — Previously completed exercise filter

Visual prototype for the approved Issue #665 scope is ready for review.

Live HTML prototype: https://gist.githubusercontent.com/9thLevelSoftware/9cfb8cde38d097b442ec197d25fc0c47/raw/6d8345c5d3a2f68f66995cb9296749c24afa27a3/index.html
Gist source + review notes: https://gist.github.com/9thLevelSoftware/9cfb8cde38d097b442ec197d25fc0c47

The mockup uses the current Phoenix picker visual language and shows:

1. Single Exercise — selected Previously completed chip with the narrowed history-derived list.
2. Routine → Add exercise — the same selected chip inside the existing rounded picker sheet; selecting an item continues to the existing configuration sheet.
3. Profile → Exercise Insights — selected chip and recoverable empty state; custom exercise creation remains unavailable.

The chip is off by default, appears after Favorites and Custom in the shared shelf, composes with the existing filters, and Clear restores the normal library. It adds no new setting, row badge, or sort order.

PNG review evidence is retained in the ticket artifact directory for pipeline verification:

• prototype/single-exercise-filter-selected.png
• prototype/routine-add-exercise-filter-selected.png
• prototype/profile-insights-filter-empty.png

Signoff: a 👍 / +1 / thumbs-up reaction on this comment or the Discord prototype message counts as acceptance. Reply with requested changes to route the ticket back to the prototype stage. Implementation must not start until acceptance is recorded.

[9thLevelSoftware]

Implementation plan ready

The reporter-approved scope is now specified as four sequential delivery packets:

1. Derive a profile-tagged completed-exercise ID set only from history-visible, positive-rep, non-deleted session history; cover profile switching so stale IDs cannot flash.
2. Add one default-off, localized Previously completed chip and a shared pure picker predicate that composes with search, Favorites, Custom, muscle, and equipment filters.
3. Wire only Single Exercise, Routine Add exercise, and Profile Exercise Insights while preserving the existing routine configuration/superset and profile custom-exercise restrictions.
4. Prove the contract with host/SQL/view-model tests plus final Android-emulator visual evidence for all three flows, empty recovery, and profile switching.

No backend, API, schema, migration, portal, persisted preference, or unrequested-picker work is authorized. PR hardening requires GitHub-readable final visual evidence in addition to the automated test/quality gates.