feat: particular-calendar overlay model and decorator (#75) #442

Merged
manlycucumber merged 1 commit from feat/75-overlay-framework into develop 2026-07-02 20:33:26 +00:00
manlycucumber commented 2026-07-02 20:32:22 +00:00 (Migrated from github.com)

The core of the particular-calendar overlay framework (epic #75) — the mechanism SSPX/FSSP/ICKSP calendars use to layer over the universal 1962 sanctoral as pure data, never engine code. First slice of the R2 / 3mi.org overlay work.

What lands

  • src/Overlay/ — the declarative model (#76): a CalendarOverlay is an identified, named set of OverlayOperations over stable feast IDs:
    • RerankOperation — keep a universal feast but rank it differently (SSPX elevates St Pius X + the Seven Sorrows to I class); re-cites the changed field to the overlay's source.
    • AddOperation — a proper feast the universal calendar lacks (a society's own saint).
    • SuppressOperation — a universal feast the particular calendar drops.
    • At most one operation may target a feast, so application is order-independent; a failed precondition raises OverlayConflict so a malformed overlay fails loudly.
  • OverlaidSanctoralData (#77) decorates the existing SanctoralData seam the resolver already reads through — so an overlay changes only the data the resolver sees. Precedence, concurrence, and commemoration logic are untouched. The version stamp carries the overlay id.
  • CitationSet::merge layers an overlay's citation over the base entry's.

Proven

11 tests / 62 assertions against the known SeedSanctoralData slice: a re-rank + add + suppress applied together, identity/date/colour preserved with the rank re-cited, order-independence, and every conflict rule.

Follows (this epic)

The cited YAML→NDJSON overlay format + generator (#76 data), the day() selector + output stamping (#78), and the full SSPX overlay content + conformance gate against the SSPX feed (#80).

Gate: lint clean · analyse [OK] · test 668 (1 skip).

Refs #75 #76 #77

The core of the **particular-calendar overlay framework** (epic #75) — the mechanism SSPX/FSSP/ICKSP calendars use to layer over the universal 1962 sanctoral **as pure data, never engine code**. First slice of the R2 / 3mi.org overlay work. ## What lands - **`src/Overlay/` — the declarative model (#76):** a `CalendarOverlay` is an identified, named set of `OverlayOperation`s over stable feast IDs: - `RerankOperation` — keep a universal feast but rank it differently (SSPX elevates St Pius X + the Seven Sorrows to I class); re-cites the changed field to the overlay's source. - `AddOperation` — a proper feast the universal calendar lacks (a society's own saint). - `SuppressOperation` — a universal feast the particular calendar drops. - At most one operation may target a feast, so application is **order-independent**; a failed precondition raises `OverlayConflict` so a malformed overlay fails loudly. - **`OverlaidSanctoralData` (#77)** decorates the existing `SanctoralData` seam the resolver already reads through — so an overlay changes only the *data* the resolver sees. **Precedence, concurrence, and commemoration logic are untouched.** The version stamp carries the overlay id. - **`CitationSet::merge`** layers an overlay's citation over the base entry's. ## Proven 11 tests / 62 assertions against the known `SeedSanctoralData` slice: a re-rank + add + suppress applied together, identity/date/colour preserved with the rank re-cited, order-independence, and every conflict rule. ## Follows (this epic) The cited YAML→NDJSON overlay format + generator (#76 data), the `day()` selector + output stamping (#78), and the full SSPX overlay content + conformance gate against the SSPX feed (#80). Gate: lint clean · analyse [OK] · test 668 (1 skip). Refs #75 #76 #77
Sign in to join this conversation.
No reviewers
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
Directorium/Core!442
No description provided.