Generate the 1954 sanctoral and rank dataset #64

Closed
opened 2026-07-01 00:52:42 +00:00 by manlycucumber · 2 comments
manlycucumber commented 2026-07-01 00:52:42 +00:00 (Migrated from github.com)

Problem

The 1954 calendar contains feasts and ranks absent or changed in 1962. A dedicated dataset is needed with the older double/semidouble/simple ranks and feasts.

Acceptance criteria

  • 1954 sanctoral feasts present with double-scheme ranks and colours
  • Feasts later suppressed are included for 1954
  • Observance IDs map to the same stable feast IDs where applicable
  • Spot-check fixture confirms a sample month

Notes

Reuse stable cross-system IDs from v0.1.0.

## Problem The 1954 calendar contains feasts and ranks absent or changed in 1962. A dedicated dataset is needed with the older double/semidouble/simple ranks and feasts. ## Acceptance criteria - [ ] 1954 sanctoral feasts present with double-scheme ranks and colours - [ ] Feasts later suppressed are included for 1954 - [ ] Observance IDs map to the same stable feast IDs where applicable - [ ] Spot-check fixture confirms a sample month ## Notes Reuse stable cross-system IDs from v0.1.0.
manlycucumber commented 2026-07-04 17:51:28 +00:00 (Migrated from github.com)

Follow-ups surfaced by the #66 (pre-1955 vigils) adversarial review, for this burndown:

  • vigilOf/octaveOf referential-integrity gate. Add a build-time gate (+ test) asserting every vigilOf/octaveOf placement target is placed in the same edition. It is premature until the full 1954 sanctoral lands here — the 1954 diff is intentionally sparse, so the 9 suppressed vigils' apostle / Immaculate-Conception feasts are not placed in 1954 yet (their vigilOf resolves against the shared identity, never dereferenced at runtime). Once this burndown authors those feasts, co-placement becomes the intended state and the gate can turn on.
  • Duplicate All Saints feast. roman:sanctorale:omnes-sancti ("Festum Omnium Sanctorum") and roman:sanctorale:omnium-sanctorum ("In Festo Omnium Sanctorum") are both Nov 1 / rank 1 / white. The golden trace treats them as two competing I-class feasts (omnes-sancti wins; omnium-sanctorum is 'transferred'), so resolving the duplicate will move the frozen golden traces — it belongs here, not in a data-only PR. The #66 All Saints vigil's vigilOf points at omnes-sancti (the winner).
Follow-ups surfaced by the #66 (pre-1955 vigils) adversarial review, for this burndown: - **vigilOf/octaveOf referential-integrity gate.** Add a build-time gate (+ test) asserting every `vigilOf`/`octaveOf` placement target is placed in the *same* edition. It is premature until the full 1954 sanctoral lands here — the 1954 diff is intentionally sparse, so the 9 suppressed vigils' apostle / Immaculate-Conception feasts are not placed in 1954 yet (their `vigilOf` resolves against the shared identity, never dereferenced at runtime). Once this burndown authors those feasts, co-placement becomes the intended state and the gate can turn on. - **Duplicate All Saints feast.** `roman:sanctorale:omnes-sancti` ("Festum Omnium Sanctorum") and `roman:sanctorale:omnium-sanctorum` ("In Festo Omnium Sanctorum") are both Nov 1 / rank 1 / white. The golden trace treats them as two competing I-class feasts (`omnes-sancti` wins; `omnium-sanctorum` is 'transferred'), so resolving the duplicate will move the frozen golden traces — it belongs here, not in a data-only PR. The #66 All Saints vigil's `vigilOf` points at `omnes-sancti` (the winner).
manlycucumber commented 2026-07-06 13:43:46 +00:00 (Migrated from github.com)

Follow-ups surfaced by the #67 (1954 precedence engine) adversarial review — for this burndown:

  • lady-on-saturday tier shadow (should-fix, must land WITH the first BVM-Saturday entry). Rubrics1954Precedence::tierOf() branches on the legacyRank grade ladder before the LADY_ON_SATURDAY kind check. The Saturday Office of Our Lady is a simplex office, so once this burndown authors it with legacyRank: simplex it will hit the simple tier (24) and never reach lady-on-saturday (26). It cannot fire today (the only simplex-graded 1954 entry is laurentius:in-octava; lady-on-saturday exists only as a tier definition, no sanctoral entry), so no resolved day changes — but the fix (move the LADY_ON_SATURDAY kind check above the grade-ladder branches, or exclude that kind from the simplex branch) must land in the same PR that adds the first BVM-Saturday office, tested together. Both candidate tiers are below the lesser-Sunday tier, so no accuracy-critical Sunday rule is affected either way.
  • isGreaterFeria() fallback rank <= 2 (nit). Dead today (every feria that reaches the fallback is rank 4). When this burndown expands the temporal rank data, tighten it to a season/kind allow-list so a future rank-≤2 non-privileged feria can't be wrongly commemorated when impeded.

Both are deferrals from the #67 review, not defects in #67 (verdict: SAFE TO MERGE, zero must-fixes).

Follow-ups surfaced by the #67 (1954 precedence engine) adversarial review — for this burndown: - **`lady-on-saturday` tier shadow (should-fix, must land WITH the first BVM-Saturday entry).** `Rubrics1954Precedence::tierOf()` branches on the `legacyRank` grade ladder *before* the `LADY_ON_SATURDAY` kind check. The Saturday Office of Our Lady is a *simplex* office, so once this burndown authors it with `legacyRank: simplex` it will hit the `simple` tier (24) and never reach `lady-on-saturday` (26). It **cannot fire today** (the only `simplex`-graded 1954 entry is `laurentius:in-octava`; `lady-on-saturday` exists only as a tier definition, no sanctoral entry), so no resolved day changes — but the fix (move the `LADY_ON_SATURDAY` kind check above the grade-ladder branches, or exclude that kind from the `simplex` branch) must land in the same PR that adds the first BVM-Saturday office, tested together. Both candidate tiers are below the lesser-Sunday tier, so no accuracy-critical Sunday rule is affected either way. - **`isGreaterFeria()` fallback `rank <= 2` (nit).** Dead today (every feria that reaches the fallback is rank 4). When this burndown expands the temporal rank data, tighten it to a season/kind allow-list so a future rank-≤2 non-privileged feria can't be wrongly commemorated when impeded. Both are deferrals from the #67 review, not defects in #67 (verdict: SAFE TO MERGE, zero must-fixes).
Sign in to join this conversation.
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#64
No description provided.