When a race date moves (or is cancelled)

What Grepiac does automatically

If the athlete is on a plan, the season view shows THAT plan's phases — the weeks of their annual plan, or of the training plan they're subscribed to — so moving a race does not silently redraw their blocks. Change the plan to change the phases.

The race-anchored shape below applies only to an athlete with no plan attached yet, where the season view estimates phases from the A, B, and C race dates and labels them as an estimate. Phase lengths are dynamic, derived from the methodology, the race distance, and the target fitness, not fixed week counts. The shape per priority:

• A race (the target of the plan): full progression, Base → Build → Peak → Taper, then a short recovery. Gets a full taper whose length scales with race distance.
• B race: compressed, with a smaller taper and no dedicated peak. The athlete trains through most of it.
• C race: no dedicated taper, trained through as a tune-up, with at most a few easy days around it.

For a plan-less athlete, the estimated phases recompute on next page load when a race date changes. You do not need to push a button; just edit the race date and the season view reflects the new dates. For an athlete on a plan, the bars follow the plan, so after moving a race you re-shape the plan itself (annual planner or training plan) — the season page will then show the new shape.

What Grepiac does NOT do automatically

• MacrocyclePlan config_json is not auto-edited. If the individual plan holds weekly volume targets keyed to specific dates, those targets do not move when the race date moves. You have to edit the plan or re-deploy from a template with updated dates.
• Race results, recaps, and CalculatorResults stay attached to the race regardless of date changes (they follow the race PK, not the date).
• Other races are not auto-rescheduled. If two A races were 6 weeks apart and one moves, the new spacing might produce a conflict (e.g. taper for one overlaps build for the other). Grepiac does not warn you; you check visually on the season view.

Race moved (rescheduled)

1. Open the race edit form (/coach/race/<race_id>/edit/).
2. Change the date.
3. Save.
4. Refresh the season view. Phases recompute.
5. Walk the season visually. Look for: * Taper / build conflicts between adjacent races. * A race that is now too close to a previous hard race. * Loss of the original peak window (if the race moved much earlier).
6. Edit the macrocycle plan if the weekly structure no longer fits.

Race cancelled

1. Open the race and set a status — never delete it, or you lose the goals, notes and season context with it: * cancelled if the race itself is off (organiser called it). * dns if the race is going ahead but the athlete is not starting. Either way it stops contributing a training phase, drops off every upcoming list and out of the race digest and weather emails, and stops holding TrainFed's deficit locked — while staying in the athlete's history. See DNF / DNS handling.
2. Check whether the macrocycle plan still has a clear A-race anchor.
3. If a new replacement A race is added, the auto-phasing picks it up; you may need to re-deploy the macrocycle from its team template (if it was derived) or edit the individual plan to align.

Race moved into the past

A result status (completed, DNF, DQ, NC) only makes sense after a race has happened, so the model rejects those on a future-dated race and asks you to correct the date or wait until after the race. cancelled and dns are exempt — both are known ahead of race day. A backdated (past) race can carry any status normally. If you backdated a race by mistake, correct the date and save.

Communication

When a race moves, write a CoachNote on the athlete explaining the change and the plan implications. Most athletes notice a season-view phase shift before you explain it; the note short-circuits the confusion.

See also: Adding a race, Macrocycle plan basics, Editing a deployed plan, DNF / DNS handling.