Project the next year onto the calendar, with its assumption said out loud #57

New Issue

Closed

opened 2026-08-20 16:38:05 -05:00 by null · 0 comments

null commented

2026-08-20 16:38:05 -05:00

Owner

What is true now. CalendarMarks.forMonth marks only the single next forecast window, so paging the calendar forward shows blank months even for a user whose cycle is textbook-regular. 'Will I have my period the week of the wedding?' is a core prediction question the app cannot answer, and browsing stopped one month ahead.

What to do. A CycleProjection type in domain/prediction, separate from Prediction because a forecast is scored and a projection never is — separate types stop a projection reaching the accuracy figures by accident. Cycle 1 is the engine's own forecast copied through unchanged so the calendar and Today screen cannot disagree. Uncertainty grows as the square root of cycles ahead; the projection stops rather than stretching once a window passes ten days either side; every month showing projected marks carries the assumption sentence and the confidence for that distance.

Traps. The failure to avoid is the one the widget library this came from walks into: stamping a fixed cycle length twelve months forward and drawing it exactly like the next period. Use her own typical cycle, never a population default — projecting 29 days for a 35-day user is §3's core defect repeated twelve times. DayMark.PROJECTED_PERIOD must be visually distinct from PREDICTED_PERIOD in greyscale, not by opacity. Logging must still stop at today even though browsing does not.

Verify: CycleProjectionTest in domain/prediction — window widens with distance, confidence never rises, a vague forecast stops early and reports that it stopped, nothing projects past a year, a confirmed period still outranks a projection on the same day, and a caller that does not ask for projections gets the calendar it had.

**What is true now.** `CalendarMarks.forMonth` marks only the single next forecast window, so paging the calendar forward shows blank months even for a user whose cycle is textbook-regular. 'Will I have my period the week of the wedding?' is a core prediction question the app cannot answer, and browsing stopped one month ahead. **What to do.** A `CycleProjection` type in `domain/prediction`, separate from `Prediction` because a forecast is scored and a projection never is — separate types stop a projection reaching the accuracy figures by accident. Cycle 1 is the engine's own forecast copied through unchanged so the calendar and Today screen cannot disagree. Uncertainty grows as the square root of cycles ahead; the projection stops rather than stretching once a window passes ten days either side; every month showing projected marks carries the assumption sentence and the confidence for that distance. **Traps.** The failure to avoid is the one the widget library this came from walks into: stamping a fixed cycle length twelve months forward and drawing it exactly like the next period. Use her own typical cycle, never a population default — projecting 29 days for a 35-day user is §3's core defect repeated twelve times. `DayMark.PROJECTED_PERIOD` must be visually distinct from `PREDICTED_PERIOD` in greyscale, not by opacity. Logging must still stop at today even though browsing does not. Verify: `CycleProjectionTest` in domain/prediction — window widens with distance, confidence never rises, a vague forecast stops early and reports that it stopped, nothing projects past a year, a confirmed period still outranks a projection on the same day, and a caller that does not ask for projections gets the calendar it had.