# Hardening Audit Report — Werkout API (Django/Python)

## Audit Sources
- 5 mapper agents (100% file coverage)
- 8 specialized domain auditors (parallel)
- 1 cross-cutting deep audit (parallel)
- Total source files: 75

---

## CRITICAL — Will crash or lose data (18 findings)

**1. werkout_api/settings.py:16** | DEBUG=True hardcoded, never disabled in production
- What: `DEBUG = True` set at module level. Production branch (when `DATABASE_URL` set) never overrides to `False` — the code is commented out (lines 142-157). `CORS_ALLOW_ALL_ORIGINS` on line 226 depends on DEBUG, so it's always `True`.
- Impact: Full stack traces, SQL queries, internal paths exposed to end users. CORS allows any origin with credentials.
- Source: Security, Config, Cross-cutting

**2. werkout_api/settings.py:160** | SECRET_KEY falls back to 'secret'
- What: `SECRET_KEY = os.environ.get("SECRET_KEY", 'secret')`. Neither `docker-compose.yml` nor any env file sets SECRET_KEY.
- Impact: Session cookies, CSRF tokens, password hashes use a publicly known key. Complete auth bypass.
- Source: Security, Config

**3. werkout_api/settings.py:226** | CORS allows all origins with credentials in production
- What: `CORS_ALLOW_ALL_ORIGINS = True if DEBUG else False` is always `True` (DEBUG never False). Combined with `CORS_ALLOW_CREDENTIALS = True` (line 231).
- Impact: Any website can make authenticated cross-origin requests and steal data.
- Source: Security, Config

**4. registered_user/serializers.py:31** | Password hash exposed in API responses
- What: `write_only_fields = ('password',)` is NOT a valid DRF Meta option. Correct: `extra_kwargs = {'password': {'write_only': True}}`. Password field is readable.
- Impact: Hashed password returned in registration responses. Enables offline brute-force.
- Source: Security, API, Cross-cutting

**5. registered_user/views.py:83-90** | update_registered_user uses request.POST — JSON requests wipe user data
- What: `request.POST.get(...)` only works for form-encoded data. JSON requests return `None` for all fields. Lines 88-90 set `first_name=None`, `email=None`, etc. and save.
- Impact: Any JSON profile update silently corrupts user data. Email set to None breaks login.
- Source: Security, Logic, Cross-cutting

**6. registered_user/views.py:108-114** | Password update broken for JSON clients, can lock out user
- What: `request.POST.get("new_password")` returns `None` for JSON. `set_password(None)` makes password uncheckable, permanently locking user out.
- Impact: Password endpoint non-functional for JSON clients. Potential permanent account lockout.
- Source: Security, Cross-cutting

**7. registered_user/serializers.py:46** | Registration creates RegisteredUser with non-existent phone_number field
- What: `RegisteredUser.objects.create(phone_number=self.context.get("phone_number"), ...)` — model has no `phone_number` field (removed in migration 0002).
- Impact: User registration crashes with TypeError if phone_number is passed in context.
- Source: Cross-cutting, Logic

**8. scripts/views.py:43-45** | Anonymous cache wipe endpoint — no authentication
- What: `clear_redis` view has no auth decorators. Active in `scripts/urls.py`. Any anonymous request wipes entire Redis cache.
- Impact: Denial of service — any internet user can flush all cached data at will.
- Source: Security

**9. video/views.py:50-59** | Path traversal vulnerability in hls_videos
- What: `video_name` and `video_type` from GET params concatenated directly into file paths without sanitization. `../../etc/passwd` sequences can access arbitrary files.
- Impact: Arbitrary file read on the server. Route commented out in urls.py but view exists.
- Source: Security

**10. video/views.py:74** | Celery task called with zero arguments but requires filename
- What: `create_hls_tasks.delay()` called with no args. Task signature `create_hls_tasks(filename)` requires one.
- Impact: Every call to `/videos/create_hls/` crashes the Celery worker with TypeError.
- Source: Celery, Cross-cutting

**11. supervisord.conf:13** | Production runs Django dev server (runserver) instead of WSGI
- What: `python manage.py runserver 0.0.0.0:8000` in production. `uwsgi.ini` exists but is unused.
- Impact: Single-threaded, no request timeouts, not designed for production. Memory leaks.
- Source: Config

**12. supervisord.conf** | No Celery worker process configured
- What: Only `django` and `nextjs` programs defined. No `[program:celery]` entry.
- Impact: All `.delay()` calls queue tasks in Redis that are never consumed. Entire async task system non-functional.
- Source: Celery, Config

**13. supervisord.conf:13** | Auto-migrate on every container start
- What: `python manage.py migrate` in startup command runs migrations automatically without review.
- Impact: Destructive migrations run silently. Race conditions if multiple containers start simultaneously.
- Source: Config

**14. docker-compose.yml:8-10,26** | Database credentials hardcoded as postgres/postgres
- What: `POSTGRES_USER=postgres`, `POSTGRES_PASSWORD=postgres` in compose file and DATABASE_URL. No `.env` override.
- Impact: Trivial unauthorized access if database port exposed. Credentials in git history permanently.
- Source: Security, Config

**15. AI/workouts.py + AI/cho/workouts.py** | 86K lines of PII data committed to git
- What: Two files totaling 86,000+ lines of user workout data from Future Fitness API with user IDs, S3 URLs, timestamps.
- Impact: PII permanently in git history. Potential GDPR/privacy liability.
- Source: Security, Config

**16. generator/views.py:1032-1160** | save_plan has no transaction wrapping
- What: Creates GeneratedWeeklyPlan, then loops creating Workout, Superset, SupersetExercise, GeneratedWorkout, PlannedWorkout objects. No `transaction.atomic()`.
- Impact: Mid-loop failure (e.g., date parsing) leaves orphaned plan records. Partially saved plans with missing days.
- Source: Data Integrity, Cross-cutting

**17. generator/views.py:789-803** | confirm_plan has no transaction wrapping
- What: Loops through generated workouts, saves status, deletes/creates PlannedWorkouts individually.
- Impact: Partial plan confirmation — some days accepted, others not, on any mid-loop error.
- Source: Data Integrity

**18. registered_user/serializers.py:34-51** | User + RegisteredUser creation has no transaction
- What: `User.objects.create()`, `set_password()`, `RegisteredUser.objects.create()`, `Token.objects.create()` — four DB ops with no `transaction.atomic()`.
- Impact: Orphaned User records if RegisteredUser creation fails. Ghost users block re-registration.
- Source: Data Integrity, Cross-cutting

---

## BUG — Incorrect behavior (28 findings)

**1. registered_user/views.py:30,47** | Validation errors return HTTP 500 instead of 400
- Impact: Clients can't distinguish server errors from bad input.

**2. registered_user/views.py:74** | Failed login returns 404 instead of 401
- Impact: Wrong HTTP semantics for auth failures.

**3. registered_user/models.py:20** | `__str__` concatenates nullable last_name — TypeError
- Impact: Admin, logging crash for users with null last_name.

**4. registered_user/admin.py:11** | Token.objects.get crashes if no token exists
- Impact: Admin list page crashes if any user lacks a Token.

**5. equipment/models.py:13** | `__str__` concatenates nullable category/name — TypeError
- Impact: Admin crashes for Equipment with null fields.

**6. muscle/models.py:11** | `__str__` returns None when name is null
- Impact: Violates `__str__` contract. Admin/template crashes.

**7. workout/views.py:45** | Workout.objects.get with no DoesNotExist handling
- Impact: Missing workouts return 500 instead of 404.

**8. workout/views.py:60,143,165** | Validation errors return HTTP 500 instead of 400
- Impact: Three views misreport client errors as server errors.

**9. workout/views.py:69** | GET endpoint returns 201 Created instead of 200
- Impact: Incorrect HTTP semantics for read operation.

**10. workout/views.py:76** | Unreachable None check — .get() raises exception, never returns None
- Impact: Dead code; actual DoesNotExist is unhandled (500 error).

**11. workout/views.py:124** | estimated_rep_duration None multiplication crashes
- What: `exercise["reps"] * exercise_obj.estimated_rep_duration` where field can be null. `int * None` = TypeError.
- Impact: Workout creation crashes mid-loop, orphaning partial records (no transaction).

**12. workout/serializers.py:37** | KeyError if 'notes' not in validated_data
- Impact: Completing a workout without notes crashes with 500.

**13. workout/serializers.py:40** | Wrong attribute name — health_kit UUID never persisted
- What: Sets `completed_workout.workout_uuid` but model field is `health_kit_workout_uuid`.
- Impact: HealthKit UUIDs silently discarded forever.

**14. workout/tasks.py:85** | estimated_rep_duration None multiplication in Celery task
- Impact: Bulk import crashes mid-way, leaving partial data.

**15. workout/tasks.py:73** | Exercise.objects.get with no DoesNotExist handling
- Impact: One missing exercise aborts entire import.

**16. workout/urls.py:14** | Duplicate URL name 'plan workout' on two paths
- Impact: `reverse('plan workout')` resolves to wrong URL.

**17. scripts/views.py:37** | NameError: MuscleGroup is not defined
- What: Catches `MuscleGroup.DoesNotExist` but only `Muscle` is imported.
- Impact: NameError crashes endpoint instead of catching intended exception.

**18. scripts/views.py:15** | equipment_required.split() crashes on None
- Impact: sync_equipment crashes for any exercise with null equipment_required.

**19. video/models.py:24** | save() missing *args in signature
- Impact: Callers passing positional args (force_insert) get TypeError.

**20. video/models.py:24-27** | HLS transcoding triggered on EVERY save, not just file changes
- Impact: Redundant expensive ffmpeg jobs on metadata-only edits.

**21. video/serializers.py:13** | video_file can be None — AttributeError
- Impact: Video listing crashes if any Video has no file.

**22. video/tasks.py:10** | Existence check uses wrong filename pattern — never matches
- Impact: Guard clause never short-circuits; re-encodes every time.

**23. generator/views.py:70** | RegisteredUser.objects.get repeated ~17 times with no DoesNotExist handling
- Impact: Any user without RegisteredUser gets unhandled 500 on every generator endpoint.

**24. superset/helpers.py:16** | Exercise.objects.get("First Up") with no error handling
- Impact: Workout detail crashes if "First Up" exercise is missing.

**25. superset/serializers.py:20** | get_unique_id returns random UUID per serialization
- Impact: Frontend can't use unique_id as stable key. Breaks diffing/caching.

**26. workout/models.py:51** | settings not imported — NameError on duration_audio()/weight_audio()
- What: Relies on `from exercise.models import *` transitive import of settings.
- Impact: NameError if transitive chain breaks.

**27. workout_generator.py:909** | None multiplication when duration is None
- Impact: Plan generation crashes if preferences have no duration set.

**28. workout_generator.py:802** | sum(c.difficulty) crashes if any difficulty is None
- Impact: Plan generation crashes for users with incomplete completion records.

---

## SILENT FAILURE — Error swallowed or ignored (5 findings)

**1. generator/views.py:193,491,874,989,1156** | Broad except Exception catches all errors, leaks str(e)
- Impact: Bugs masked. Internal details leaked to clients.

**2. superset/helpers.py:19-23** | In-memory mutations on Exercise ORM object never saved
- Impact: Changes silently lost. Risk of corrupting shared Exercise if accidentally saved.

**3. workout/helpers.py:41** | ser_data.mutable = True is a no-op
- Impact: No effect. Indicates confusion about data type.

**4. audit_exercise_data.py:168-170** | except Exception: pass silently swallows all errors
- Impact: Database errors during field checks silently ignored.

**5. workout/views.py:32** | Infinite cache with incomplete invalidation
- Impact: Generated workouts never appear in all_workouts until manual cache clear.

---

## RACE CONDITION — Concurrency issue (1 finding)

**1. registered_user/views.py:34** | Email uniqueness check is a race condition
- What: `User.objects.filter(email=email)` check followed by `serializer.save()`. No DB unique constraint visible.
- Impact: Concurrent registrations can create duplicate email accounts.

---

## LOGIC ERROR — Code doesn't match intent (12 findings)

**1. rules_engine.py:650** | Push/pull ratio check skipped when either count is zero
- What: Condition requires both counts > 0. A workout with 2 push, 0 pull passes silently.
- Impact: Unbalanced push-heavy workouts pass validation.

**2. rules_engine.py:858-860** | Workout type match is a no-op for non-strength types
- What: Non-strength branch unconditionally counts every exercise as matching (100% always).
- Impact: HIIT/cardio/core workouts can contain arbitrary exercises without violations.

**3. workout_generator.py:1459** | Workout type affinity matching NEVER works
- What: `SPLIT_TYPE_WORKOUT_AFFINITY` uses underscore names like `'traditional_strength_training'` but comparison uses `wt.name.strip().lower()` which yields space-separated names.
- Impact: All workout type assignments fall through to round-robin fallback. Push splits get assigned random types.

**4. workout_generator.py:2070** | Modality check counts exercise capability, not actual assignment
- What: Checks `ex.is_duration` (capability flag) not whether the entry was actually given duration.
- Impact: False modality calculations for dual-modality exercises.

**5. workout_generator.py:1404** | Diversify type count wrong on replacement
- What: Doesn't subtract from the removed type count when replacing, only adds to candidate count.
- Impact: Valid replacements rejected. Invalid ones accepted in edge cases.

**6. workout_generator.py:2898** | Final conformance treats all warnings as blocking
- What: `_is_blocking_final_violation` returns True for `severity in {'error', 'warning'}`.
- Impact: Workouts crash with ValueError for minor advisory issues (cooldown missing, duration bias slightly off).

**7. workout_generator.py:1209** | Recursive retry destroys cross-day dedup state
- What: Failed attempt's exercises already recorded in week state via `accumulate_week_state`. Retry with different exercises creates ghost entries.
- Impact: Later days in the week have artificially smaller exercise pools.

**8. entry_rules.py:19** | Volume floor can violate workout type rep ranges
- What: With `min_volume=12` and `rounds=1`, forces 12 reps. Strength (3-6 rep range) gets 12 reps.
- Impact: Strength workouts get inflated reps contradicting their character.

**9. rules_engine.py:441** | Push/pull counting double-counts dual-pattern exercises
- What: Exercise with `'upper push, upper pull'` counted in BOTH push AND pull totals.
- Impact: Inaccurate push:pull ratio calculations.

**10. exercise_selector.py:631** | No-equipment path restricts to bodyweight only (contradicts docs)
- What: MEMORY.md says "no equipment set = all exercises available." Code excludes all exercises with equipment entries.
- Impact: Users without equipment config get dramatically reduced pool.

**11. muscle_normalizer.py:163** | Glutes in both lower_push and lower_pull categories
- Impact: Glute-dominant workouts get incorrect split classification, cascading into wrong type assignments.

**12. exercise_selector.py:1274** | Substring partner matching causes false positives
- What: `if base_name.lower() in partner.name.lower()` — "Curl" matches "Barbell Curl Right", "Hammer Curl Right", etc.
- Impact: Wrong exercises paired as L/R counterparts.

---

## PERFORMANCE — Unnecessary cost (18 findings)

**1. exercise/serializers.py:30,35** | N+1 per exercise for muscles + equipment (~3400+ queries on cache miss)
- Impact: `/exercise/all/` cold cache: 1133 exercises × 3 queries each.

**2. workout/serializers.py:56-77** | Triple N+1 on WorkoutSerializer (~5000+ queries)
- Impact: `all_workouts` cache miss: 633 workouts × (muscles + equipment + exercise_count).

**3. superset/serializers.py:32** | N+1 per superset for exercises, cascading through ExerciseSerializer
- Impact: Each workout detail triggers O(supersets × exercises × 3) queries.

**4. workout/helpers.py:14-71** | Cascade of N+1 queries in exercise list builder
- Impact: ~80+ queries per workout detail (supersets + exercises + serializer chain).

**5. generator/serializers.py:338** | N+1 for supersets in GeneratedWorkoutDetailSerializer
- Impact: Plan detail views trigger dozens of cascading queries per day.

**6. generator/views.py:1106** | Exercise.objects.get in triple-nested loop in save_plan
- Impact: 5-day plan with 5 supersets × 3 exercises = 75 individual SELECT queries.

**7. muscle_normalizer.py:218** | ExerciseMuscle query per exercise in analyzer (~19,000 queries)
- Impact: `analyze_workouts` command fires ~19,000 queries for 633 workouts.

**8. workout_analyzer.py:1332-1337** | 120 exists() checks in _step7
- Impact: 8 types × 3 sections × 5 goals = 120 individual queries.

**9. recalculate_workout_times.py:53-58** | Triple-nested N+1 with no prefetch (~18,000 queries)
- Impact: Command takes orders of magnitude longer than necessary.

**10. exercise_selector.py:593,629** | M2M querysets not cached (excluded_exercises + available_equipment)
- Impact: 15-30 redundant identical queries per workout generation.

**11. populate_exercise_fields.py:1006** | Individual save() per exercise (1133 UPDATE queries)
- Impact: Command takes minutes instead of seconds. No bulk_update.

**12. plan_builder.py:64,82** | Redundant save() after create() on Workout and Superset
- Impact: 2 unnecessary DB writes per superset creation.

**13. Various views** | Infinite cache with no invalidation strategy
- What: equipment, exercise, muscle, workout, video views all use `cache.set(key, data, timeout=None)` with no invalidation.
- Impact: New/edited data never appears until manual cache clear or restart.

**14. workout/serializers.py:109** | Redundant re-fetch of registered_user
- Impact: Extra query per workout detail for no reason.

**15. generator/views.py:570-572,604-607** | N+1 save pattern for re-ordering after delete
- Impact: Up to N individual UPDATEs instead of 1 bulk_update.

**16. generator/views.py:423-429,964-976** | N+1 for sibling exercise exclusion
- Impact: N queries instead of 1 IN query for sibling workout exercises.

**17. generator/views.py:70** | RegisteredUser.objects.get repeated 17x with no caching
- Impact: 1 unnecessary query per API request across all generator endpoints.

**18. exercise_selector.py:1063** | Potentially large retry loop in _weighted_pick
- What: `max_attempts = len(pool) * 3` with weighted pools of 500+ entries = 1500+ iterations.
- Impact: CPU-bound stall risk in constrained pools.

---

## SECURITY — Vulnerability or exposure (6 additional findings)

**1. werkout_api/settings.py:140** | ALLOWED_HOSTS=['*'] in production
- Impact: HTTP Host header injection, cache poisoning, password reset URL manipulation.

**2. werkout_api/settings.py:1-231** | Missing all HTTPS/security hardening settings
- What: No SECURE_SSL_REDIRECT, SECURE_HSTS_SECONDS, SESSION_COOKIE_SECURE, CSRF_COOKIE_SECURE, etc.
- Impact: Cookies sent over plaintext HTTP. No HSTS protection.

**3. werkout_api/settings.py:31** | Django Debug Toolbar enabled unconditionally
- Impact: Exposes SQL queries, settings, request data at `/__debug__/` in production.

**4. workout/views.py:24-33** | all_workouts returns ALL users' workouts (IDOR)
- What: `Workout.objects.all()` with no ownership filter.
- Impact: Any authenticated user sees every user's workout data.

**5. workout/views.py:39-49** | workout_details has no ownership check (IDOR)
- What: Any authenticated user can view any workout by guessing IDs.
- Impact: Insecure Direct Object Reference.

**6. workout/views.py:170-172** | GET endpoint triggers data mutation — bulk import
- What: GET triggers Celery task importing workouts for hardcoded user IDs. Any authenticated user can trigger.
- Impact: Data corruption via idempotent-violating GET.

---

## DATA INTEGRITY — Database/model consistency issues (5 findings)

**1. workout/views.py:94-138** | add_workout has no transaction wrapping
- Impact: Partial Workout/Superset records on mid-loop failure.

**2. plan_builder.py:59-149** | create_workout_from_spec has no transaction wrapping
- Impact: Core builder used by all generation paths creates orphaned records on error.

**3. workout_analyzer.py:249-252** | _clear_existing_patterns deletes without transaction
- Impact: If analysis crashes mid-way, ML pattern tables are empty with no recovery.

**4. workout/tasks.py:11-101** | Bulk import has no transaction or idempotency
- Impact: Partial imports, duplicate records on re-run.

**5. workout/views.py:150** | datetime.now() without timezone in USE_TZ=True project
- Impact: Incorrect PlannedWorkout filtering near midnight due to timezone mismatch.

---

## MODERNIZATION — Legacy pattern to update (4 findings)

**1. Dockerfile:13** | Python 3.9.13 base image (EOL October 2025)
- Impact: No further security patches.

**2. requirements.txt** | All dependencies pinned to mid-2023 versions
- Impact: Django 4.2.2 has had multiple security releases since.

**3. supervisord.conf:24** | Next.js runs `next dev` in production
- Impact: No production optimizations, source maps exposed.

**4. Various models** | max_length on IntegerField/FloatField (no-op parameters)
- What: 10+ fields across superset, workout, exercise models use meaningless `max_length` on numeric fields.
- Impact: Misleading — suggests validation that doesn't exist.

---

## DEAD CODE / UNREACHABLE (4 findings)

**1. exercise/serializers.py:5** | Import shadowed by local class definition
- What: Imports `ExerciseMuscleSerializer` then redefines it locally.

**2. exercise/models.py:4** | `from random import randrange` — imported but never used

**3. audit_exercise_data.py:88-89** | Dead `.exclude()` clause — logically impossible condition

**4. workout/views.py:76** | Unreachable None check after `.get()`

---

## FRAGILE — Works now but will break easily (5 findings)

**1. exercise_selector.py:613** | Hard exclude to soft penalty conversion mutates instance state permanently
- What: `_warned_small_pool` guard uses `hasattr` which survives `reset()`.
- Impact: Once triggered, ALL subsequent selections treat hard-excluded exercises with soft penalty only.

**2. exercise_selector.py:645** | Equipment map cache survives reset() — stale data possible
- Impact: Low risk per-request but dangerous in long-running processes.

**3. workout_generator.py:1046** | Working superset detection relies on name prefix 'Working'
- Impact: Any naming inconsistency silently breaks trimming, padding, modality validation, compound ordering, rebalancing.

**4. workout/models.py:51** | settings import via wildcard chain from exercise.models
- Impact: Transitive dependency breaks if `*` re-export chain changes.

**5. exercise_selector.py:260** | Working set exclusion icontains 'stretch' catches valid exercises
- Impact: Exercises like "Stiff Leg Deadlift Stretch Position" incorrectly excluded from working sets.

---

## Summary

### Summary by Category
| Category | Count |
|----------|-------|
| Critical | 18 |
| Bug | 28 |
| Silent Failure | 5 |
| Race Condition | 1 |
| Logic Error | 12 |
| Performance | 18 |
| Security | 6 |
| Data Integrity | 5 |
| Modernization | 4 |
| Dead Code | 4 |
| Fragile | 5 |
| **Total** | **106** |

### Summary by Source
| Source | Findings |
|--------|----------|
| Security Auditor | 34 |
| Data Integrity/ORM Auditor | 64 |
| Logic Errors Auditor | 42 |
| Performance Auditor | 41 |
| Generator Logic Auditor | 22 |
| API Correctness Auditor | 43 |
| Celery/Async Auditor | 24 |
| Config/Deployment Auditor | 30 |
| Cross-cutting Deep Audit | 35 |
| *(after dedup)* | **106 unique** |

### Top 10 Priorities

1. **[CRITICAL] settings.py — DEBUG=True + SECRET_KEY='secret' + CORS wide open in production** — Three compounding security misconfigurations that enable session forgery, CSRF bypass, and full API data theft from any website.

2. **[CRITICAL] registered_user/views.py:83-90 — request.POST wipes user data on JSON update** — Any JSON profile update sets email, name, image all to None. Active, reachable endpoint.

3. **[CRITICAL] registered_user/serializers.py:31 — Password hash exposed in API** — Invalid DRF Meta option means hashed password is readable in registration responses.

4. **[CRITICAL] scripts/views.py:43 — Anonymous cache wipe** — Unauthenticated endpoint wipes entire Redis cache. Active route, no auth required.

5. **[CRITICAL] supervisord.conf — No Celery worker + dev server in production** — All async tasks (HLS transcoding, imports) silently queue and never execute. Django dev server handles all production traffic.

6. **[CRITICAL] generator/views.py — No transaction.atomic() on save_plan/confirm_plan** — Multi-object creation loops with no transaction wrapping leave orphaned records on any failure.

7. **[BUG] workout/serializers.py:40 — HealthKit UUID silently discarded** — Sets wrong attribute name (`workout_uuid` vs `health_kit_workout_uuid`). Data permanently lost.

8. **[BUG] workout/views.py:124 + tasks.py:85 — None multiplication on estimated_rep_duration** — Nullable field multiplied without null check. Crashes workout creation and bulk import.

9. **[LOGIC] workout_generator.py:1459 — Workout type affinity matching NEVER works** — Space vs underscore comparison means all type assignments fall through to random round-robin.

10. **[PERFORMANCE] Serializer N+1 queries — 5000+ queries on cache miss** — WorkoutSerializer, ExerciseSerializer, and SupersetSerializer each trigger per-object queries with no prefetching. Mitigated by infinite caching but devastating on any cache clear.