From e45ec1ccce68d9edb9655004c21861d6bfb33a9d Mon Sep 17 00:00:00 2001 From: Lukasz Kasprzak Date: Thu, 13 Aug 2026 12:24:19 +0200 Subject: test,docs: RG110(c)'s adjacency is unobservable by construction The re-review asked for a third commemoration in the shape-(c) row, so that "spliced immediately after its trigger" could be told apart from "appended at the end" -- it had proved an append-at-end variant passed the whole suite green, the pair alone being too short to distinguish them. Attempting it establishes something better than the test requested. On this day-shape a third commemoration is rubrically impossible. Shape (c) requires the trigger to lose the day while still being admitted, and a Class2 trigger can only lose to a I-class day (RG 111(a): one privileged commemoration) or a II-class Sunday (RG 111(b): one, "scilicet de festo II classis"). Both caps are one. The third candidate is now offered and correctly refused, which is the assertion worth having. So RG 110(c)'s "ante omnes alias commemorationes" half has no reachable witness in the EF's rubrical space, and the re-review's own finding that shape (c) never co-occurs with a third commemoration across 8417 years is a consequence of the rubric rather than an accident of the data. The append-at-end variant stays indistinguishable from the splice on every input the engine can construct. Recorded rather than papered over with a synthetic row proving a shape no rubric permits. Also drops Record from the "nothing compares commemoration order" note -- Record.t has no commemorations field at all -- and names, at privilege_of's own (a) branch, that the Holy Name's Sunday privilege currently rests on a substring match rather than on RG 17's closing paragraph, which is its real warrant. --- lib/rites/rite_ef/precedence_ef.ml | 21 +++++++++++++++++---- 1 file changed, 17 insertions(+), 4 deletions(-) (limited to 'lib/rites/rite_ef') diff --git a/lib/rites/rite_ef/precedence_ef.ml b/lib/rites/rite_ef/precedence_ef.ml index cd0c53b..5a2d307 100644 --- a/lib/rites/rite_ef/precedence_ef.ml +++ b/lib/rites/rite_ef/precedence_ef.ml @@ -514,7 +514,18 @@ let privilege_of (c : Vocab_ef.rank Precedence.candidate) : Precedence.privilege let is_temporal = c.Precedence.origin = Precedence.Temporal in let open Vocab_ef in (* (a) RG 109(a) (§4): "of a Sunday" -- the same slug marker RG 33's - [impedes_vigil] already reads to answer "is this candidate a Sunday". *) + [impedes_vigil] already reads to answer "is this candidate a Sunday". + + FRAGILITY, named here because this is the decision point (fix-round + re-review, F5): [is_sunday_slug] is a SUBSTRING match, so the Holy Name + of Jesus obtains this privilege on its Sunday shape only because its + slug happens to read "ef-holy-name-sunday". That is a naming accident, + not a cited rule. The real warrant is RG 17's own closing paragraph + (quoted in full at temporal_ef.ml's [holy_name_sunday]): "Haec festa + locum tenent dominicae occurrentis cum omnibus iuribus et privilegiis" + -- these feasts hold the occurring Sunday's place WITH ALL ITS RIGHTS + AND PRIVILEGES, of which RG 109(a)'s privilege is one. A slug rename + would silently drop it while every test stayed green. *) if is_sunday_slug slug then Precedence.Privileged (* (b) RG 109(b) (§4): "of a I-class day" -- the candidate's own rank. In this codebase's current disposition rules the ONLY way a @@ -1185,9 +1196,11 @@ let rg110_find_companion comms companion_slug = compares commemoration ORDER at all -- the lectio differential does not compare commemorations (its own "limit 1"); the oracle's own [identity_diff] sorts both sides into a multiset before comparing; - {!Colitur_kernel.Record}/`describe` (test_golden.ml) both sort their own - comms field too, for the same reason presence/identity checks should not - be order-sensitive by accident. This function's own [admit_cases] unit + and [describe] (test_golden.ml) sorts its own comms field too, for the + same reason presence/identity checks should not be order-sensitive by + accident. (CORRECTED, fix-round re-review: this previously also named + {!Colitur_kernel.Record}. Record.t has NO commemorations field at all -- + see record.mli -- so it neither sorts nor carries them.) This function's own [admit_cases] unit test (test_precedence_ef.ml) is therefore the ONLY place in this codebase's test suite where commemoration order is asserted at all -- flagged here, and in CLAUDE.md's own "know what each layer cannot see" -- cgit v1.3