Epic: Data-preserving schema redesign for scaling foundation

[Yanchek99]

Summary

Track the full data-preserving schema redesign for WOD Tracker. The goal is to keep PostgreSQL, replace polymorphic metrics with structured domain columns, preserve existing data through additive migrations/backfills, support hundreds of programs posting daily workouts, support lazy user-specific workout instances, and prepare for future scaling recommendations from movement-level logged history.

Implementation Issues

• Add direct workout and log score fields #1622
• Clean up segment modeling #1623
• Move exercise prescriptions onto exercises #1624
• Move movement log performance onto movement logs #1625
• Remove legacy metrics storage #1626
• Evolve schedules into program workouts #1627
• Add lazy user workout instances #1628
• Add movement taxonomy and substitutions #1629
• Build initial rule-based scaling foundation #1630

Recommended Order

1. Add direct workout and log score fields (Add direct workout and log score fields #1622).
2. Clean up segment modeling (Clean up segment modeling #1623).
3. Move exercise prescriptions onto exercises (Move exercise prescriptions onto exercises #1624).
4. Move movement log performance onto movement logs (Move movement log performance onto movement logs #1625).
5. Remove legacy metrics storage (Remove legacy metrics storage #1626).
6. Evolve schedules into program workouts (Evolve schedules into program workouts #1627).
7. Add lazy user workout instances (Add lazy user workout instances #1628).
8. Add movement taxonomy and substitutions (Add movement taxonomy and substitutions #1629).
9. Build initial rule-based scaling foundation (Build initial rule-based scaling foundation #1630).

Data Preservation Rules

• Each phase should be additive before destructive.
• Backfills must copy existing data from old fields/tables into new fields/tables.
• Reads can temporarily prefer new columns and fall back to legacy metrics during migration.
• Writes should switch to new columns only after backfill.
• Legacy metric storage should be removed only after tests and parity checks pass.
• Any unmapped metric should be reported during migration instead of silently dropped.

Acceptance Criteria

• All child issues are linked from this epic.
• Overall migration order is clear.
• Destructive cleanup only happens after parity is verified.
• Existing seeded and user-created data is preserved.
• The resulting schema is structured enough to support future movement-level scaling recommendations.

Assumptions

• PostgreSQL remains the source-of-truth database.
• The first goal is structured data quality, not immediate ML.
• Constantly varied workouts mean recommendations should generalize from movements, movement families, loads, volume, time domains, and logged performance.
• Personalized workout copies should be created lazily, only after user engagement.