Hi Joachim, AppVeyor builds were not starting, I re-authorized the repo and they are working again, but you need to push some change to restart the build.

Removed an empty line, appveyor seems to run now

Hi Joachim, I am not sure I understand the rationale for this.
When you execute a planned workout on a different date than planned you still have the original date in the planned activity, no need to move the planned activity.
If you decide to move the planned part you are changing the plan and I don't understand why this change needs to be logged unlike all other changes you can do to a plan s.t. changing for a shorter easier workout due to insufficient recovery or time constraints.

Hi Ale, I want to cover the following two usecases, do they sound reasonable to you? This PR is the base, the usecases will be implemented in later PRs

Usecase 1

Currently my plan keeps on drifting (multiple reasons like injuries, fatigue, sickness, family, work, ...). I would like to have a chart to analyze the plan and execution retrospectively:

• Why started my plan to drift?
• Is the plan doable for me?
• What should be changed next time?
• What assumptions did I get wrong?
• Did I insert unplanned activities?
• Did I skip planned activities?

The screenshot shows a rough sketch and were the original planned date comes into play. This chart will only be about time and execution, not stress.

Usecase 2

When (later) exporting a training plan, I would like to be able to preserve the original intent and schedule, even if rest days were inserted

Hi Joachim, I think the plan should be keep unchanged so the comparison (and future export) are WRT the original plan, when you miss a workout of execute it on a different day or add a non planned activity or change the characteristics of a planned activity you reflect that on the actual activity so you always can compare what you really did vs what was planned. It would rapidly became murky if you want to have multiple versions of the plan you want to compare to, IMHO.
BTW, I am not sure what you mean by "insert a rest day", I always assumed a day without a planned/actual activity is a planned/actual rest day.

Hi Ale, We share the same goal: keeping the original plan immutable for comparison, export, and repetition. The original planned date does not create new plan versions, but acknowledgments that life happens, while preserving original intent.
As the PMC is based on past actual and future planned activities, unfinished planned activities from past days will be ignored. This makes the projection less exact, especially when executing them later. Shifting a days plan when not fulfilled, closes this gap.
Additionally, the agenda helps to easily find the next upcoming workout without need to scan the calendar for missed planned activities. This also requires moving planned if missed.
Inserting a rest day refers to the shift-functionality in the calendar: When fatigue or any duties prevent you from training, all planned activities on and after the selected day will be shifted by one day.
The chart I described is my proposal to compare the execution to the plan, not only from a PMC point of view but from a time perspective: Where did the drift start, how did it evolve?

Now I understand the use case, you have a plan but no deadline so you can shift the workouts, may be that is a common pattern. I am more used to plans targeting specific events with fixed dates where you can't do that, if you miss a workout you just move on and continue with rest of the plan -or interchange workouts if the missed one is particularly relevant-, eventually you may need to review the rest of the plan when the discrepancy becomes too large, but just to shift in time is not a common action, or even an option in this case.

Ale, thanks a lot for merging, this is highly appreciated. I think the main issue (long interruption of the plan) should later be tackled with the macro planning
What do you think about collecting different personas to ease such discussions for the future? If you don't mind I will start a thread on the list, including a description of myself. This would help tailoring new features from the start.

Agree on both, Joachim.
Starting a new thread from scratch with a description of current status of Planning features to discuss future directions looks as a great idea.
I will be travelling the next weeks, but I will trigger a snapshot update before that.