# Cadence — independent interface redesign brief for Claude

## Your task

The owners dislike Cadence's current interface and want multiple proposals before choosing any direction. They explicitly asked for independent proposals from Claude as well as another assistant. The product brief is: **“Explore broadly — the whole interface needs a rethink”** and **“The whole app, with emphasis on logging a workout.”**

Produce **three materially different whole-app redesign proposals** for this offline iPhone training log. Do not implement anything, run commands, edit the repository, ask questions, or request tools. This brief is self-contained. Other assistants' directions have deliberately not been included. Think independently. The proposals need different information architectures or workout interaction models as well as different visual character; three palettes over the same layout are insufficient.

Audience: two regular gym users who direct development in plain language and care about how the app feels during training. Make the proposal understandable to them, while concrete enough for a SwiftUI developer to build. Fast, legible, one-handed workout logging is the priority, but show that the idea works across the whole app. Use only the synthetic data below. These are proposals for comparison, not an approved production design.

## Product and technical constraints

- Native iPhone app written in SwiftUI with Observation, Charts, Foundation, HealthKit, ActivityKit and other Apple system frameworks. Deployment target iOS 18+; current development and verification use Xcode 27 / iOS 27. Do not depend on a new-only component without an iOS 18 fallback.
- No third-party runtime dependencies, accounts, network, cloud sync, subscription, social feed, online AI coach, external assets fetched at runtime, or new data source. Each user has a separate local database on their own phone. Preserve offline functionality.
- The existing domain separates routine prescriptions from actual logged sets. Progression recommendations seed future entry rather than rewriting history. A UI change must preserve those semantics.
- Versioned local JSON storage, atomically saved with a previous-good snapshot. Interrupted workouts and rest deadlines persist across app termination. Read failures preserve files and present read-only recovery instead of resetting history. Existing backups must remain readable. A visual redesign should normally require no database migration; any new stored state must be optional or explicitly migrated.
- Exercise UUID identity is stable across renames, library updates, machine customisation, archiving and historical references. Machine variants with the same movement remain distinct histories. Do not combine them to simplify the interface.
- Metric units: kg and km. Effort and strength record calculations must keep their current meaning. No fictional GPS tracking, heart-rate capture, energy estimate, Watch app, or calendar-based program scheduling.
- Use native SwiftUI components and available SF fonts / symbols where suitable. Propose detailed component grammar, font sizes and spacing, rather than claiming “native” by itself. Custom compositions are fine if feasible with Apple frameworks. Provide both light and dark behavior without making one universally superior.
- The app already has licensed offline movement drawings and body muscle figures, with artwork attribution in Settings. Drawings can be used where useful but are unavailable for some movements; layout must gracefully handle that.

## Existing feature inventory — preserve and find a clear home for it

1. **Starting and resuming:** Today suggests the next routine in an ordered program; routines open a preview; open workouts can start from scratch. Only one workout can be active. If another start control is tapped while a workout is active, it resumes that workout; the redesign should make this behavior explicit and avoid implying it starts the routine being viewed. Minimise/resume and a persistent active-workout indicator work throughout the app.
2. **Strength logging:** kg, reps, RPE and optional RIR; select-all numeric entry and keyboard Next/Done; previous sets for comparison; normal, warm-up, failure, drop, AMRAP and timed set types; completion and undo; add/delete sets; exercise replacement and reordering; workout, exercise and set notes. Replacing an exercise that has recorded sets warns that those sets will be removed from the current session.
3. **Equipment setup:** one setup note per exercise, shown prominently on the current live set and on its exercise page, editable during the workout; separate from routine-entry and workout notes. Brand/model labels identify distinct machine exercises. A configurable default weight jump seeds new prescriptions while old prescriptions retain their original jump. Exercises can be archived from new selection without deleting history or routine references, and restored later.
4. **Supersets:** exercise groups; automatic next-set routing through the group; users can choose a different set manually and change/reorder exercises without losing context.
5. **Rest:** persisted deadline, +15/other adjustments, skip, foreground haptic/sound, optional local notification while locked. Live Activity / Dynamic Island displays the rest countdown with skip and +15, and local notifications provide a fallback. Rest and set entry must remain usable while browsing other parts of the workout or app.
6. **Finishing:** any workout with a completed valid set can be saved; uncompleted sets remain visible in history as skipped. An empty workout cannot be saved as if complete. Discard is explicit and confirmed. Show a useful completion summary; do not invent rewards or scores with no basis in stored data.
7. **Routines/programs:** create/edit/duplicate/reorder/delete/start routines; sets, rep ranges, load, rest, RPE/RIR targets, superset groups and progression. Programs are repeatable ordered routine sequences that advance after completion, not scheduled calendar plans. Routine text import is deterministic, reviewed and corrected before saving.
8. **Progression:** fixed and double progression with reduction after two missed sessions; actual entry receives a recommendation without rewriting past prescriptions. Effort is recorded but does not drive progression.
9. **History:** session list/detail, draft-based editing and deletion; exercise history; heaviest load, Epley estimated max for 1–12 reps, rep records and best sets by rep range; volume excludes warm-ups as appropriate. Live PR callouts when completing a set, based on finished workouts plus the current session, warm-ups excluded.
10. **Progress:** Charts; weekly consistency, weekly external load volume, primary-muscle working-set counts, and a month calendar counting training days rather than workout count. Tap a trained day to see its sessions. Exercise charts and records are available for trained movements.
11. **Library:** 290 local exercises covering barbell, dumbbell, machine, cable, bodyweight and other equipment, plus conditioning. Search recognises aliases such as “db press”, “pullup”, “curls” and “rdl”; filter by muscle and equipment; recent exercises first; multiselect additions; custom exercise create/edit/delete where unused; archive/restore. Exercise guide provides movement drawings where available and primary/secondary muscle figures, accessible from exercise history and picker long press.
12. **Plate calculator:** per-side breakdown for a barbell load, with closest achievable load if plate inventory cannot make it exactly; bar weight and inventory configurable in Settings.
13. **Other activities:** manually log running/cardio distance and duration with computed pace; mobility/yoga duration and effort; intervals, EMOM and AMRAP timers with work/rest settings, round and partial-round entry, and sequence notes. Interval clocks recover from wall time after backgrounding; interval phase sound cues occur in the foreground only. Do not hide these to create a strength-only app.
14. **Data and measurements:** versioned JSON export/import, validation, previous snapshot restore and pre-import recovery copies; Hevy CSV history import with conversion, exercise-mapping review and repeat-import deduplication. Measurements include bodyweight and custom metric/unit entries, removable by swipe. Optional Apple Health export of a finished workout (type and duration, no guessed calories), and reading latest bodyweight; permissions requested only when users choose an action. Stable sync/sample IDs prevent duplicates. Local edits/deletion do not rewrite exported Apple Health data.
15. **Sample/recovery:** a separate temporary sample database with six weeks / 24 synthetic sessions, never merged into personal data; a clear read-only recovery screen linking to restore/import. Artwork credits remain accessible.

## Current interface — factual description, not a preferred direction

### RootView.swift

The root is a four-tab `TabView`, each containing its own `NavigationStack`: **Today / Train / History / Progress**. Settings is a gear button opening a sheet from Today. Today uses a native List and sections: date, next program routine shown in a rounded surface with 3 big figures (exercise count, set count, prior duration) and Start/Resume; start open workout; weekly training ticks; last session; all routines with preview and separate start controls. Train duplicates some starting/routine access, then lists routine management and program management. History is a session list and Progress is a list of calendar, charts, muscle counts and exercise record links. There is no standalone library tab; the picker and exercise pages are entered through training/routine editing/progress.

Active workouts open as a modal sheet. A bottom inset outside the sheet displays active workout name, elapsed timer and upward chevron as a resume control, regardless of selected tab. Routine previews and Settings also open sheets; presentation coordination handles opening an active workout from a preview or Lock Screen request. Read-only recovery overlays the root with a Settings link.

### Instrument.swift and shared colors

The current system is a restrained “instrument” look: white canvas / near-white neutral surfaces in light mode, black canvas / very dark neutral surfaces in dark mode; gray rules and hairlines; amber live-state accent (approximately #A85C08 light and #FFB020 dark). It uses large SF system numerals, monospaced digits, tracked uppercase micro labels (base 11 pt, larger fallback at accessibility text sizes), rounded 16 pt bordered surfaces, and an amber-filled 54 pt minimum-height action button with 11 pt radius. Week ticks are narrow vertical marks with weekday initials. A persistent session footer shows elapsed time, completed-set count and external load volume. The redesign is allowed to rethink all of this.

### ActiveWorkoutView.swift and its components

The active-workout sheet contains a `NavigationStack` and scrolling List of all workout exercises. Top fields edit workout title and notes. Each `ActivityEditor` is a section with a large exercise heading (27 pt base), options menu, equipment/muscle/prescription micro label, recommendation text and rows of sets. The header links into the exercise's history/guide. Exercise options expose replacement, note/setup editing, show RIR and move earlier/later. Extra exercise details reveal rest prescription, superset group and exercise notes. “Add exercise” follows the full list.

In strength logging, one next live set is expanded as a rounded bordered card; other sets collapse into a compact ledger. The expanded `SetRow` shows set type/index, Set n of total / live label, setup note, large kg and reps inputs side by side (one column at accessibility text sizes), smaller effort inputs, previous-set comparison, plate hint, and the full-width Log set button. Tapping a collapsed set expands it for editing. A recorded set has an undo checkmark and possibly PR badge. Set type is a small menu at the left. Keyboard Next cycles metrics and can move to the next set.

Completing a set records it, starts rest if appropriate, collapses that entry, chooses the next set, and scrolls to it; supersets route to the next grouped exercise. The rest bar is attached near the relevant set. Reopening tries to scroll to the current set. Current toolbar contains Minimise, workout options/discard, Edit, and Finish. A bottom safe-area inset shows session statistics. Finishing prompts to save/discard, preserving uncompleted sets as skipped. These functional behaviors should remain, while their presentation can change substantially.

## Synthetic comparison fixture

Use the same concrete workout in all three directions, so the difference is the interface rather than the data:

- Today: Thursday 1 October. Routine **Upper A**, next in program **Upper / Lower**, 5 exercises, 15 working sets, approximately 45 minutes last time. Weekly consistency: 3 sessions. No real user history.
- Active workout: **Upper A**, elapsed **18:42**, **6 of 15** working sets logged. Current movement: **Bench Press (Barbell)**, prescription **3 × 8–10**, **70 kg**, **120 sec rest**, target **RPE 8**. Setup note: **“Rack height 9 · feet under knees”**.
- Previous session: 67.5 kg × 10 / 9 / 8. Today, set 1 is already logged **70 kg × 9 @ RPE 8**. Set 2 is ready to log **70 kg × 8 @ RPE 8**, with optional **RIR 2**. Set 3 is uncompleted. The displayed active rest state after set 1 has **01:15** remaining. A user can edit/log early, skip rest, or add 15 sec.
- Next movement: **Seated Row (Machine) · Machine A**, setup **“Seat 4 · chest pad 3”**, 3 × 10–12 at 45 kg. Also include a superset example **Lateral Raise (Dumbbell) ↔ Face Pull (Cable)** to explain routing.
- Example progress fact: bench heaviest working load **72.5 kg**; recent estimated max chart may show **86 → 90 → 92 kg** only as synthetic values. Avoid claiming 70 × 8 is a new PR if it does not exceed the displayed existing record.
- The plate hint for 70 kg with a 20 kg bar can be **25 kg per side**. Library has recent bench/row entries and a search for “row” with equipment filters. History has a synthetic **Upper A · Tue 29 Sep · 43 min · 15 sets** entry.

## What each proposal must explain

For each of your THREE proposals, provide:

1. Name and short thesis, plus the actual behavioral principle that makes it distinct.
2. Concrete palette (hex colors and semantic roles for light/dark), type (SF family/design, sizes/weights, Dynamic Type), spacing/radii, and native component grammar. Say where imagery belongs and where it does not.
3. Top-level navigation and the persistent active-workout route.
4. Plans for Today/start, active logging, routine/program planning, history, progress, library/exercise detail, and Settings/data recovery/measurements. Every inventory item above must have a home.
5. A detailed active-workout screen layout for a typical iPhone **393 × 852 point** canvas: hierarchy from top to bottom, what's initially visible, the main thumb action, keyboard behavior, rest controls, set comparison, setup note, exercise switching, optional detail access, and finish/resume behavior. Do not rely on screenshot inspection, as you have none.
6. The actual interaction sequence for starting Upper A, reviewing setup, changing weight/reps, logging a set, resting, undoing or correcting it, handling the superset, minimising, reopening, and finishing with skipped sets. Specify obvious affordances; don't require discovering gestures to log or navigate.
7. Three specific sample screens per direction suitable for later mockups. Use **Today**, **active workout**, and one **Progress or Library** screen, with concrete visible text and described layout. These should read like visual compositions, not feature lists.
8. One meaningful strength, one distinctive tradeoff, implementation effort (low/medium/high, relative to a UI-only SwiftUI refactor), accessibility treatment (44 pt targets, contrast, color-independent state, VoiceOver, Dynamic Type, Reduce Motion), and explicit preserved-feature mapping.

Avoid fashionable jargon, stock fitness gamification and “more whitespace” without a specific layout. Do not recommend a winner; let the owners compare equally developed directions.

## Required response format

Return **one valid JSON object**, with no prose or Markdown fences outside it. Use this exact top-level structure, retaining plain-language content inside fields:

```
{
  "briefVersion": "cadence-independent-v1",
  "proposals": [
    {
      "id": "claude-1",
      "name": "...",
      "thesis": "...",
      "distinctivePrinciple": "...",
      "palette": { "light": {"canvas":"#...", "surface":"#...", "ink":"#...", "muted":"#...", "accent":"#...", "success":"#..."}, "dark": {"canvas":"#...", "surface":"#...", "ink":"#...", "muted":"#...", "accent":"#...", "success":"#..."} },
      "typography": "...",
      "componentGrammar": "...",
      "navigation": "...",
      "screens": { "today":"...", "activeWorkout":"...", "routinesPrograms":"...", "history":"...", "progress":"...", "libraryExerciseDetail":"...", "settingsRecoveryMeasurements":"..." },
      "activeLayout": ["top-to-bottom zone..."],
      "interactionSequence": ["step..."],
      "sampleScreens": [{"name":"Today", "composition":"...", "visibleCopy":["..."]}, {"name":"Active workout", "composition":"...", "visibleCopy":["..."]}, {"name":"Progress or Library", "composition":"...", "visibleCopy":["..."]}],
      "strength": "...",
      "tradeoff": "...",
      "implementationEffort": {"level":"low|medium|high", "reason":"..."},
      "accessibility": "...",
      "preservedFeatures": [{"feature":"inventory group...", "home":"..."}]
    }
  ]
}
```

Use ids `claude-1`, `claude-2`, `claude-3` in order. Aim for about 900–1,300 words per proposal. Be concrete and complete while keeping each idea comparable. Do not copy this placeholder example text.