128 lines
6.3 KiB
Markdown
128 lines
6.3 KiB
Markdown
# 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
|