Thanks Rumo. I've made some minor tweaks - do they work for you?

Sure!

🚀

I just wanted to document customData and realised it might not be very useful in its current implementation. I understand the goal is to facilitate persistent custom variables which will be used for calculating scheduling states. Let's say we have something like this:

const fooFactor = customData.fooFac || 1;
if (states.good.normal?.review) {
  states.good.normal.review.scheduledDays *= fooFactor;
}
customData.fooFac = calculateNewFooFactor(fooFactor); // what's the point?

As the custom variable must be calculated in advance, it cannot take into account the answer rating. But without it, what scheduling variable worth persisting can we possibly calculate?
Shouldn't customData be stored in every member of states, so that we can pick the new one depending on the rating?

Am I missing something?

You're right 🤦 I guess we could pack it into the top level of SchedulingState so we don't have to update every enum variant?

Sounds good, I'll take care of it.