The Coach Moved Your Workout Before You Said Yes

About this post: this describes how our own app handles chat requests, from an audit of our code and its test runs. No real athlete's data was involved.

You type: "legs are shot, shorten today."

There are two ways an app can answer. It can propose a change and wait for you. Or it can make the change and tell you afterwards. Our chat did the second, for a particular family of requests, and we had not looked hard at it until an audit did.

What the old path did

When a small reader was confident you wanted something shorter, lighter or skipped, the message took a fast route. In order:

1. The reader labelled the request as a shorten, a tired day, or a skip.
2. The fast path ran the same adjustment routine that sits behind the buttons on the Today screen.
3. That routine rewrote today's sessions in your plan, logged the decision, and pushed the changed workout to your connected device.
4. Only then did the reply appear, with a card saying what had been done and an Undo button.

The arithmetic was fine. The order was not.

You asked for something easier. You did not choose how. "Move it to tomorrow" does not just shorten a session: it inserts a session into tomorrow and can push the end of your plan back. All of that was decided and written before you could see it, and the Undo button asked you to notice a change you had not reviewed and reverse it.

We had decided this on purpose

This was not an accident. An earlier decision record of ours permitted immediate shortening when the request was clear, on the theory that one fewer tap was friendlier. Our rule since then is that a change to your calendar waits for your tap, because the tap is your consent. The chat path had not caught up.

Reading the code is how we found the gap. The audit followed a message from the chat box to the database, and the database was written to before the card was shown.

What happens now

Chat does not change your workouts. When you ask for something easier, it builds a proposal: the sessions you have that day, and the exact replacements, worked out by the same plain code as before. The card shows both sides. Pick an option and tap, and that change is applied once.

Behind the tap is a signed approval that binds four things: your account, the local day, the exact list of sessions on the card, and the options offered. The server works the change out again on its own side. Nothing your phone or browser sends is trusted as a workout.

If anything differs when you tap, because you changed the day on another device, or left the card open overnight, the tap is refused with "Your calendar changed" and nothing is written. No half-applied day. The new workout goes to your device only after the change has been committed.

Two smaller decisions went with it:

• Cards from before keep their Undo, because they record something that really happened. The shorten and skip buttons on the Today screen still act on tap, since they are a tap.
• The reply wording changed. The old fallback text announced the change as made. It now says "Nothing changes until you apply the card."

What the check is for

The stale check protects your consent to the version you reviewed. It does not limit what you can ask for. Ask for a longer ride, or a harder day, and the proposal shows you that. We did not add a gate on load, duration, sleep or heart rate variability along the way.

How it was tested

The change merged on 2026-11-06. Its approval tests run against a real Postgres database and passed 15 of 15 in CI, and the browser walkthrough passed all 101 of its checks.

What we have not checked: real phones, real watches, paid AI models, and native accessibility behaviour. The local test setup used fake device providers, so it shows the flow works, not that a watch received a workout.

Want a coach that proposes and waits for your yes? Get early access.