SneakySwole/docs/roadmap.md

SneakySwole Roadmap

V2 Improvements

Each improvement is implemented as a separate branch/PR. Implementation order matters — auth removal goes first since other features depend on the simplified profile flow.

---

1. Easier Profile Selection ✅ Complete

Branch: feature/remove-auth (merged in 758034b)

Strip all authentication entirely — this is a homelab app, no need for login. When the app opens, the landing page (/) shows a profile picker with cards for each user. Selecting a profile sets an active_profile_id cookie that persists across sessions (per-device, until the user switches profiles or clears cookies).

What gets removed:

• Admin login flow (login page, bcrypt password verification, session tokens)
• is_admin and password_hash fields from the users table
• auth_service.py, auth.py routes, login.html template
• bcrypt and itsdangerous dependencies
• Auth dependency (get_current_admin_user) from all route handlers

What gets added/changed:

• / becomes the profile picker page (cards with name, height, weight, and "Select" button)
• require_active_profile() dependency replaces auth — just checks for the cookie
• NoProfileSelectedError handler redirects to / if no profile is set
• NavContextMiddleware simplified to only read the active_profile_id cookie
• Nav bar always shows profile switcher dropdown (no admin gating)

Edge cases:

• No profiles exist → show "Create Profile" link
• Cookie references a deleted profile → middleware returns None, redirect to picker
• Existing DB with admin row → migration deletes it

---

2. Schedule Adjustment — "Workout Now" Flow ✅ Complete

Branch: feature/workout-now (committed in 4b117c6) | Depends on: #1 merged

Replace the /workouts page (static list of all 4 days) with a smart "Workout Now" page that auto-recommends the next workout in the Push → Pull → Lower → Full Body cycle based on the user's last completed session.

How it works:

1. User selects profile → navigates to /workouts
2. App queries the most recent workout_session for that profile
3. Determines next day in cycle (e.g., last did Push → recommend Pull). No history defaults to Push.
4. Page shows all 4 workout types as cards, with the recommended one visually highlighted (<mark>Recommended Next</mark>, primary button vs outline for others)
5. User clicks "Start Workout" on any card → goes to that workout's exercise page
6. Once on a workout, a "Change Workout" button is visible to switch types (soft lock — not hard-locked, but the UI keeps you focused on the chosen workout)

Card-based approach (no JS): The recommendation is shown via highlighted cards rather than a dropdown/select. This follows the project's HTMX-first principle — no JavaScript needed.

Display context: Show "Last workout: Pull on Mar 10" message on the page so the user understands the recommendation.

Edge cases:

• Same-day multiple workout types → creates separate sessions (existing behavior, correct)
• No profile selected → show "pick a profile first" message with link to /

---

3. Automatic Scaled Workout Reps / Sets / Weights — 6→12 Rep Ladder

Branch: feature/rep-ladder-progression | Depends on: #1 merged

Replace the current wk1/wk4 target system with a fixed, universal rep ladder progression. Every exercise follows the same pattern:

Progression model:

• Rep ladder: 6 → 8 → 10 → 12 reps at current weight
• Weight increase: At 12 reps with all sets marked "felt easy" → +5 lbs, reset to 6 reps
• Hold: If not all sets felt easy at current reps → stay at current reps/weight
• Climb: If all sets felt easy but below 12 reps → move to next step in ladder
• Deload: After 4+ consecutive sessions struggling (none felt easy) → reduce weight by 20%, reset to 6 reps
• Always 3 sets per exercise

Schema change: Simplify user_exercise_programs table — keep only starting_weight per user/exercise (migrated from existing wk1_weight data). Drop wk1_reps, wk4_reps, wk4_weight columns. The existing 40 rows of programming data (20 exercises × 2 users) are preserved as starting weights.

Starting weight behavior:

• Exercise with no log history → suggest starting_weight at 6 reps, 3 sets
• Exercise with log history → progression engine picks up from last logged values

UI change: Replace the Week 1/Week 4 target display on exercise cards with a rep ladder progress bar showing the 4 steps (6, 8, 10, 12) with the current position filled in.

Bodyweight exercises (weight = "BW"): Weight increase is skipped. User climbs the rep ladder and holds at 12 reps.

Data continuity: The 55 existing workout log entries are unchanged and feed directly into the new progression engine. The progression_service.py gets a full rewrite of get_suggestion() with the new ladder logic.

---

4. Export Workout History as CSV

Branch: feature/csv-export | Depends on: #1 merged

Add a CSV export section to the dashboard page with a date range picker (default: last 30 days) and a "Download CSV" button.

CSV format — one row per set:

Column	Description
date	Workout session date (ISO format)
workout_type	Push / Pull / Lower / Full Body
exercise	Exercise name
set_number	Set number within that exercise
reps	Reps completed
weight	Weight used
felt_easy	Yes / No

Implementation:

• GET /dashboard/export?start_date=YYYY-MM-DD&end_date=YYYY-MM-DD returns a CSV file download
• Uses standard HTML form GET (not HTMX — HTMX can't trigger file downloads)
• StreamingResponse with Content-Disposition: attachment header
• Filename: sneakyswole_{profile_name}_{start}_to_{end}.csv
• Date range defaults: start = 30 days ago, end = today. Invalid dates fall back to defaults.

Edge cases:

• No data in range → CSV with headers only (valid empty CSV)
• No profile selected → redirect to dashboard
• Large date ranges are fine — even a year of heavy use is ~3,000 rows

---

Implementation Order

1. Remove Auth ✅ ──┬──> 2. Workout Now ✅
                    ├──> 3. Rep Ladder Progression  (can be parallel with 4)
                    └──> 4. CSV Export              (can be parallel with 3)

---

Future Ideas

• Exercise video/image attachments
• Custom workout program builder