1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
//! The recurrence boundary: supported series rules and the schedule arithmetic
//! behind them (mission `recurring-issues-01M3C7G7`, WP01).
//!
//! A recurrence rule is **data**, never executable code. It names one of five
//! supported families — daily, weekly, monthly, interval, cron-like — and the
//! cron-like family reaches a parser only through the review-gated seam in
//! [`rule`] (`docs/recurrence-dependency-review.md`). Everything here is a pure
//! function of the rule and an **injected** local date/timezone context: domain
//! code never reads the ambient clock, so detection and generation are exactly
//! as deterministic in a test as in production.
//!
//! # What lives here, and what does not
//!
//! [`rule`] owns the typed model, its field-aware validation, and the
//! deterministic next-date arithmetic that produces canonical `YYYY-MM-DD` keys.
//! It touches no files and holds no state, so the whole surface is testable with
//! no `Store` and no `tempfile`.
//!
//! Later work packages add siblings that consume these rules, each in its own
//! module: `series` (stable series identity and occurrence keys, WP02), `detect`
//! (read-only due warnings, WP03), `generate` (confirmed idempotent occurrence
//! creation, WP04), and `lifecycle` (pause/resume/skip/end/defer/ignore, WP05).
//! Those modules own persistence and mutation; this one owns the rule, and only
//! the rule.
//!
//! # Date keys are calendar dates, on purpose
//!
//! A rule produces a canonical date key (`YYYY-MM-DD`) and nothing else. The key
//! is byte-identical for the same rule and the same injected context, it sorts
//! chronologically as a plain string, and it needs no timezone to be meaningful.
//! A timezone is carried on the rule only as an explicit, auditable policy; a
//! named IANA zone is refused rather than guessed, because its daylight-saving
//! transitions would make a date ambiguous.