There is a week in every musher's life when the plan and the logbook stop telling the same story. A dog limping for three days, a storm, a work trip — and suddenly a fortnight has been half run on a plan that keeps asking for the full thing.
Until now, MushMate told you so. A banner appeared: "the team is under the plan", with the percentage and a button to regenerate. The statement was true, but it left you with a blunt choice: redo everything, or do nothing.
What changes
The server now computes a proposal — a complete plan, recalculated from what you actually ran — and shows it to you instead of applying it.
You see a band of cards, one per upcoming week. On the ones that change: the old number of kilometres struck through, the new one right beside it. On the ones that don't: the figure, set back. You tap the weeks you want to take. The button counts as you go: "Take these 3 weeks". Next to it, the other button simply says "Keep mine".
Above the band, a chart: bars for your current plan, a line for what you actually ran, and a dotted line for what the proposal suggests. It is there so you see the why before deciding the what.
What it does not do — and that is not "not yet"
The plan never regenerates on its own. That was true before and it stays true. The proposal is computed and stored; it becomes your plan only if you tick weeks and confirm. Do nothing, and nothing happens.
Weeks you have already run do not move. What is past is past: the proposal copies them verbatim and recalculates only what lies ahead. If a week already behind you no longer matches — a dog removed from the objective, say — the server refuses to compose rather than choose for you.
You will not be drowned in proposals. A proposal does not reopen just because the gap persists: you must have logged new runs and the gap must have grown by half, or changed direction. After you decline, the screen simply reminds you of the date you said no.
On your phone too. The proposal shows up on the Objective screen, right above your current week: the same sentence, the same weeks to tap, the same two buttons. You decide where you are, including on the way back from a run.
What the phone does not show, and this is not "not yet": the chart, and the load jump shown under a week you have just taken. The threshold that defines a "jump" is set per objective, and that value does not reach the device yet. We chose to show nothing rather than a percentage that could differ from the desktop's for the same plan. A number that contradicts itself between two screens is worse than a missing number.
You need to be online to decide. The decision recomposes your plan on the server; it is not queued. Out of coverage, the screen says so and does nothing — your proposal will wait.
And only the kennel owner decides. Other members see the card and its numbers, without the buttons: the information is useful to everyone, the decision belongs to one person.
A decision taken against the obvious
The simplest thing for us would have been to offer a whole plan: "here is the new one, take it or leave it". One button, no band, no counter.
We did not, because it is almost always wrong. A musher who missed two weeks for a good reason should not have to throw away the rest of the season. They usually know, better than the model, which week they will make up and which they will not. Splitting by week costs more to build — and asks one more gesture of you — but it leaves you the one thing the model does not have: your context.
One honest consequence to know about: by taking two weeks out of three, you can create a step that neither your plan nor the proposal carried. The screen flags it under the week concerned, the moment you tick it. Your call.