Add a guided FTP test with retest reminders and progress tracking

[HugoLeBoennec]

Why

The ramp and 20-minute protocols already existed — as two rows in a list of fourteen bundled workouts, with no explanation of what FTP is, which test to pick, or when to retest. FTP drives every workout target in the app, so a rider who never sets it trains against the 200 W default forever. Beginners are the ones most likely to be in that position and the least likely to go looking, so this promotes FTP testing to a destination of its own.

What the research says

• Protocol choice depends on experience, not preference. The ramp test (start ~100 W, +20 W/min to failure, FTP = 75% of the final minute) is easy to execute and repeatable but can read high for riders with a strong sprint. The 20-minute test (95% of the average) is more accurate but requires pacing — exactly the skill a first-timer lacks, so a badly paced first attempt reads low. Coaching guidance is explicit: default beginners to the ramp for their first two cycles, then move them across.
• Retest every 4–6 weeks, at the conservative end. Threshold adaptations take roughly 3–6 weeks to register as measurable power, and a maximal effort costs 1–2 days of quality training either side. CTS is stricter (6 weeks minimum, up to 2–4 months). Consistency of conditions matters more than which protocol you pick.

Sources: Cycling Weekly · CTS/TrainRight · TrainerRoad · Roadman Cycling · Canadian Cycling Magazine

What's here

• /ftp-test screen (lib/presentation/screens/ftp_test_screen.dart) — FTP explainer, status card, protocol picker with the recommendation badged and pre-selected (override allowed), preparation checklist, and an FTP-over-time chart with a test-to-test history list.
• Home dashboard card — doubles as the reminder: badges START HERE for an untested rider, DUE once the interval elapses.
• FtpTestPlanner (lib/core/application/services/ftp_test_planner.dart) — pure-Dart retest timing and protocol recommendation.
• Settings — retest interval, six weeks by default, adjustable from four to sixteen.

Notable decisions

Schema migration (v6). FTP history stored only a date and a value, so "last changed" and "last tested" were indistinguishable — anyone nudging their FTP by hand in Settings would silently stop getting reminders. Added a nullable source column; pre-v6 rows read back as manual, the conservative default. A test that confirms an unchanged FTP now still writes an entry, otherwise a rider whose fitness held steady would never reset the clock.

Consolidated a duplicate enum. FtpTestType (presentation) and FtpTestProtocol (domain) were the same thing — collapsed into the domain one across 5 call sites.

Restored generated schema files. Regenerating the drift schema rewrote v2–v5 in a newer style that drops the insert helpers the migration tests use. Only the v6 addition is kept; v2–v5 are untouched. Worth knowing before the next regeneration.

Testing

flutter analyze clean, all 835 tests pass.

• 17 unit tests for FtpTestPlanner (status boundaries, custom intervals, protocol graduation, progress across manual edits, future-dated entries).
• 8 widget tests for the FTP test screen.
• Storage round-trip tests for the recorded source, plus a v5→v6 migration test asserting pre-existing entries survive with a null source.

Three existing widget tests broke because the new card and tile pushed content below the 800×600 test viewport. Those tests were given a taller surface rather than having assertions adjusted — the content was correct, just unbuilt.

🤖 Generated with Claude Code