Monthly should mean a month after it was last done.

01

The old assignment was valid until the meaning changed.

Preserving work is usually a sensible default. That is why this bug is more interesting than a date calculation in isolation. An assignment created under a fixed schedule had a reason to exist. Once I changed the task to count from completion, that old reason no longer applied. The planner needed to recognise the change in meaning rather than preserve the row simply because it was already there.

The repair distinguished a mode transition from an edit within the same mode. That boundary prevents a broad cleanup from becoming destructive. If I only change a detail of an existing rolling chore, the current turn may still be useful. If I switch from fixed dates to completion based timing, the planner has to reconsider which turn belongs to the new rule. The visible due date is the final result of that decision.

02

Thirty days is not a month

The repair also changed monthly rolling calculations to use calendar months rather than a flat thirty day interval. A monthly promise is expressed in a calendar, and the calendar does not contain twelve identical thirty day blocks.

This is a small difference in code with a visible consequence in the interface. If a date is surprising, the person using the product does not care that the scheduler was internally consistent. They care whether “monthly” meant what they expected.

03

I needed the calendar promise to survive February.

Monthly sounds ordinary until the implementation turns it into a constant number of days. Then the promise begins to drift across months of different lengths. The useful review examples are at the edges: a completion near the end of January, a short February, and the transition through daylight saving time. These are checks I would use to make the calendar semantics explicit, rather than assume that adding a duration expresses the same intent.

The source recorded both the rule repair and affected production state being corrected. It also recorded the local database test gap. I keep those together because repairing code, repairing existing rows, and running integration checks answer different questions. The interactive date example makes the relationship inspectable without pretending to be a screenshot of the scheduler’s internal state.

04

August 26: the behaviour needed a better explanation.

Once the scheduling distinction existed in the implementation, I challenged the way we described it. Rolling was familiar inside the project, but it did not explain what happened after a chore was finished. I wanted a reader to see the relationship between completion and the next due date.

The interactive example in this article exposes that relationship directly. It is an explanation of the rule, not a screen from the app or a completed marketing campaign. My next communication check would be to ask someone to explain the next due date from the visual alone. That check is a proposal, not a study I have already run.

Completion dates and household presence influence different parts of scheduling. I return to that question in Three people at home should not mean nine days of waiting.