From 12b97761019cfa02ca0da8a5fb50ef815d07685c Mon Sep 17 00:00:00 2001 From: Lukasz Kasprzak Date: Fri, 21 Aug 2026 14:42:30 +0200 Subject: feat(ef): implement RG 33's third omission trigger RG 33 omits a II/III-class vigil in three cases: it falls on a Sunday, it falls on a I-class feast, "vel si festum cui praemittitur in alium diem transferri aut ad commemorationem reduci contingat". Only the first two were built; the third was recorded in precedence_ef.ml as unimplemented on the grounds that no witness existed in the shipped data. That reasoning was wrong, and the rule fires on 1 744 days across 1583-9999. Both halves of the clause reduce to one observable question -- is the feast the OBSERVED office on the following day (RG 34 puts it there) -- so the kernel asks it once per candidate, after place_transfers has settled the year. No fixed point is needed: a vigil is a candidate only on its own day, never on its feast's, so suppressing it cannot change what the next day observes. Precedence.rules gains vigil_feast, which returns the slug of the feast a vigil precedes; the kernel cannot infer that itself, because only two of the five vigil/feast pairs share a slug stem. Blast radius, measured pre-change binary vs HEAD over the whole domain and classified: 1 744 days, three shapes, zero unexplained. 1 199 are the feast reduced to a commemoration (10 August on a Sunday, St Lawrence); 478 and 67 are the feast transferred under RG 96 after the Sacred Heart or Corpus Christi takes its day. The Assumption's and the Ascension's vigils never qualify -- their I-class feasts always keep their own day. Independently witnessed, which is unusual here. The published Ordo -- the only witness outside the Divinum Officium -> missalemeum -> lectio lineage -- omits St Lawrence's vigil on 2025-08-09, agreeing with colitur against both engines. That date had been read earlier as an Ordo gap; the Ordo was right, and correcting the misreading is what surfaced this clause. On 2027-08-09 the feast does keep its day and the Ordo omits a vigil colitur correctly keeps, which is a genuine Ordo gap. Allow-lists: C39 (lectio, 10 rows) and a 2038 oracle class citing the register, the 2026-2027 window having no instance. The golden pin asserting St Lawrence's vigil is violet moved 2025 -> 2027; its own comment had reasoned about the vigil's weekday and missed that RG 33 also looks at the feast's. Two new pins cover both shapes of the clause. The vigil/feast table is built with Slug.of_string_exn: mutation testing showed that of_string plus Result.to_option turns a typo into None, which this hook's contract reads as "not a vigil", switching the rule off in silence. Two tests assert the table against the shipped data in both directions. --- lib/kernel/precedence.mli | 40 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 40 insertions(+) (limited to 'lib/kernel/precedence.mli') diff --git a/lib/kernel/precedence.mli b/lib/kernel/precedence.mli index 09376d7..a0b4b1a 100644 --- a/lib/kernel/precedence.mli +++ b/lib/kernel/precedence.mli @@ -86,6 +86,46 @@ type ('s, 'r) rules = { own module documentation (Rite_ef.Precedence_ef.admit); stated here because this signature -- not any one rite's implementation of it -- is what an author of the next rite reads. *) + vigil_feast : 'r candidate -> Slug.t option; + (** The feast this candidate is a VIGIL OF, when the rite subjects that + vigil to omission because its feast did not keep its own day; + [None] for every other candidate, which is what a rite with no such + rule returns unconditionally. + + Exists for RG 33's third omission trigger -- "vel si festum cui + praemittitur in alium diem transferri aut ad commemorationem reduci + contingat", "or if the feast it precedes happens to be transferred + to another day or reduced to a commemoration". Both halves of that + clause reduce to ONE observable question, which is why this hook + returns a slug rather than a verdict: is the named feast the + OBSERVED office on the following day? {!Calendar} asks it and + suppresses the vigil when the answer is no. A feast transferred away + (RG 96) and a feast outranked into a bare commemoration (RG 94) both + fail that test; so does a feast omitted outright, which RG 33 does + not enumerate but which is strictly the stronger case. + + WHY THE RITE NAMES THE FEAST. The kernel could not infer it. RG 34 + fixes the vigil on the day BEFORE its feast, so the date is known, + but nothing in {!Celebration.t} links the two and the slugs do not + reliably derive from one another -- in the EF's own shipped data + only two of five vigils ("ef-ascension-vigil"/"ef-ascension", + "vigil-of-sts-peter-paul"/"sts-peter-paul") share a stem, while + "vigil-of-st-lawrence" precedes "lawrence" and + "vigil-of-the-assumption" precedes + "assumption-of-the-blessed-virgin-mary". Deriving the feast by + string surgery would be wrong for three of the five. Asking "is a + Class1 sanctoral office observed tomorrow?" would be a PROXY, and + would fire on a day where some UNRELATED I-class feast had + transferred in on top of the real one -- the vigil's feast would be + absent and the vigil wrongly kept. + + CALLED ONCE PER CANDIDATE PER DAY, and the resolution of the + following day that {!Calendar} performs to answer it does NOT + itself apply this rule. That is not an approximation: a vigil is a + candidate only on its own day, never on its feast's, so suppressing + it cannot change what is observed the day after. The check is + therefore a single pass with no fixed point and no recursion -- + unlike RG 96's transfers, which genuinely need one. *) } (** The outcome of resolving one day's candidates. *) -- cgit v1.3