A teammate caches the first preview “because the calculation is pure”. The service handles different days, policies and account records over its lifetime. A caller may also edit the notice plan it receives.
Tomorrow’s preview shows yesterday’s remaining days; a renewed account can still receive its old reminder.
Reproduce
One service previews the same account at day 40 and day 41. Its notice should change from near:2 to near:1. The starter repeats near:2.
Acceptance criteria
- Each preview reflects that request’s complete account values, day and window.
- Editing a returned plan cannot change a later preview.
- Preview remains free of sends, and explicit delivery records the current plan once.
- Keep the cache only if it preserves every stated behavior; removing it is a valid fix.
Notes
- Inputs are already validated: unique nonempty account IDs, whole day indices from 0 to 10000, and a reminder window from 0 to 30. The service has already chosen its calendar convention; do not parse dates or read a clock.
- An account is due when 0 ≤ endsOn − today ≤ window, including expiry day. Keep input order and leave supplied records unchanged.
- The sent list is a local delivery stand-in, not an email service. Each case creates fresh state; all requests inside that case use one service. Sending twice is two explicit sends, not deduplication.
- Keep the supplied entry points and data fields. Alternate loops and helpers are welcome. The checks observe outputs, input preservation and the supplied sent list; they cannot prove arbitrary code has no other side effects.