will
aba89dc250
Trinity Sunday wasn't modeled at all: getDayLabel had a purely
cosmetic "Trinity Sunday" label overlay for the Sunday after
Pentecost, but resolveTemporalId just fell back to post-pentecost-01
(ordinary-sunday category), so any Duplex+ saint assigned that date
(e.g. the Queenship of the BVM, fixed May 31) won outright, real
Trinity Sunday content never appearing anywhere.
Added a real temporal-feasts/trinity-sunday.yml record (Easter+56,
Duplex II. classis, live-verified). Per direct instruction,
unconditional: true (same shape as christ-the-king.yml) -- a
principal Sunday shouldn't lose a same-rank fixed-date collision, and
the one real collision case (Queenship of the BVM) isn't
independently verifiable against Monastic 1617 at all (that calendar
doesn't carry the Queenship feast -- May 31 there is St. Petronilla
instead).
Authored the full office and registered trinity-sunday in
ALWAYS_OVERRIDE_TEMPORAL_IDS -- the same generic mechanism already
built for the Pentecost-cluster fix, no new code needed: collect,
Benedictus/Magnificat antiphons, Matins hymn ("Summæ Deus cleméntiæ"),
Lauds/Vespers chapter (shared, Rom 11:33) and hymn (shared, "O lux
beáta Trínitas", already the pre-Urban VIII text), each hour's own
distinct responsory/versicle -- all live-verified 2026-05-31.
Fixed 3 pre-existing tests written around the old cosmetic-label
behavior, two of which had never-verified guesses baked in as if
correct: day-label.test.ts's "names the anchor day itself" test and
its "outranks an active octave" test (was asserting "Duplex I Class",
a guess -- the real live-verified rank is Duplex II);
transfer.test.ts's St. Felix I test.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01AGjUyhUZJaSjiniEmnLdak
32 lines
1.6 KiB
YAML
32 lines
1.6 KiB
YAML
# Read from the reference engine: web/www/horas/Latin/Tempora/Pent01-0.txt
|
|
# ("In Festo Sanctissimæ Trinitatis"), Duplex II. classis — live-verified
|
|
# 2026-05-31 (Trinity Sunday itself that year). Previously not modeled as
|
|
# its own record at all: `resolveTemporalId` just fell back to
|
|
# `post-pentecost-01`, so this Sunday — one of the principal Sundays of
|
|
# the whole year — displayed as a generic ordinary post-Pentecost Sunday,
|
|
# with whatever saint happened to be assigned that date (if any) winning
|
|
# outright per the plain `ordinary-sunday` rule. Found and fixed 2026-09-04
|
|
# after the user asked about a display-only-looking gap that turned out to
|
|
# be this much bigger mechanism gap.
|
|
id: trinity-sunday
|
|
name: "The Most Holy Trinity"
|
|
# Reference engine's own [Officium] title is a prepositional phrase ("In
|
|
# Festo Sanctissimæ Trinitatis"); adapted to this app's nominative-noun-
|
|
# phrase convention.
|
|
nameLa: "Sanctissima Trinitas"
|
|
rank: duplex-2-classis
|
|
anchor:
|
|
kind: easter
|
|
offset: 56
|
|
# Per direct instruction (2026-09-04): always wins, same as christ-the-
|
|
# king.yml's own `unconditional: true` — one of the year's principal
|
|
# Sundays shouldn't lose to a same-rank fixed-date collision. The one
|
|
# real case this matters for: the Queenship of the BVM (1954 addition,
|
|
# fixed May 31, also Duplex II. classis) lands on the same date as
|
|
# Trinity Sunday in rare years (e.g. 2026) — not verifiable against the
|
|
# Monastic Tridentinum 1617 track directly, since that calendar doesn't
|
|
# carry the Queenship feast at all (confirmed live: May 31 1617-track
|
|
# shows St. Petronilla instead, this app's own blended-calendar-only
|
|
# collision).
|
|
unconditional: true
|