Stage 3: Plan editor with Steps, Supersets and reordering

- Plan model with immutable edits: add with Mode defaults, move, remove,
  Superset with next, take a member out, ungroup; Stretching length
  estimate from holds, sides, rounds and Transitions
- drift database (plans table, items as JSON, ADR 0005) and
  PlanRepository; Plans list per Mode with rename/duplicate/delete
- Editor: drag handles, step editor sheet (sets, reps or time, optional
  kg; hold, both sides, rounds; Superset sets and rest between),
  pause between holds for Stretching Plans
- Exercise picker reusing the Library browser; Add to plan from the
  Exercise detail page
- Theme: Mode-styled snackbar, FAB, menus, segmented buttons, switches

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
CedricandClaude Opus 5.5 committed 2026-10-28 23:48:07 +01:00
1 parent 786dd52e30
commit bbdca95541
28 files changed
+3654 -11

No files matched your search

@@ -0,0 +1,18 @@
# ADR 0005 — A Plan's Steps and Supersets are stored as JSON
Status: Accepted (2026-10-29)
A Plan's items (Workout Steps, Stretching Steps and Supersets with their members) are stored as one
JSON column on the `plans` row, following CookIT's ADR 0002. A Plan is always loaded, edited and saved
as a whole, every edit is an immutable `Plan.withX` operation that can be unit-tested without a
database, and reordering or grouping into Supersets needs no position or group bookkeeping.
Plans are only listed per Mode, newest first.
## Consequences
- Items carry no ids; the editor keys rows by object identity, which is enough because every save
re-reads the Plan.
- Sessions will store a snapshot of the Plan's items (same JSON), so editing a Plan never changes
History.
- Querying across Plans by Exercise in SQL would need a table of its own; nothing needs it yet.