Deferred: §30's four-button follow-up and §29's custom reminder time #75

New Issue

Closed

opened 2026-08-20 21:24:15 -05:00 by null · 0 comments

null commented

2026-08-20 21:24:15 -05:00

Owner

Filed rather than fixed, so the gap between the specification and the app is recorded rather than rediscovered.

What is true now.

docs/planning/PRODUCT_PLAN.md:1330-1341 (§30) specifies four follow-up buttons — [Yes, Today] [Yes, Yesterday] [Choose Date] [Not Yet]. The app offers exactly two actions, always (core/notifications/.../NotificationCopy.kt:123-133, ReminderWorker.kt:131-139).
docs/planning/PRODUCT_PLAN.md:1287-1293 (§29) lists Morning / Afternoon / Evening / Custom. app/.../feature/settings/NotificationSettingsScreen.kt:129-135 offers three fixed buttons (09:00 / 14:00 / 19:00) and no picker, although reminder_minute_of_day already stores an arbitrary minute.

Why they are filed and not fixed. The four-button follow-up needs a dated-action wire format — which the sibling issue in this batch introduces — plus a deep-link into the Today sheet for 'Choose Date'. That is a product surface with its own copy and its own QA, not part of hardening; doing it inside a correctness batch would mix a behaviour change into commits meant to be provably safe. The custom time is pure UI on a preference that already supports it, and is better done alongside whoever next touches that screen.

Traps. 'Yes, Yesterday' is not a shortcut for today-minus-one at write time — it must resolve against the day the reminder asked about, or it reproduces the dated-action defect this batch fixes. Adding a third and fourth action changes the notification's layout on small screens and on the lock screen, where §28's privacy modes constrain what the labels may say.

Verify: a decision recorded here — either both are implemented with tests and the §29/§30 rows in the QA plan updated, or this issue is closed with the reason they stay deferred.

Filed rather than fixed, so the gap between the specification and the app is recorded rather than rediscovered. **What is true now.** 1. `docs/planning/PRODUCT_PLAN.md:1330-1341` (§30) specifies four follow-up buttons — `[Yes, Today] [Yes, Yesterday] [Choose Date] [Not Yet]`. The app offers exactly two actions, always (`core/notifications/.../NotificationCopy.kt:123-133`, `ReminderWorker.kt:131-139`). 2. `docs/planning/PRODUCT_PLAN.md:1287-1293` (§29) lists Morning / Afternoon / Evening / **Custom**. `app/.../feature/settings/NotificationSettingsScreen.kt:129-135` offers three fixed buttons (09:00 / 14:00 / 19:00) and no picker, although `reminder_minute_of_day` already stores an arbitrary minute. **Why they are filed and not fixed.** The four-button follow-up needs a dated-action wire format — which the sibling issue in this batch introduces — plus a deep-link into the Today sheet for 'Choose Date'. That is a product surface with its own copy and its own QA, not part of hardening; doing it inside a correctness batch would mix a behaviour change into commits meant to be provably safe. The custom time is pure UI on a preference that already supports it, and is better done alongside whoever next touches that screen. **Traps.** 'Yes, Yesterday' is not a shortcut for today-minus-one at write time — it must resolve against the day the reminder asked about, or it reproduces the dated-action defect this batch fixes. Adding a third and fourth action changes the notification's layout on small screens and on the lock screen, where §28's privacy modes constrain what the labels may say. Verify: a decision recorded here — either both are implemented with tests and the §29/§30 rows in the QA plan updated, or this issue is closed with the reason they stay deferred.