1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
|
; data/ef/adjustments.sexp -- hand-authored overlay over data/ef/sanctoral.sexp
; (Task 11). NOT generated by tools/bootstrap_sanctoral.ml -- edit directly.
;
; Suppresses `vigil-of-christmas` (24 Dec, data/ef/sanctoral.sexp, lectio's
; own bootstrapped entry): it is the SAME celebration as colitur's temporal
; cycle's own `ef-nativity-vigil` (rite_ef/temporal_ef.ml's [named], also 24
; Dec, RG 91 entry 5), not a second, distinct one. Once the sanctoral layer
; is live, that date would otherwise carry two candidates for one feast.
; Recorded as an Overlay directive rather than filtered out of the bootstrap
; or special-cased in code, per the task brief -- an auditable, diagnosable
; removal (Overlay.apply's own diagnostic fires if this slug is ever absent,
; e.g. after a re-bootstrap that renames it), not a silent drop.
;
; RG16(a) task (docs/research/rules-register.md §6.0): corrects one of
; data/ef/sanctoral.sexp's six `(subject Lord)` entries, inherited unchecked
; from lectio's own `class = lord` field (tridentine-calendar.ini) --
; `most-holy-name-of-mary` (12 Sep): calendarium line "Sanctissimi Nominis
; Mariae, III classis" -- "Nominis Mariae", the Name of MARY, not of the
; Lord, with no counter-evidence found anywhere (the "D. N. I. C." formula
; the genuinely Lord-tagged entries carry, e.g. 6 Aug "IN TRANSFIGURATIONE
; D. N. I. C.", is simply absent here, and nothing else in the calendarium
; suggests otherwise). This tag has no behavioural effect either way today
; ({!Precedence_ef.band}'s entry 14, the only place [subject] is tested for
; a II-class candidate, requires [Class2]; this entry is [Class3]) -- kept
; for the data's own accuracy, not because anything currently reads it.
;
; The tag [Bvm] itself carries no further systematic meaning in this
; codebase beyond "not Lord" -- after this correction it exists on exactly
; this one entry, while every other Marian feast (the Assumption, the
; Immaculate Conception, the Nativity of the BVM, ...) stays `(subject
; Saint)`. Nothing reads [Bvm] specifically; {!Subject.t}'s four-way split
; is not fully exercised by this codebase's own logic, only [Lord] is.
;
; RG16(a) task, fix round 1 (CRITICAL finding, reverted): a companion Edit
; here previously also retagged `purification-of-the-blessed-virgin-mary`
; (2 Feb) to [Bvm], on the same calendarium-title argument ("B. Mariae
; Virg.", not "D. N. I. C."). REVERTED -- the user has ruled: follow the
; oracle. missalemeum (this project's designated EF oracle) treats the
; Purification as taking an occurring II-class Sunday's place OUTRIGHT, with
; NO commemoration of the Sunday (`2020-02-02`, `2014-02-02`: title
; "Purification of the Blessed Virgin Mary", `"commemorations": []`),
; exactly RG 16(a)'s own "festum Domini" treatment -- and NOT the treatment
; it gives an ordinary Marian feast on a Sunday (`2019-09-08`, the Nativity
; of the BVM: title "XIII Sunday after Pentecost", the FEAST demoted to a
; commemoration, the Sunday observed -- the opposite pattern). Genuine
; primary-text counter-evidence for the Marian reading remains on record
; (RG 120(b): the white-colour rule groups 2 February under "B. Mariae
; Virg.", a SEPARATE category from "Domini" -- register §6.0 quotes it in
; full), so the calendarium TITLE and the oracle's BEHAVIOUR disagree here;
; the user's ruling resolves that disagreement in the oracle's favour for
; this codebase's own purposes, not by declaring the calendarium argument
; wrong. See register §6.0 for the full account of both sides.
;
; ef-rebootstrap (2026-08-12): both directives re-examined against the
; regenerated source (tridentine-calendar.ini, SHA-256 1b303ef2...), which
; independently fixed several of the same defects this file was written to
; patch. Neither directive was removed -- reasoning below, per the task's
; own instruction to decide deliberately rather than delete on sight.
;
; `Edit most-holy-name-of-mary` -- the base bootstrap no longer needs this
; correction: the regenerated INI's own `[most-holy-name-of-mary]` section
; has DROPPED its `class = lord` field entirely (confirmed by direct grep
; against the source), so `tools/bootstrap_sanctoral.ml`'s `parse_subject`
; now falls through to its own default, `Subject.Saint` -- not `Lord` --
; before this overlay ever runs. Checked what {!Overlay.apply}'s [Edit]
; actually does with a directive whose target slug is present but whose
; field is no longer wrong, rather than assuming: [Edit] has no notion of
; "already correct" -- it looks up the slug, and if found (as this one
; still is) unconditionally folds every field_edit over the current value,
; firing NO diagnostic either way (overlay.ml's [apply_directive], the
; [Edit] branch: the only diagnostic is "slug not present", never "already
; matches"). So this is not a no-op: it still forces `Saint -> Bvm` on
; every run, identically to before, just starting from a different base
; value than it used to. Decision: KEEP, for two independent reasons, not
; one -- (1) DATA PRECISION, unaffected by the base bootstrap's own fix:
; the calendarium's "Sanctissimi Nominis Mariae" title names Mary
; specifically, so [Bvm] remains the more accurate tag than the generic
; [Saint] default, on the same textual grounds as the original entry
; above, regardless of what lectio's own `class` field happens to say this
; week. (2) REGRESSION DEFENCE: because [Set_subject] is unconditional, it
; also now stands as a guard against `class = lord` ever being
; RE-introduced for this slug by a future lectio regeneration -- the
; overlay would still force the result away from [Lord] (the one subject
; value {!Precedence_ef.band}'s RG 16(a) branch behaviourally reads),
; rather than silently letting a re-introduced bootstrap defect through.
; Removing the directive now would trade a currently-harmless redundancy
; for the loss of that guard.
;
; `Suppress vigil-of-christmas` -- re-verified, not assumed: `[vigil-of-
; christmas]` (24 Dec) is still present, unchanged, in both the
; regenerated INI and the regenerated `data/ef/sanctoral.sexp` (still the
; same duplicate of `rite_ef/temporal_ef.ml`'s own `ef-nativity-vigil`
; this directive was written to remove), so `Layer.mem` still finds it and
; {!Overlay.apply}'s [Suppress] branch still fires its ordinary
; slug-present path (no diagnostic) exactly as before. Nothing about this
; regeneration touched the reason this directive exists; kept unchanged.
;
; `Edit eusebius-confessor` -- NEW (ef-rebootstrap fix round 1, F3): this
; new entry's own bootstrapped colour, `Red`, is a LECTIO DATA DEFECT,
; found by checking the primary scan directly rather than trusting lectio's
; ini or missalemeum's own `:r` colour tag, which agree with each other but
; not with the Missal -- exactly the "two non-primary witnesses agreeing
; against the primary text" trap this project's own transcription-audit
; task already named once. `missale-romanum-1962.pdf`, 14 August, the
; commemoration's own proper: *"Eodem die 14 augusti / S. Eusebii Conf. /
; Commemoratio / Missa Iustus, ut in festo S. Pauli primi Eremitae, die 15
; ianuarii..."* -- "Conf." (Confessor, not Martyr), and the borrowed Mass
; "Iustus" is the SAME Mass 15 January's own St Paul the First Hermit uses
; -- a Confessor, white in both lectio's own data and colitur's
; (`paul-the-first-hermit`, `data/ef/sanctoral.sexp`) -- for the Common of
; Confessors. Corroborated negatively: lectio gives WHITE to every other
; Confessor/Abbot commemoration in its own data (`maur-abbot`, `giles`,
; `remigius`, `didacus`, `ubaldus`, `hilarion`, `sabbas`, `silvester`,
; `alexis`) -- Eusebius Confessor is the one exception, with no textual
; support found for it. No behavioural impact today (`Commemoration_only`
; entries are never the OBSERVED celebration, so this colour is never
; printed by the current pipeline -- but `Record`/rendering will read it
; the moment a template does), fixed for the data's own accuracy via the
; SAME overlay mechanism as the other two directives, since
; `data/ef/sanctoral.sexp` is generated and the source is upstream. Logged
; as a lectio-side generator/data defect in docs/research/rules-register.md
; for a future generator fix, not merely patched here silently.
((id ef-adjustments)
(directives
((Suppress vigil-of-christmas)
(Edit most-holy-name-of-mary ((Set_subject Bvm)))
(Edit eusebius-confessor ((Set_colour White))))))
|