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
40
41
42
43
44
45
46
47
48
49
50
//! Repeating cycle schedules (mission `repeating-cycle-schedules-01M3C7W1`).
//!
//! # Three things that look alike and are not
//!
//! * A **named cycle** — `[cycles.<name>]` or a `docs/cycles/*.md` record. It is the
//! manual registry: `tix cycle …`, the planning modal, rollover and an issue's
//! `cycles` references all point at its **name**.
//! * A **schedule** — `[cycle_schedules.<schedule-id>]`, this mission. A stable-ID
//! *definition* of a repeating cadence: how often a cycle starts, how long it
//! lasts, where it starts, in which timezone, and how far ahead to look.
//! * A **generated cycle** — one concrete instance a schedule produced, with a stable
//! identity of its own, its own lifecycle, and a snapshot taken when it closes.
//!
//! Keeping them apart is the mission's second constraint (C-002): a schedule never
//! replaces the named registry, never rewrites an issue's `cycles` reference, and
//! never moves an issue. The named registry stays usable exactly as it was.
//!
//! # The escalation boundary is a design boundary, not a caveat
//!
//! There is no daemon and no hosted scheduler (C-001). Detection is **read-only**:
//! it reports ended/due cycles and available actions, and it changes nothing (C-004).
//! Nothing here reads a clock — an evaluation is driven by an injected date context,
//! so the same input always produces the same answer. Generation and every lifecycle
//! action are explicit, confirmed operations.
//!
//! # One cadence vocabulary, one timezone rule, one arithmetic owner
//!
//! The recurring-issues mission (`recurring-issues-01M3C7G7`) already answered the
//! cadence, timezone and dependency questions for the sibling concept, and recorded
//! the answers in `docs/recurrence-dependency-review.md`. This module **reuses** them
//! instead of restating them: [`config::Cadence`] and a schedule's `timezone` are the
//! same `RuleKind`/`IntervalUnit`/`Timezone` vocabulary the series registry uses, and
//! [`config::Cadence::to_rule`] hands them to the one arithmetic owner,
//! `RecurrenceRule`, so interval bounds, month-end re-anchoring, leap days and the
//! daylight-saving refusal each live in exactly one place (C-008/C-009).
//!
//! # What this module owes each surface
//!
//! The CLI, the TUI's `F8` Schedule page, its startup refresh warning, MCP and
//! `tix lint` are all expected to read the *same* resolution rather than each
//! recomputing one (C-008) — the reason the evaluator, generator and lifecycle
//! actions are services with typed results here rather than logic in a command.