A retroactively logged start leaves its "not yet" answers behind to penalise the next cycle #48

New Issue

Closed

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

null commented

2026-08-20 16:13:29 -05:00

Owner

Found by tracing the learning loop at 93ec5b7.

What is true now. confirmPeriodStart clears not-yet observations with notYetDao.deleteBefore(startDate.plusDays(1)) — only those dated on or before the confirmed start. A period logged retroactively (she answered 'Not yet' on the 29th, then logged the 28th on the 30th) leaves the 29th's observation alive. It then censors the next cycle's forecast: a confidence penalty via PersonalPredictionEngine.notYetPenalty and a floor under the window, both for a question that is already answered.

What it costs. Confidence quietly depressed on a cycle where nothing is wrong — and the user is told her forecast is less certain than it is.

What to do. Every stored observation censors the same single question ('when does the period after the latest confirmed start begin?'), so a confirm that becomes the newest start moots all of them at once: clear all. A backfill into the middle of history resolves nothing about the standing question and must keep the current date-bounded clear.

Traps. This needs a deleteAll() on NotYetObservationDao, which is the deliberate exception to that file's documented no-deleteAll-by-convenience rule — amend the header note to name the exception rather than leaving the next reader to think it was overlooked. Do not overshoot into 'any confirm clears everything'; the deep-backfill pin below exists to catch exactly that.

Verify: a not-yet dated after a retroactively logged start does not haunt the next cycle (red before, green after) and a deep backfill does not clear the observations censoring the standing question (green both sides) in CycleRepositoryTest.kt.

Found by tracing the learning loop at 93ec5b7. **What is true now.** `confirmPeriodStart` clears not-yet observations with `notYetDao.deleteBefore(startDate.plusDays(1))` — only those dated on or before the confirmed start. A period logged retroactively (she answered 'Not yet' on the 29th, then logged the 28th on the 30th) leaves the 29th's observation alive. It then censors the *next* cycle's forecast: a confidence penalty via `PersonalPredictionEngine.notYetPenalty` and a floor under the window, both for a question that is already answered. **What it costs.** Confidence quietly depressed on a cycle where nothing is wrong — and the user is told her forecast is less certain than it is. **What to do.** Every stored observation censors the same single question ('when does the period after the latest confirmed start begin?'), so a confirm that becomes the newest start moots all of them at once: clear all. A backfill into the middle of history resolves nothing about the standing question and must keep the current date-bounded clear. **Traps.** This needs a `deleteAll()` on `NotYetObservationDao`, which is the deliberate exception to that file's documented no-deleteAll-by-convenience rule — amend the header note to name the exception rather than leaving the next reader to think it was overlooked. Do not overshoot into 'any confirm clears everything'; the deep-backfill pin below exists to catch exactly that. Verify: `a not-yet dated after a retroactively logged start does not haunt the next cycle` (red before, green after) and `a deep backfill does not clear the observations censoring the standing question` (green both sides) in CycleRepositoryTest.kt.