| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The previous commit's bootstrap_sanctoral.ml change (name.pl optional) is
correct and verified not to silently drop a present name, but nothing in
the suite would have caught a regeneration that dropped name.pl WHOLESALE
-- the exact defect lectio itself shipped once (a regeneration that lost
all 322 Polish names, only caught because that project's own review ran
cmd/lectio-ef-dump, which happens to include name fields; this project's
own test_load_and_counts checks entry/status/rank counts only, none of
which move if every name.pl vanishes).
Added a 322-of-327 count assertion (5 legitimately lack it, matching
parse_names's own list), independently re-derived: `grep -c '^name.pl'
tridentine-calendar.ini` = 322, cross-checked against `grep -c '(pl'
data/ef/sanctoral.sexp` = 322 exactly.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
data/ef/sanctoral.sexp bootstraps colour=red for this new entry (14 Aug),
inherited from lectio's own ini; missalemeum's fixture independently tags
it :r too -- two non-primary witnesses agreeing with each other, not with
the Missal, the exact "trap" this project's own transcription-audit task
already named once.
Checked directly against the scan (missale-romanum-1962.pdf), not taken on
a reviewer's transcription: the 14 August proper reads "S. Eusebii Conf. /
Commemoratio / Missa Iustus, ut in festo S. Pauli primi Eremitae, die 15
ianuarii" -- Conf. (Confessor, not Martyr), borrowing the SAME Mass 15
January's own Paul the First Hermit uses, a Confessor's Common, white in
both engines' own data for THAT entry. Every other Confessor/Abbot
commemoration in lectio's own data is white (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
printed observed colour under the current pipeline), fixed via the overlay
mechanism since sanctoral.sexp is generated and the source is upstream.
New test proves it through the real pipeline, the same discipline already
applied to the subject retags.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
13 January retagged subject=Lord (previous commit's regeneration) makes
RG16(a) fire on the 7 years it falls on a Sunday within 2005-2050 (2008,
2013, 2019, 2030, 2036, 2041, 2047): colitur now observes the Baptism of
the Lord itself where it used to observe the generic Sunday slug. The diff
signature against lectio's fixture widens from {season;colour} to
{season;slug;colour} -- but jan_6_13_slug already pre-authorised this exact
slug across the whole 6-13 January window (correctly, for the other 39
non-Sunday years), so layer_c_reason routed the new, wider-shape rows into
C1 unchanged, and C1's own expected_rows (a pure row count) did not move.
A count proving cardinality where identity was required -- on the one day
this branch itself already flags as still wrong under RG 112.
Split into its own entry, C13, matched by an exact 7-date literal list
checked before C1 in the if/elif chain. C1's own expected_rows corrected
368 -> 361 (independently re-derived: a Python script reading
data/ef/sanctoral.sexp's regenerated output and the committed lectio
fixture directly, replicating diff_fields/layer_c_reason's own logic
outside the OCaml comparator -- not transcribed from the failing
comparator's own count).
C13's own citation records a refinement over the coordinator's framing,
checked directly rather than assumed: lectio's committed fixture is a
frozen snapshot that predates lectio's own equivalent fix to this entry's
class field (the same staleness shape as C12). Confirmed by building
lectio's own cmd/lectio-ef-dump from its current source tree (read-only)
and running it fresh for all 7 dates -- lectio's LIVE engine now agrees
with colitur's slug/rank/colour exactly, disagreeing only on season (the
already-understood C1 divergence). This is not evidence colitur's answer
is right against the Missal -- it is not (register's own RG112 item) --
only that this specific divergence from the fixture is a staleness
artifact, not a live disagreement between the two engines' current logic.
Also fixes F5: C12's own note said "5 of the 15 corrected slugs" while
listing and counting 7 -- corrected to 7.
Also corrects the module header's stale "13 January ... slug/rank/colour
already equal lectio's exactly, in all 46 years" claim (true only for the
39 non-Sunday years now).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
are silent
The comment on test_iii_class_feast_wins_class4_feria gave a single reason
for why 8 of the 15 rank-corrected slugs produce zero diff rows anywhere in
the domain: "always fall inside Lent/Passiontide proper, RG 91 entry 22,
which already outranks entry 24". Wrong for 3 of the 8: gabriel-the-
archangel (24 Mar), john-damascene (27 Mar) and john-of-capistrano (28 Mar)
land in Paschaltide 226/846/1108 times domain-wide, always at class-1
(inside the Easter Octave, RG91 entry 2/10), never entry 22.
The conclusion (zero diff rows) was and remains right; only the reason was
wrong -- exactly the "correct code, wrong explanation" defect this project
has repeatedly caught before. Corrected to the actual, checked shield:
every context these 8 dates ever land in domain-wide is either class-1/2
(trivially outranking any class-3 candidate and excluding it from
commemoration by RG111's own rank floors, regardless of status) or the
season's own class-3 feria at entry 22 (which outranks entry 24 for
observation but admits the losing saint's commemoration identically
whether Commemoration_only or Feast, RG111(c)/(d) having no ferial-class
gate on an ordinary sanctoral candidate).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
2008-04-02/04/05 and 2038-03-06/08/09 are the six dates the re-bootstrap's
own brief named as producing a wrong observed office under the old data
(a III-class feast wrongly demoted to Commemoration_only, unable to win
against an ordinary class-4 feria it should trivially outrank). Verified
against the Missal before pinning, per this file's own rule: RG 91 entry 24
("Festa III classis, in calendario Ecclesiae universae inscripta")
outranks entry 28 ("feriae IV classis"), a plain, unqualified table
reading, and the calendarium text for all six was already primary-verified
in the register before this task ran -- only the data was wrong.
Each pin proves the mechanism, not merely the answer: an omitted_has check
(one per season family, Paschaltide and Septuagesima) confirms the
displaced class-4 feria actually reached disposition and was actively
excluded under RG26, not merely absent because nothing was ever offered.
test_easter_extreme_2038_late_modern's own header previously recorded these
three March dates as a DELIBERATE EXCLUSION because they were known wrong;
corrected in place to point at the now-existing pin instead of continuing
to justify an exclusion whose reason no longer holds.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Each was recorded as a genuine data gap "traced upstream into lectio,
unfixable without touching lectio". That constraint is gone: all five
commemorations (St Agnes secundo 28 Jan, St Eusebius Confessor 14 Aug, St
Evaristus 26 Oct, St Theodore 9 Nov, St Boniface Martyr 14 May) are now
present in the re-bootstrapped sanctoral.sexp, and each divergence stops
occurring in the 2026-2027 oracle fixture -- verified by re-running the
comparator and confirming zero rows for all five ids, not assumed from the
data change alone.
Removed rather than kept as dead 0-row citations, matching the M17
precedent already in this file: the count pin
(test_layer_m_counts_match_citations) now enforces that none of these five
divergences can silently reappear. Corresponding dead code (m4_dates
.. m14_dates and their layer_m_reason branches) removed from
test_oracle.ml; a short pointer comment left at each id's old location.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Re-bootstrapping sanctoral.sexp (previous commit) makes 7 of the 15
newly-corrected III-class feasts win an occurrence they previously lost as
Commemoration_only: RG 91 entry 24 (a universal III-class feast) outranks
entry 28 (a IV-class feria), and the occurrence code that resolves this
already existed and needed no change. lectio's own committed differential
fixture (test/fixtures/lectio-ef-2005-2050.txt) is a frozen snapshot
predating lectio's own equivalent generator fix, so it still shows the
class-4 feria observed with the same saint only as a trailing
commemoration -- a new, expected divergence from that fixture, 14 rows in
the 2005-2050 window.
expected_rows (14) is independently re-derived by grepping the regenerated
sanctoral.sexp's own post-regeneration civil-day output against the
committed lectio fixture directly (two flat-file extractions cross-checked
against each other), not transcribed from the comparator's own failing-test
output.
C12 reuses an id last used, and removed, by the RG16(a) task's own reverted
Purification retag -- noted at both the old and new entries' own comments
so the id's history is visible to a future reader.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Neither of adjustments.sexp's two directives is a no-op after the
regeneration, and neither is removed -- reasoned through deliberately
rather than deleted on sight, per Overlay.apply's own documented
diagnostic behaviour (Edit has no "already correct" case; it unconditionally
folds every field_edit over the current value when the slug is present, no
diagnostic either way).
`Edit most-holy-name-of-mary (Set_subject Bvm)`: the base bootstrap no
longer needs this correction (the source dropped `class = lord` for this
slug, so the default is already Subject.Saint), but the overlay still
forces `Saint -> Bvm`. Kept for two reasons: data precision (the
calendarium's "Sanctissimi Nominis Mariae" title still argues for Bvm over
the generic Saint default, independent of what lectio's class field says)
and as a regression guard (Set_subject is unconditional, so it would also
correct a future re-introduction of `class = lord` for this slug, the one
subject value RG16(a) behaviourally reads).
`Suppress vigil-of-christmas`: re-verified, not assumed -- the slug is
still present, unchanged, in both the regenerated source and the
regenerated sanctoral.sexp, so the directive still fires its ordinary
slug-present path.
test_rite_ef.ml's own comment on the overlay-in-effect test previously
claimed the base file carries `subject Lord` for most-holy-name-of-mary,
which the regeneration made false; corrected in place rather than left
stale, per this project's own discipline around wrong claims.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Regenerated via tools/bootstrap_sanctoral.ml against lectio's
tridentine-calendar.ini (SHA-256 6a25e634... -> 1b303ef2...), whose own
generator was independently fixed in a concurrent session. 327 entries (223
feast, 104 commemoration-only), up from 322 (208/114):
- 15 entries wrongly bootstrapped `rank = commemoration` are now
`class-3` (a real III-class Feast) -- all 6 March-5 April, all
primary-source-verified against the calendarium (register's own
"Commemoration-only entries' inferred STATUS" item).
- 5 new entries: agnes-secundo (28 Jan), boniface-martyr (14 May),
eusebius-confessor (14 Aug), evaristus (26 Oct), theodore (9 Nov) --
all Commemoration_only, all primary-source-verified (register's "Four
confirmed sanctoral DATA GAPS" item + expected-divergences-missalemeum
.sexp's former M4/M6/M7/M9/M14).
- commemoration-of-the-baptism-of-the-lord (13 Jan) is now
`(subject Lord)` (the source's own `class` field, not a colitur
overlay); most-holy-name-of-mary (12 Sep) no longer carries `class =
lord` at all (the source dropped it), so the bootstrap default
(Subject.Saint) is now correct there without help from
adjustments.sexp's own Edit.
test_sanctoral_ef.ml's pinned counts (327/104/12 Class1) are re-derived
directly from the source INI (`grep -c '^\['`, `grep '^rank' | sort |
uniq -c`), not transcribed from a bootstrap-tool or `colitur day` run.
data/ef/adjustments.sexp and the differential/oracle allow-lists still
need updating for the consequences of this regeneration -- follow-up
commits.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
All three are the project's own "correct code, wrong explanation" shape,
found by the final review of the RG 113 work. No behaviour change.
test_rite_ef.ml's registered Alcotest label said "Thomas of Villanova
observed, Maurice commemorated" while the test asserts the Ember
Wednesday is observed, Thomas is the sole commemoration and Maurice is
omitted -- the opposite of two of its three assertions. The body's own
doc comment was right; only the name a test run prints was wrong.
validate.ml's lead-in still said origin is reconstructed as Sanctoral
uniformly because the EF admit "reads only rank and slug, never origin".
That stopped being true in ea22ad2: admit now orders by band, and band
reads origin via is_temporal, so a temporal-origin commemoration
relabelled Sanctoral would be scored on the wrong table entry. The code
below already recovers the origin exactly; only this comment lagged.
precedence_ef.ml's band guard justified itself by citing
celebration.mli as saying a demoted feast retains its rank for RG 111's
admission-COUNT purposes. celebration.mli says the opposite -- it names
the ORDERING use the guard removes. The guard is right for a reason it
did not give: rank stays load-bearing through RG 111(b)'s "de festo II
classis" floor, which is what excludes these entries from a II-class
Sunday's slot. Both the citation and celebration.mli's own now-stale
line are corrected, each recording what it previously claimed.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix round 1 on the commemoration-identity/tie-break work: the "genuine
same-band tie" M17 adjudicated as open was not a tie at all. RG 91's
table enumerates only "dies liturgici" (real feasts) -- entry 24's own
text is "Festa III classis, in calendario Ecclesiae universae
inscripta" -- so a Celebration.t.status = Commemoration_only candidate
(a saint reduced to a bare commemoration) has no row in the table to
begin with. Precedence_ef.band used to read rank alone, so it silently
lent such a candidate the same table entry as a genuine Feast of its
own rank; the calendarium's own 22 September row confirms the
distinction in its own notation ("S. Thomae de Villanova ... III
classis. / Commemoratio Ss. Mauritii et Soc. Mm." -- Thomas carries a
class number, Maurice carries none).
Fixed at the source, not by adding a status tier to compare_precedence:
band now checks status first, ahead of every rank-keyed branch, and
returns unclassified for any Commemoration_only candidate. M17 deleted
(not re-adjudicated) -- 22 September now resolves identically on both
sides, with no divergence left to name.
Blast radius measured independently (a temporary git worktree at the
pre-fix commit): 4451 days change across the whole 1583-9999 domain,
exactly 4 verified shapes -- 3576 x maurice-and-companions-martyrs ->
thomas-of-villanova and 282 x eleutherius -> philip-neri (admitted set
changes), 502 x appollonia/cyril-of-alexandria and 91 x dorothy/titus
(order only, independently confirmed against the calendarium's own
listing convention). Zero days change who is observed. Further swept
the whole domain for a genuine "two different candidates on the
identical real table entry" residual -- the shape RG 113 truly gives
no instruction for -- and found it empty: of 109201 same-rank ties
domain-wide, 83950 now resolve by band alone and the remaining 25251
are exclusively two Commemoration_only candidates tied at unclassified,
never two real feasts. The residual admit still breaks alphabetically
is real, but narrower than previously documented.
The "66 days" figure is reconciled, not merely disputed: 599 is the
tie population, 65 (whole-comparator: 67) is the real admitted-set
decision count within it (independently reproduced against the
pre-Task-B binary), 149 is order-only. Every one of the 65 real
decisions traces to the same Commemoration_only/Feast root cause as
Maurice/Thomas.
Also: validate.ml's admission fixed-point check recovers a
commemoration's real origin (by matching its slug against the day's
own temporal office) instead of reconstructing every candidate as
Sanctoral, since band -- unlike EF's own admit -- does read origin;
precedence_ef.ml/.mli's motivating example and blast-radius claims
corrected to no longer rest on the fixed Maurice/Thomas case;
test_identity_rank_corroboration's own population count corrected now
that 22 September (and 21 other Feast-status matches) became reachable;
its rank-agreement pin documents exactly what it does and does not
prove. Register (§4, §6.1, §6 checklist) and CLAUDE.md corrected in
place, including the RG 113 first-sentence gap this exercise surfaced
but did not close, recorded as a new open item.
275 -> 276 tests (with the exhaustive sweep), all green.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
test_oracle.ml (validation layer 4) used to compare commemoration
presence and List.length only -- cardinality, never which candidate is
admitted. A reviewer proved this vacuous by reversing admit's dignity
sort (the engine admitting the worst commemoration, an outright RG 111
violation) and finding every assertion in this file green across all
730 days.
tools/extract_missalemeum_oracle.py now also emits each commemoration's
own missalemeum id (field 9, commemoration_ids), parallel to the
existing title field; fixture regenerated from the same underlying
lectio snapshot (commit d7da4b0, re-verified, first 8 fields
byte-identical), read from a scratch copy so ~/git/projects/lectio was
never touched. SHA-256 pin and provenance updated.
The mapping: colitur identifies a commemoration by slug, missalemeum by
an English title string. No hand-built slug<->title table -- colitur's
own Celebration.t.names already carries the same English text for every
SANCTORAL-origin commemoration (bootstrapped from lectio, verified to
match missalemeum's titles character-for-character). This resolves
identity for every sanctoral-origin commemoration but cannot resolve a
TEMPORAL-origin one (Rite_ef.Temporal_ef never sets a celebration name)
-- that case is a new, distinct outcome (Comm_identity_unresolved),
counted and allow-listed, never silently skipped: 19 of 227
non-empty-commemoration days over 2026-2027.
Two genuine identity mismatches found and adjudicated (new allow-list
entries M15-M17, one is the unresolved bucket): M16, 27 March 2026, the
already-known unimplemented Seven Sorrows of Passion Friday office
(verdict missalemeum); M17, 22 September 2027, the RG 113 same-band
tie-break residual (verdict open, per the sibling admit fix). A new
corroborating check cross-references missalemeum's own id-embedded rank
against colitur's, split by status: Feast-status matches must agree
exactly (none reachable in this 2-year window, checked regardless);
Commemoration_only-status matches either genuinely agree or fit a known,
pre-existing, already-registered convention gap (colitur's bootstrap
rank vs missalemeum's own sentinel) -- not a title-matching defect.
Perturbation test performed and reverted: reversing admit's dignity-
based ordering (compare_precedence's real committed form uses band, not
dignity -- this reproduces the historical defect shape directly) turns
the oracle layer red: "no differences outside the cited allow-list"
fails with an unexplained commemoration-identity-mismatch on 2026-09-23
(colitur admits "St. Thecla" where the rubric and missalemeum both
require "St. Linus"). Reverted; diff against the prior commit confirms
no residue.
CLAUDE.md's "know what each layer cannot see" section updated: the
commemoration-identity gap it documented as open is now closed, with
the mapping's limits and the RG 113 tie-break finding summarised.
271 -> 273 tests (274 with the exhaustive sweep), all green.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
precedence, not slug
Precedence_ef.admit broke a same-rank tie among commemoration candidates
alphabetically by slug -- a deterministic engineering convention with no
rubrical citation. RG 113's own second sentence, primary-source-verified
against two independent scans and previously uncited in the register
(only "commemoratio de Tempore fit primo loco" was quoted before), gives
the real rule: "in admittendis et ordinandis aliis commemorationibus,
servetur ordo tabellae praecedentiae" -- admitting and ordering
commemorations both run on the rite's own table of precedence (band's
28-entry table), not RG 8's coarse four-class rank.
Precedence.resolve now computes each commemoration candidate's own band
value once, generically, and hands it to rules.admit as a third tuple
element (Precedence.rules.admit's signature changed accordingly, ditto
Precedence_ef.admit; every rule-record stub in the test suite updated to
match). Precedence_ef.admit's own compare_dignity is replaced by
compare_precedence, ordering by band then slug; a residual tie within one
identical band value still falls back to slug, since RG 113 gives no
further instruction there -- documented as a still-uncited engineering
convention, not dressed up as a rubric.
RG 98 ("in paritate autem Officium prius impeditum praecedit") was
considered as a candidate authority for that residual and rejected: it
governs the transfer queue order among several simultaneously-impeded
I-class feasts (Caput XIII), a different operation in a different
chapter from RG 113's commemoration admission (Caput XVI); nothing in the
primary text connects the two.
Blast radius measured against the pre-change binary across the entire
1583-9999 domain (not only 2005-2050): the admitted-commemoration-slug
set is byte-identical, day for day, before and after this change. The
fix corrects the citation and mechanism, not the answer, on this
codebase's current data -- both of the task brief's named examples
(22 Feb Chair-of-Peter/Lent-vs-Paul, 22 Sept Maurice-vs-Thomas-of-
Villanova) are confirmed present and unchanged in both streams. A new
test (RG113: admit picks by precedence order, not slug, when they
disagree) proves admit actually consults the passed-in precedence value
with a synthetic pair whose slug order and precedence order disagree --
teeth a same-band-only regression test could not have caught, since
every real collision found in the domain happens to agree on both axes.
271 -> 272 tests, all green; COLITUR_EXHAUSTIVE_SWEEP=1 unaffected.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
data/ef/expected-divergences-missalemeum.sexp's M6 entry and its matching
comment in test/test_oracle.ml both cited 1962-06-23,_SS_Ioannes_XXIII,
_Missale_Romanum,_LT.pdf's 14 August row ("Vigilia, II classis." --
nothing else) as if it were the calendarium itself. It is an electronic
transcription that silently drops commemoration lines the photographic
scans carry. missale-romanum-1962.pdf's 14 August row reads "Vigilia, II
classis, Commemoratio S. Eusebii Conf.", with its own proper following --
independently confirmed in the second scan, Missale Romanum 1962_text.pdf.
M6's verdict flips colitur -> missalemeum: this is a genuine colitur data
gap, the same shape as M4/M7/M9/M14 (absent from data/ef/sanctoral.sexp and
from lectio's own tridentine-calendar.ini), not a spurious oracle entry.
Not fixed here for the same reason those four are not: it requires
touching lectio's own bootstrap source, out of reach for this task.
expected_rows is unchanged (2) -- the diff shape the allow-list predicate
matches does not depend on which side is judged correct, confirmed by the
suite passing unchanged.
A companion register ruling that convicted romanus (9 August) on the
identical reasoning -- and the register's own sanctoral-audit bucket
counts that followed from it -- are corrected in docs/research/
rules-register.md (gitignored, not part of this commit). Full audit
method, the complete list of dropped commemorations found across the
whole calendarium, and every other ruling checked for the same defect
are in .superpowers/sdd/2026-08-12-colitur-rg16a/transcription-audit-
report.md (also gitignored).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix round 1 review, MINOR finding (item 4). Both precedence_ef.ml and
test_precedence_ef.ml claimed the loser-side Class2 conjunct held because
'entry 6's own band value (6) is lower than every entry [3, 11-14]' --
false on its face (6 is not lower than 3) and, worse, the claim proves the
opposite of what it was cited for: if a band-3 candidate really did
contest a Class1 Sunday, the lower number would win, meaning the Sunday
would lose, not beat it as claimed.
The conclusion itself was never wrong, only the justification. Against
entries 11-14 (sanctoral-origin Lord feasts) the numeric argument holds
(6 < 11-14). Against entry 3 (Epiphany, Ascension, Trinity, Corpus
Christi, Sacred Heart, Christ the King) it is not numeric at all but
structural: every band-3 celebration is temporal-origin, and
Precedence.resolve takes exactly one temporal candidate per day, so a
band-3 Lord feast IS that date's own single temporal candidate, never a
second one contesting a separately-produced Sunday -- there is no band
comparison to make in the first place. Comment-only; no behaviour change.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
day's own Sunday-ness, not observed
Fix round 1 review, two findings landed together because each golden pin's
correctness depends on both.
CRITICAL (item 1): reverts this branch's own first-pass retag of the
Purification (2 February) from Lord back to Bvm -> Lord. The calendarium
titles it 'B. Mariae Virg.', but missalemeum -- this project's designated
EF oracle -- treats it as taking an occurring II-class Sunday's place
outright, commemorations empty, exactly RG16(a)'s own festum Domini
treatment (2020-02-02, 2014-02-02, independently fetched). Control,
2019-09-08 (the Nativity of the BVM, an ordinary Marian feast, on a
Sunday): the Sunday observed, the feast merely commemorated -- the
opposite pattern, proving the Purification's own oracle treatment is
deliberate, not a gap. RG16(a) alone, on the untouched data, would have
matched the oracle character for character; retagging Bvm is what moved
colitur away from it on 1200 domain-wide days. The user has ruled: follow
the oracle. Genuine primary-text counter-evidence (RG120(b), the colour
rule grouping 2 February under 'B. Mariae Virg.', a category separate
from 'Domini') is recorded in the register, not discarded -- a different
project could reasonably rule the other way on the same evidence.
most-holy-name-of-mary stays retagged Bvm; that one was never disputed.
Removes the now-unneeded C12 lectio allow-list entry (data/ef/
expected-divergences.sexp, test_differential.ml): with the Purification
Lord again, colitur matches lectio's own class = lord on every affected
date, no divergence to allow-list.
IMPORTANT (item 2): Precedence.rules.admit gains a ~temporal parameter --
a genuine kernel signature change, unlike RG16(a) itself. RG111(b)'s own
Sunday rank floor ('one commemoration, namely of a II-class feast') used
to be detected by reading observed's own slug for a Sunday marker, which
silently assumed observed IS the day's temporal-cycle office. RG16(a)
breaks that assumption on purpose: a Feast of the Lord standing in for an
impeded Sunday 'cum omnibus iuribus et privilegiis' keeps the day a
dominica II classis for RG111(b) too, even though the FEAST, not the
Sunday, is observed. Before this fix an unrelated saint (Pope Sixtus II
et al., 6 August, Class3) was wrongly admitted into the freed slot on
every one of 1178 domain-wide days. Oracle-confirmed directly: 2023-08-06
(a Sunday) shows him displaced, commemorations empty; 2026-08-06 (an
ordinary Thursday) shows him admitted -- being a Sunday is exactly what
excludes him. admit now reads Sunday-ness off ~temporal (the day's own
temporal-cycle candidate, passed through from Precedence.resolve
unchanged) instead of observed. Validate's own admission fixed-point
invariant updated to pass the same real temporal candidate through.
Both golden pins in test_golden.ml were promoted from actual colitur day
output without independently consulting the rubric or the oracle first --
a real defect the review caught. Re-derived from both before re-pinning:
2028-08-06 and 2025-02-02 now pin comms=[], no commemoration at all,
matching missalemeum exactly in both cases.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Two real dates, hand-verified against the rubric before pinning
(test_golden.ml's own discipline): 2028-08-06, the Transfiguration
suppressing an ordinary Sunday's commemoration entirely (with an
unrelated III-class saint the same fixed date, Pope Sixtus II et al.,
still getting its own ordinary commemoration -- proof the rule targets
the Sunday specifically, not every commemoration due that day); and
2025-02-02, the corrected Purification -- the Sunday observed, the
Purification surviving as an ordinary commemoration, the exact opposite
of what RG16(a) would have done to it before the data fix.
Re-ran the exhaustive sweep (COLITUR_EXHAUSTIVE_SWEEP=1 dune test
--force): 1583-9999, 0 failures, including the resolution invariants
that now see RG16(a)'s changed commemoration accounting.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Both entries carried (subject Lord) in data/ef/sanctoral.sexp, inherited
unchecked from lectio's own class = lord field. The calendarium says
otherwise: 2 February reads "IN PURIFICATIONE B. MARIAE VIRG." and
12 September reads "Sanctissimi Nominis Mariae" -- both name Mary, not
the Lord, unlike the four genuine Lord entries' own "D. N. I. C."
formula (Precious Blood, Transfiguration, Exaltation of the Holy Cross,
Dedication of the Archbasilica of the Most Holy Saviour), all of which
were checked against the same calendarium and left untouched.
This matters together with RG16(a): applying the rule while the
Purification was still mistagged Lord would have made it outrank an
occurring II-class Sunday and then wrongly suppress that Sunday's own
commemoration under RG16(a) too, the opposite of the intended fix.
Retagged, the Purification no longer bands at RG91 entry 14, so the
Sunday is observed and the Purification survives as its own ordinary
commemoration.
Corrected via a new data/ef/adjustments.sexp overlay (Set_subject Bvm),
the same mechanism that file already uses to suppress vigil-of-christmas
as a bootstrap duplicate, not a hand-edit of sanctoral.sexp itself: that
file's own header asks for edits to go through the generator, and its
SHA-256 provenance covers a byte-faithful mirror of lectio's INI. The
Purification retag changes which day the lectio differential observes on
2 February whenever it falls on a Sunday (six years, 2005-2050); allow-
listed as C12 in data/ef/expected-divergences.sexp, expected_rows derived
independently (date -d <year>-02-02 for each year in range), not
transcribed from a comparator run.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Sunday uncommemorated
Caput III "De Dominicis", RG 16(a): a Feast of the Lord, I or II class,
occurring on a II-class Sunday takes the Sunday's own place with all its
rights and privileges -- of the Sunday, therefore, no commemoration is
made. band's entry 14 already ranked such a feast above the Sunday
correctly; disposition had no exception for the collision, so the impeded
Sunday fell through to the ordinary RG 95/109(a) commemorate-or-omit
catch-all and was wrongly admitted as a privileged commemoration.
Adds a branch to Rite_ef.Precedence_ef.disposition, gated on all four of:
loser is temporal-origin, loser rank Class2, loser carries the Sunday slug
marker, winner rank Class1-or-2 with subject Lord. No signature change --
disposition already receives the winner (RG 33's own vigil-omission branch
already reads it); each conjunct is proved independently load-bearing by
a dedicated disposition_cases row, including one real-data case each for
the winner's subject and rank conjuncts, and a defensive synthetic case
for the winner rank conjunct's currently-unreachable Class3 shape. A new
end-to-end resolve-level test (2028-08-06, the Transfiguration) proves the
real band/disposition pipeline together, checking the Omit reason string
distinguishes this from admit's own admission-limit cut.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Six independent, small corrections found during the final review:
- dune (workspace root): the comment said the stanza used "(:standard)"
to preserve dune's default `default` alias target; the stanza actually
spells that out explicitly via (alias_rec install). Comment now matches
the code.
- test_validate.ml's test_easter_extremes asserted `List.length ys = 2`
where an identity check was called for -- the comment already named
1598 and 1666, but nothing confirmed extreme_years() found THOSE two
rather than some other pair with the right cardinality. Now asserts the
identities directly (the project's "cardinality where identity was
required" vacuity flavour, per the review).
- test_oracle.ml and expected-divergences-missalemeum.sexp both claimed
"one entry (M13) is [verdict open]" -- M11 is open too (its own verdict
changed from colitur to open in fix round 1); both now say "two entries
(M11 and M13)".
- expected-divergences-missalemeum.sexp's M2 note attributed `band` to
temporal_ef.ml; `band` is precedence_ef.ml's own function.
- lib/kernel/precedence.mli documented `dropped`/`admit`'s physical-
equality obligation nowhere -- it lived only in one rite's own module
(Rite_ef.Precedence_ef.admit's doc comment), but this signature is what
an author of the next rite actually reads. Added the obligation here,
cross-referencing the EF instance as precedent, not the only source.
- README's opam install line omitted sexplib and ppx_sexp_conv (both in
dune-project's own depends; `dune build` fails without them for a
contributor following the README verbatim) and documented only
`colitur easter`, though `temporal` and `day` both exist and are the
more useful entry points. Fixed both.
No behaviour change: comment/doc/test-assertion corrections only (the
easter-extremes fix strengthens an assertion, it does not change what
passes). Verified byte-identical `colitur day` output across 1583, 1900,
1902, 2008, 2011, 2026, 2038, 9999. 259/259 tests green.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
test_validate.ml's own prop_invariants samples 200 of 8 416 years
(2.4% of the domain) on a random seed -- QCheck.Test.make draws a fresh
one from the environment each run when none is given, and two consecutive
runs of this suite were observed using different seeds. CLAUDE.md's
standing claim that Validate is "clean across all 8 416 years --
exhaustive, not sampled" was true whenever it was last actually re-run in
full, but pinned by no committed artifact, and a year-specific regression
would show up in this suite only intermittently.
Added test_exhaustive_domain_sweep: every year 1583..9999 through
Validate.run, not a sample, with 9999 handled via the same documented
truncation test_year_9999_does_not_raise already pins (the domain ceiling
means the season-run check legitimately, and only, fires there).
Tagged `Slow, but NOT wired through Alcotest's -q/--quick-tests flag at
the dune level: that filtering is all-or-nothing per speed level, and
this codebase already tags six OTHER cases `Slow -- the two pre-existing
exhaustive Computus checks (fast, sub-second) and, found while
implementing this item, every QCheck property in the suite (test_date.ml
x3, test_overlay.ml, test_temporal_ef.ml, prop_invariants itself), since
QCheck_alcotest.to_alcotest defaults ~speed_level to `Slow when not given
explicitly and no call site in this codebase overrides it. Wiring
`(action (run %{test} -q))` into test/dune was tried and reverted: it
dropped the default `dune test`'s reported count from 260 to 251,
silently excluding prop_invariants itself -- the project's own
"confidence-to-9999" property -- along with five others, a far bigger
regression than the one test this item asks to add.
Instead the new test gates its own body on an environment variable,
COLITUR_EXHAUSTIVE_SWEEP, and calls Alcotest.skip when unset -- reported
honestly as SKIP, not a vacuous pass, and not counted toward "tests run".
Default `dune test` is therefore unaffected (259 tests run, same as
before this commit, 1 skipped) and stays at ~2.6s. Run the real sweep
with:
COLITUR_EXHAUSTIVE_SWEEP=1 dune test --force
Measured runtime: ~49-53s (three separate invocations, including dune's
own build/dependency-check overhead), against the ~35-45s estimate --
same order of magnitude, reported as measured rather than adjusted to
match the estimate.
No behaviour change to any existing test. Verified byte-identical
`colitur day` output across 1583, 1900, 1902, 2008, 2011, 2026, 2038,
9999, both with and without COLITUR_EXHAUSTIVE_SWEEP set.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
68 "register line N" pointers in tracked code and data cited the
register's line numbers directly. The register has moved since: line 334
(cited six times as RG 91 entry 8) is now rose/colour prose; lines
375-376 (cited as "RG 109 leaves Advent/Lent Ember ordinary") are now
RG 26, the paragraph that refutes that exact reading; line 374 (cited as
RG 109(a)) is now RG 25's Latin; line 378 (RG 111) is blank.
expected-divergences.sexp even wrote "RG 91 line 332" three times, as
though the line offset were part of the rubric's own identity. Since
docs/research/rules-register.md is gitignored, no reader of the public
repo could resolve any of these, and -- since the register has moved on
its own copy too -- neither can the author's.
Replaced every pointer with an anchor that survives editing: the RG
paragraph/entry number itself (already present in nearly every case,
since the citation text already names "RG 91 entry N" or "RG 109(a)"
next to the stale line number -- the line number was redundant, not
load-bearing) plus a "§4" or quoted-subsection-heading pointer into the
register for readers who want to locate the fuller discussion. Also
corrected one genuinely stale content error found while migrating its
anchor: test_precedence_ef.ml's RG33 disposition-cases comment still said
"a I/II-class vigil impeded by any Sunday" -- the pre-Task-16
mistranscription the register itself corrects to II/III class; fixed the
prose alongside its citation, since leaving a wrong RG-class claim next
to a freshly-verified anchor would be worse than the stale line number it
replaced.
Covers lib/rites/rite_ef/precedence_ef.ml (18), precedence_ef.mli
(already fixed with item 1), test/test_precedence_ef.ml (44, including
two instances that only word-wrapped "register\nline N" across a line
break and so did not match a same-line grep), and
data/ef/expected-divergences.sexp (5, including three "RG 91 line 332"
instances). All 68 original pointers resolved -- none needed guessing;
every citation's target rule was already named in the surrounding prose.
No behaviour change: every edit is a comment/citation/data-note change.
Verified byte-identical `colitur day` output across 1583, 1900, 1902,
2008, 2011, 2026, 2038, 9999. 259/259 tests green.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The guard added under Plan 2's carried item 5 only scanned a +/-window of
dates around Easter, so it caught erosion of an Easter-relative anchor but
missed a fixed-date one entirely: deleting ("ef-nativity", ...),
("ef-epiphany", ...) or ("ef-christ-the-king", ...) from temporal_ef.ml's
anchors list left the whole suite green. Item 5 -- the item this guard
exists to satisfy -- was therefore only half-closed while being reported
as closed, and the least-covered anchor was exactly the one with the
weakest citation (Christ the King's last-Sunday-of-October placement,
oracle-backed but not yet primary-verified as of this commit).
Widened the scan from an Easter-centred window to the whole civil year:
named only ever answers Some for its ~20 genuinely proper/named days, so
scanning every day of the year is no more likely to pick up an ordinary
week's slug by accident than the narrower window was -- it is simply no
longer selective about which KIND of named day it notices. Renamed
easter_relative_named_slugs to named_slugs_for_year and the covering test
to test_anchors_cover_all_named_days accordingly; broadened the negative
fixture (test_anchors_erosion_is_caught) to strike an Easter-relative and
a fixed-date anchor together.
Verified by deleting each of the three previously-unguarded anchors in
turn (locally, reverted after each), rebuilding and re-running the suite:
delete ef-nativity: Received: `["ef-nativity"]'
delete ef-epiphany: Received: `["ef-epiphany"]'
delete ef-christ-the-king: Received: `["ef-christ-the-king"]'
each against the same assertion:
ASSERT 1598: every named slug is restated in anchors
FAIL 1598: every named slug is restated in anchors
Expected: `[]'
All three reversions applied only to temporal_ef.ml (not committed); the
tree is unchanged there. Test count unchanged (259); no behaviour change.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
guard claim
Item 2(a): the RG 26 omission gate (rank = Class4) is extensionally
identical, over every candidate this engine actually constructs, to the
refuted "privilege_of loser = Ordinary" predicate it replaced -- confirmed
by enumerating the whole candidate space over 1583-9999, substituting the
old predicate back leaves 257/257 green and byte-identical output. Adds a
synthetic row: a temporal-origin, Ordinary-privilege Class3 loser, which
the two gates disagree on (RG26: Commemorate; the refuted gate: Omit,
since it never looked at rank). Reverting the gate to the old predicate
turns exactly this row red:
Expected: "Commemorate(Ordinary)"
Received: "Omit"
Item 2(b): the existing "RG33 boundary" row's comment claimed it proved
the RG26 branch's own (not (is_vigil ...)) guard. It does not: the vigil
sourced there is Class2, already excluded by the branch's rank = Class4
test alone, with or without the vigil guard -- verified by deleting the
guard, which leaves 257/257 green. Corrected the comment to say what the
row actually shows (RG31's "if impeded, commemorated" vigil mandate, a
real and separate fact worth keeping) and added a genuinely discriminating
synthetic row: a temporal-origin Class4 loser whose slug is ALSO
vigil-shaped, a combination RG 91 does not describe but Precedence.resolve
can still be asked to construct. Deleting the guard turns this row red:
Expected: "Commemorate(Ordinary)"
Received: "Omit"
Both reversions were applied locally to precedence_ef.ml, confirmed, and
reverted; the committed .ml is unchanged. Test count 257 -> 259, both new
rows green under the current, correct code.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Validation layer 5: fourteen hand-verified pins in test/test_golden.ml,
wired into the suite via test/test_colitur.ml. Each pinned day was computed
and checked against its RG citation before being written down, never
transcribed from `colitur day` output:
- Easter extremes 1598 (earliest, 22 Mar), 1666 (latest, 25 Apr) and 2038
(late-modern instance of the same latest date) -- all three independently
computed by hand via the Gauss/Meeus Gregorian Easter algorithm, not read
off Computus.gregorian_easter. extreme_years in test_validate.ml already
established 1598/1666 as the true 1583-2500 extremes (correcting a stale
1818/2038 comment); this file pins the resolved DAY there, not just the
date.
- Annunciation transfer, 25 March inside Holy Week (2016: 25 March is
literally Good Friday) and the double transfer with St Joseph (2008:
RG96's Attamen(a) claims Easter+8 for the Annunciation first, Joseph's
own RG96 walk continues past it to the next day).
- The RG96 Attamen(a) exception's own CONDITION pinned on both sides: 2057,
2007, 2012 (general walk suffices, lands before Easter, no exception) vs
2016/2024 (walk would cross Easter, Easter+8 fires).
- 2011-07-04, the Precious Blood transfer (Sacred Heart outranks it
outright on 1 July; the RG96 walk skips Visitation and a Sunday before
landing on 4 July).
- All Souls falling on a Sunday (2025, RG96 Attamen(b)) and Christmas
falling on a Sunday (2022, RG91 entry 1 -- no contest, since 25 December
is never an ordinary Sunday candidate in the EF temporal cycle).
- Holy Thursday's white amid violet Passiontide (2026, RG128(b)/RG122) --
the case colitur and lectio previously agreed was violet, so the
differential could never have caught it; only a golden pin or the
missalemeum oracle can.
- Advent/Lent Ember ferias commemorated when impeded (1900, 1902, RG24 +
RG109(e)) contrasted with IV-class ferias never commemorated (2026,
RG26) and RG111(b)'s Sunday rank floor (2009, 2026) -- all three assert
the actual displaced/excluded candidate is present in `omitted`, not just
that `commemorations` is empty, so a day with no losing candidate at all
could not pass vacuously.
2038 is deliberately NOT pinned day-by-day: register item F4 confirms
2038-03-06/08/09 are wrong (a lectio bootstrap-generator defect, not
fixable here). Only the Easter-week days, untouched by that bug, are
pinned; the exclusion is stated in the test's own comment, not silent.
Every weekday asserted was independently cross-checked against `date -d
<iso> +%A` (glibc, wholly outside this codebase) before being written down.
Precedence outcomes were traced against precedence_ef.ml's own band/
disposition/admit/transfer_target, not merely observed to look plausible;
where the primary text alone doesn't fully settle an outcome (the 2008
Annunciation/Joseph tie-break, both landing at RG91 table entry 11), the
test's own comment says so rather than overclaiming a citation.
Perturbation-tested: temporarily broke Holy Thursday's white-colour special
case in temporal_ef.ml, confirmed the golden test failed with a clear
day-and-field diff, reverted.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
M11 (the Nativity Octave's 26/27/28 December commemoration) previously
read "No RG paragraph found to support this" with verdict colitur.
Wrong on both counts, found by fix-round-1 review.
RG 67 ("dies infra octavam sunt II classis") and RG 109(c) ("de
diebus infra octavam Nativitatis Domini") both name this
commemoration; the 1962 calendarium's own text confirms it directly,
verbatim, under all three dates: "S. STEPHANI PROTOMARTYRIS, II
classis. / Com. octavae Nativitatis." (same pattern for John the
Evangelist and the Holy Innocents).
It is also a genuine regression the previous commit's own
commemoration-eligibility fix introduced: before that fix, colitur
happened to commemorate the day's generic Christmastide loser
unconditionally, which coincidentally kept presence agreeing with the
oracle even though the reasoning was wrong; the fix correctly stopped
that, but 26-28 December's own temporal candidate falls through to
[ferial_rank]'s Christmastide catch-all, which gives it Class4 -- the
wrong ferial rank for a day RG 67 says is II class. A naive fix would
also get RG 69 backwards: when this window falls on a Sunday, RG 69
names the SUNDAY as observed with a commemoration of THE FEAST ITSELF
(Stephen/John/the Innocents), never the generic octave placeholder --
so this needs a commemoration that attaches to whichever named feast
is observed, not one more competing RG 92-95 candidate the way
everything else in this engine is modelled. Out of this fix round's
own scope.
Verdict changed from colitur to open: neither side is confidently
right without that fix, and the previous "colitur is correct, nothing
to implement" framing was itself the risk under review.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
RG109
Review round 1 (F1, Critical): the commemoration-eligibility fix from
the previous commit silently dropped II-class Advent and Lent Ember
ferias when impeded, while ordinary (lower-solemnity) ferias of the
same seasons kept their commemoration -- backwards on any reading.
Reproduced: 1900-12-21 (an Advent Ember Friday) lost its commemoration
entirely; 2026-12-21 (an ordinary Advent feria the same week) kept
its.
F2 (Important, the direct cause of F1): the branch's own justification
mis-stated RG 109 as an exhaustive list of the only temporal
circumstances that generate a commemoration. RG 109 is headed
"Commemorationes privilegiatae sunt commemorationes" and closes
"Omnes aliae commemorationes sunt commemorationes ordinariae" -- it
sorts commemorations that already exist into two HONOUR classes
(RG 108's differing liturgical hours), and says nothing about which
offices have the right to be commemorated at all. That right belongs
to Caput IV, "De feriis" (RG 21-27), never opened by the original
pass:
RG 24 (II-class ferias): "si vero impediuntur, commemorari debent"
-- if impeded, MUST be commemorated. Not optional.
RG 25 (III-class ferias): same mandate.
RG 26: every feria not named in 23-25 is IV class, and IV-class
ferias are NEVER commemorated -- the one exclusion RG 21-27 actually
states.
The omission branch is now gated on `rank = Class4` (RG 26) directly,
not on `privilege_of = Ordinary` -- the old gate happened to reach the
right answer for IV-class ferias (RG 26 also excludes them, for a
reason the old citation did not give) and the wrong one for II/III-
class Ember ferias RG 109(e) did not name by letter.
RG 109(e) itself is also corrected: its bare "feriis Adventus,
Quadragesimae et Passionis" previously excluded the Advent and Lent
Ember sub-days by analogy with (d)'s separate September carve-out.
RG 91's own TABLE needs an explicit "exceptis feriis Quatuor
Temporum" at entries 22 and 25 to keep Ember days from being double-
listed against their own entry 18 -- an exception that would be
unnecessary drafting if "feriae Adventus"/"feriae Quadragesimae" did
not already include their Ember sub-days by default. RG 109(e) carries
no such exception, so it is read at that same default, inclusive
scope: the Advent and Lent Ember ferias are privileged under (e), not
merely ordinary-but-commemorable. (d)'s own existence is unaffected --
September Ember days sit outside Advent/Lent/Passiontide under any
reading, so (d) remains necessary regardless.
Verified: 1900-12-21 and 1902-02-22 now correctly commemorate their
Ember ferias; 2026-12-21 and 1902-02-24 (ordinary ferias) unchanged.
Blast radius re-measured against the prior commit, 1900-2100: 102
civil days changed, every one an Advent/Lent Ember (or Ember-vs-
Joseph-collision) day regaining its commemoration, nothing else.
Validate re-swept exhaustively, 1583-9998: 0 failures.
F6: two privilege-boundary test rows that had been bent to expect the
bug's own output (Commemorate -> Omit) are restored to what RG 24/25
actually require, now Commemorate(Privileged) given the RG 109(e)
correction above -- these are the rows that should have caught F1.
F7: admit_cases had no witness for RG 111(b)'s rank floor that wasn't
already Class2, so reverting that filter only reddened the oracle
suite, never this file. Added a row (II-class Sunday, sole candidate
an ordinary Class3) that fails without the filter and passes with it.
F9: RG 122 cited alongside RG 128(b) for Holy Thursday's white --
states the same fact affirmatively ("Demum adhibetur color albus,
feria V Hebdomadae sanctae...") rather than as an exception to violet.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Validation layer 4: an oracle harness against missalemeum (Divinum
Officium data), independent of the lectio bootstrap chain colitur's
own sanctoral data comes from -- the only layer that can catch an
error inherited from that bootstrap, and the only one that can
validate commemorations at all (the lectio differential explicitly
excludes them, per its own header comment).
tools/extract_missalemeum_oracle.py shapes the fixture from lectio's
sources/snapshot.tar.gz outside the test (no JSON library in this
project's frozen deps, same reasoning test_differential.ml's own
fixture already documents). test/fixtures/missalemeum-ef-2026-2027
.txt (730 days, SHA-256 pinned and asserted) + its own .provenance
note record exactly how to regenerate it.
test_oracle.ml compares three axes the oracle actually supports:
rank, colour (SET MEMBERSHIP -- 14 of 730 days carry two colours,
e.g. rose+violet on Gaudete/Laetare, which independently vindicates
this project's own rose reading against lectio's violet-only one,
recorded in the register), and commemoration presence/count. Slug
identity is deliberately out of scope (needs a title->slug mapping,
the data audit's own business, not the automated comparator's).
Of 730 days, 688 matched cleanly outright. The remaining 42 are all
named in data/ef/expected-divergences-missalemeum.sexp (14 cited
entries, M1-M14): most are genuine primary-source-confirmed findings
this task adjudicated and fixed in the two preceding commits (RG 33,
RG 109/111, Holy Thursday's colour); the rest are real, cited,
deferred feature/data gaps (RG 91 entry 27's BVM-Saturday office, RG
110's inseparable Peter/Paul commemoration, four sanctoral entries
missing from lectio's own source) or genuine oracle-side artifacts
-- honestly verdicted against whichever side this task's own
primary-source research actually backs, never defaulted to colitur.
One entry (M13, St Joseph vs the Friday of Passion Week 2027) is
verdict open: adjudicated as unresolved after real search effort,
not guessed past.
The data audit: every sanctoral entry the comparison flagged was
hand-checked against the 1962 calendarium, plus a 20-entry
deterministic random control sample (seed 20260812) drawn
independently of the flagged set. The control sample caught two
entries (benedict, frances-rome) marked Commemoration_only in the
bootstrapped data when the primary calendarium lists them as plain
III-class feasts with their own Office -- traced to lectio's own
source, not fixable here, and reported as a signal (10% of a random
sample) rather than a blanket claim. Coverage recorded honestly in
docs/research/rules-register.md's own three buckets: confirmed by
oracle (200/322), confirmed by hand (23/322, 2 of them wrong),
unverified (115/322) -- the unverified bucket stated explicitly
rather than left implicit.
Harness teeth demonstrated and reverted (not committed): a fixture
rank/colour edit on a previously-clean day fails both the checksum
pin and the no-unexplained-differences assertion independently; an
expected_rows drift on the allow-list fails the citation-count
assertion. Both captured with their exact failure messages, both
reverted before this commit.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
RG 128(b) excepts "Missa sive Chrismatis sive in Cena Domini feria V
Hebdomadae sanctae" from the Septuagesima-to-Easter-Vigil violet span
as a whole-Mass exception (unlike Palm Sunday's blessing/procession,
which the same sentence carves out as only part of that day) -- so
Holy Thursday's Mass is white, not violet. temporal_ef.ml fell through
to the generic Passiontide ferial path (season_colour Passiontide =
violet) for this date, since [named] has no entry for the Triduum at
all (rank was already correct via [privileged_feria]; only colour was
wrong).
Found via Task 16's missalemeum oracle comparison: every other Triduum
day's oracle colour set includes violet as an option (Good Friday
"bv", Holy Saturday "vw" -- already-flagged, deliberately deferred
per-action gaps, register §3b), but Holy Thursday's is white alone.
This is a genuine NEW divergence from lectio too (lectio has no such
exception and still prints violet for Holy Thursday) -- added as
Layer C11 to the differential harness and data/ef/expected-divergences
.sexp, 46 rows (2005-2050), rather than silently changing what that
harness accepts.
Also corrected a stale comment on season_colour claiming white's RG
paragraph was never pinned -- RG 119 was found and cited in the
register on 2026-08-11 but the correction was never copied into this
file's own comment.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Task 16's missalemeum oracle comparison (2026-2027) surfaced three
distinct precedence-engine bugs, each confirmed against the primary
1962 Missale Romanum text and cross-checked against the oracle:
1. RG 33 (vigil omission) was transcribed backwards. The primary text
reads "Vigilia II AUT III classis penitus omittitur" (a II OR III
class vigil is entirely omitted on any Sunday or I-class feast) --
not "I aut II" as the register and this module's own rank check
(Class1 || Class2) previously had it. I-class vigils (Nativity,
Pentecost) can never actually lose in this engine (band always
ranks them above anything that could coincide with their dates), so
the Class1 half was dead code; the real bug was that Class3 (St
Lawrence's vigil, the sole III-class vigil) was MISSING, so it fell
through to an ordinary commemoration instead of RG 33's mandatory
omission whenever 9 August landed on a Sunday.
2. RG 93/95/109/113 read together: an ordinary, non-privileged
TEMPORAL-cycle office (a bog-standard green-season feria, a plain
Advent/Lent Ember day, a Minor Rogation day) has no standing to be
commemorated at all when impeded -- RG 109's six-item list is a
CLOSED set of the only temporal circumstances that generate a
commemoration, not a floor under which anything ordinary still
gets one. The engine previously commemorated the losing feria
itself in this situation; confirmed wrong against ~190 independent
missalemeum days (2026-2027) showing zero commemorations for the
exact shape. Vigils are explicitly excluded from this new rule --
RG 31/32 give them their own "if impeded, commemorated" mandate,
independent of RG 109's list.
3. RG 111(b)'s Sunday admission slot is restricted to "de festo II
classis" -- a rank restriction, not merely the best available
ordinary candidate. A III/IV-class ordinary saint competing for a
II-class Sunday's single commemoration slot had no such restriction
applied before; confirmed wrong via St Hyginus (11 Jan, Class3)
losing to Holy Family, which missalemeum shows entirely displaced,
never commemorated.
All three fixes are pure disposition/admission changes -- they never
touch band, so the observed day (season/slug/rank/colour) is
unaffected in every case; the lectio differential (which never
compares commemorations) stays green untouched. test_precedence_ef.ml
updated throughout: two previously-wrong test expectations corrected
(the RG33 III-class-vigil boundary row, the IV-class-feria totality
row), three privilege boundary rows sharpened from "commemorated but
unprivileged" to "omitted entirely" now that temporal+ordinary
means omission, and a new contrast row added to keep the SANCTORAL
side of rule 2 covered separately from the TEMPORAL side.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix round 1 on Task 15's review, four findings closed.
C1 and C6 previously gated on calendar date alone -- unlike every other
Layer C entry, which also checks the actual colitur slug that won. A
future sanctoral change producing an unrelated celebration with the same
diff shape (e.g. a promoted 29-31 December saint landing on C6's own
[Slug_f; Rank]) would have been silently absorbed under a citation that
has nothing to do with the real cause. Both entries now require, whenever
Slug_f is in the diff set, that colitur's own slug be a member of an
explicit closed list (jan_6_13_slug, nativity_octave_day_slugs) -- the
same style advent_feria_slug already used for C4. Constructed the exact
substitution via a temporary (unshipped) overlay Replace directive
promoting thomas-becket to Class1 Feast White; confirmed the tightened
predicate refuses to absorb it (46 unexplained rows, one per year); reverted.
C10 gained the diff-field-subset restriction every other entry already
had (it previously fired on the two pinned dates regardless of which
fields differed).
Fixed a stale doc comment ("SIX" columns; field has five constructors).
The fixture's provenance note now records its SHA-256, and the suite
asserts it as its own first test case (test_fixture_checksum), so a
hand-edited or partially re-copied fixture fails loudly instead of
silently becoming an unlabelled snapshot. Computed via the system
sha256sum binary through Sys.command plus a redirected-output temp file
-- no new library dependency, not even unix. Constructed a one-byte
fixture edit and confirmed the checksum test fails independently of the
row-comparison test; reverted.
237/237 tests green, clean-build verified.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Validation layer 3 (design spec's five): compares colitur's real day-by-day
EF output against lectio (sibling project, Go), 2005-2050, one line per
civil day. Of 16801 day-pairs, 11206 already agree on the seven leading
columns; the 5595 that don't resolve into exactly 25 distinct field-diff
signatures, all triaged.
Three strictly separate layers, per the controller's ruling (the brief's
single flat allow-list assumed a handful of differences, not 5595):
- Layer A (test_differential.ml, norm_season/norm_slug): vocabulary. An
explicit, closed table of naming synonyms with no liturgical substance
(lectio's easter/christmas vs colitur's paschaltide/christmastide; a
handful of slugs that are two names for the identical office). No
wildcards -- every entry is a literal string pair.
- Layer B (strip_epiphany_index): numbering. The one slug family whose
lectio/colitur index offset is not a constant (Time-after-Epiphany week
numbering, register 3c#5) has its embedded digit stripped to a common
form on both sides before comparing; rank and colour stay fully compared.
- Layer C (data/ef/expected-divergences.sexp): the cited allow-list. Ten
genuine liturgical disagreements, each citing its RG paragraph and
naming which engine is right (always colitur, verified against the
Missal/register, never against lectio's own behaviour). This is the
only layer permitted to cover a difference in rank, colour, or which
celebration is observed. Five extend or restate register 3c's already-
documented divergences (season boundary, Sunday I-class, Advent Ember
ferias, Rogations); five are new, found and adjudicated in this task
(Lent Ember days, the Nativity Octave, Ember-day-vs-saint precedence,
the St Joseph transfer off a Lent Sunday, and the 2011 Sacred Heart /
Precious Blood / Visitation collision). expected_rows on each entry is
an exact regression pin, asserted by the test, not documentation.
13 January (register 6's long-open "Baptism of the Lord" item) is
confirmed empirically fixed already -- Task 11's sanctoral wiring closed
it before this task started -- so it is not allow-listed; the only
residual difference there is the season boundary already covered by C1.
Two stated limits carried from the brief (commemorations are not
comparable; lectio's own EF oracle asserts season only, 2025-2026 only,
so a rank/colour difference is not presumptive evidence against colitur)
plus a third found during this task (the week column is a display
convention on both sides, not a liturgical fact, and is not compared at
all) are documented in the test file's own doc comment.
Fixture: test/fixtures/lectio-ef-2005-2050.txt, committed as plain text
(1.4 MB), generated by lectio commit 2386a45; provenance recorded in the
sibling .provenance file. Colitur's side is recomputed fresh from the
library on every run, through the same Calendar/Rite_ef pipeline
`colitur day` uses, not the compiled binary.
Proved the harness has teeth by two reverted perturbations: a genuine
colour difference injected into a fully-covered fixture row fails the
"no unexplained differences" check with the exact mismatched row printed;
a one-row drift in an allow-list entry's expected_rows fails the count
check independently, showing it is not merely a duplicate of the first
assertion. 236/236 tests green, clean-build verified, deterministic
across OCAMLRUNPARAM=R.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Three carried items from Plan 2's parked rulings, closed:
1. Slug uniqueness moves from a 200-sample QCheck property scoped to
one rite (test_temporal_ef.ml) into Validate's own "slugs" check, so
every consumer gets it. The resumed-Sunday exemption that property
carried is dropped, not weakened elsewhere: Plan 2 verified zero
duplicate slugs domain-wide (all 8 416 years), and by construction a
resumed Sunday only ever backfills a week number Septuagesima cut
short that same liturgical year, so it can never repeat a number
that year's own January Sundays already used. The now-redundant
property and its is_resumable_sunday_slug helper are removed from
test_temporal_ef.ml; test_validate.ml's own domain-wide property
covers the same ground for every consumer.
2. The anchors-erosion guard (Plan 2: deleting entries from a rite's
anchors list left the whole suite green) is implemented, but not in
Validate. Which of a rite's named days are Easter-derived is
knowledge only the rite's own `named` function has; Rite.t
deliberately exposes only `temporal` and `anchors`, never `named`,
so a rite-agnostic Validate has no ground truth to check anchors'
completeness against. Hardcoding an Easter offset, or even Easter
itself, would smuggle Western/Gregorian-specific knowledge into code
meant to also serve a future Julian-reckoning rite; rediscovering
"named-ness" structurally from `temporal` alone is unsound for EF,
since most ordinary Sunday/feria slugs from Septuagesima onward are
also constant-offset-from-Easter by construction. The guard is
therefore EF-specific and lives in test_temporal_ef.ml, discovering
the Easter-derived slug set mechanically (scanning a window around
Easter and keeping whatever `named` answers Some for) rather than
hand-copying either named's or anchors' own offset list, then
asserting completeness against the real anchors for the domain's
Easter extremes (1598, 1666) plus an ordinary year. A negative
fixture proves the guard has teeth, matching Plan 2's exact
regression (anchors missing "ef-ascension" reports it, and only it,
as missing).
3. test_validate.ml's extreme_years comment claimed 1818/2038; verified
against Computus.gregorian_easter directly, the domain's actual
Easter extremes (1583..2500) are 1598/1666. Corrected.
Verification: the full 1583..9999 domain sweep (233 tests via dune
test's 200-sample default, plus a manual full sweep) reports exactly
one failure -- the known, already-pinned year-9999 season-truncation
case -- and zero occurrences of the new "slugs" check anywhere in the
domain. Deleting "ef-ascension" from the real anchors list (reproducing
Plan 2's regression directly) is caught immediately by the new EF test
and, confirmed empirically, invisible to Validate's own full property
sweep -- direct evidence for why item 2 cannot live in Validate.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Task 11's re-review found that Precedence_ef.transfer_target's
Annunciation/Easter condition -- and RG 96's general walk more broadly --
is correct only because Temporal_ef happens to make every day from
Easter Sunday through Low Sunday (Easter+0..+7) blocking (Class1/2):
Easter and Low Sunday via named, every day between via
privileged_feria. Nothing enforces that; a future edit narrowing the
octave's blocking range could let a translated feast land inside it,
silently.
Add a test for the consequence, not the mechanism: over 2005-2050 (real
data, the project's own differential window), no day in [Easter,
Easter+7] is ever a transfer's target, checked against both
transferred_in and transferred_out's own recorded target dates. Plus a
direct, deliberately-constructed case that starts the RG 96 search
inside Holy Week itself (Holy Thursday 2026, real occupant), pinning
that the search lands on Easter+8 -- and a companion test that reads the
real occupant's own rank across the whole [origin+1, Easter+7] span to
confirm the search genuinely walked through the window rather than
stopping early for an unrelated reason.
Mutation-verified: narrowing privileged_feria's post-Easter range (6 to
4 days) makes all three new tests fail, including a real natural
occurrence the fixture did not anticipate (St Joseph, 19 March,
transferring into Easter+5 in 2008/2035/2046) -- not just the
deliberately constructed Holy Week case.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Widen Validate.run to take the rite's sanctoral layer alongside the rite
itself (Calendar.year needs both), and add five checks over the fully
resolved liturgical year, on top of the existing temporal-only pass:
- observed: a day's observed celebration never also appears among that
same day's own commemorations/omissions.
- lost: no sanctoral entry is silently dropped. Per slug, the number of
times it is actually sighted (observed + commemorations + omitted,
summed over the year) must never fall below the number of times its
own Date_spec resolves within the year's span -- also fires if
resolving the year raises at all, the most total form of loss.
- duplicated: the same per-slug count must never exceed the number of
Date_spec resolutions either. Deliberately NOT "no slug appears
twice": a fixed date can legitimately resolve twice in the ~20% of
liturgical years whose 371-day span reaches it on both ends (30
November/St Andrew is the worked example in validate.mli).
- unconverged: no day's omitted reason indicates Calendar's placement
pass hit its round guard before reaching a fixed point.
- admission: the rite's own rules.admit is a fixed point on what it
already admitted -- the rite-agnostic form of "the admission limit
was not exceeded" available without embedding a rite's own numeric
caps (RG 111's, for EF) into kernel code.
Each check has a dedicated negative fixture in the synthetic rite
(test_validate.ml), hand-traced against Calendar's actual resolution
mechanics before writing the assertion, and verified to fail for the
right reason against the code before this change. One pair
(unconverged/duplicated) is not fully independent: hitting the round
guard genuinely also trips duplicated, a real consequence of Calendar's
own accounting once a candidate is simultaneously sighted at its
permanent natural date and wherever the last placement round left it --
documented in guard_rules's own comment, not papered over.
test_validate.ml's ef_rite/run now use the real Rite_ef.context and the
real bootstrapped data/ef layer (Precedence_ef and the sanctoral
bootstrap did not exist when this scaffolding was first written) rather
than the earlier placeholder rules. Validate is clean across the whole
1583..9999 domain against real EF data except the one already-documented
year-9999 truncation case (test_year_9999_does_not_raise).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The register was transcribed faithfully but was itself wrong: RG 96's
Attamen (a), primary-source-verified from the scans and now corrected
in the register, reads 'festum Annuntiationis B. Mariae Virg., quando
est transferendum post Pascha, transfertur ... in feriam II post
dominicam in albis' -- the Monday-after-Low-Sunday seat applies ONLY
'quando est transferendum post Pascha', when the feast is to be
transferred PAST EASTER. The unconditional transcription made the
exception fire on every impeded Annunciation regardless of cause.
transfer_target now computes the general RG 96 target first, for every
candidate, and overrides to the Monday after Low Sunday only when that
general target itself falls after Easter Sunday -- testing the rubric's
own condition directly rather than re-deriving a date-proximity rule
from first principles.
Confirmed against three real years the review named: 2007, 2012 and
2057 all previously sent the Annunciation to Easter + 8 (16 April,
16 April, 30 April respectively) when the correct, now-produced target
is the next free day before Easter (26 March in each case -- Passion
Sunday in 2007/2012, Lent III Sunday in 2057). Verified with actual CLI
output for all three, before and after.
Also cites RG 96 Attamen (b), the same primary-source passage, as the
direct authority for All Souls' own move to the following Monday when
impeded by a Sunday -- previously inferred from RG 91 entry 8's
parenthetical plus the general walk, which happened to produce the
right date; now stated directly.
Rewrote the two existing Annunciation unit tests, whose synthetic
occupants no longer trigger the (now correctly conditional) exception,
and added a 2057 regression test using the real Temporal_ef.temporal as
occupant plus a real-data cram pin -- both mutation-verified against
the unconditional reading.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With data/ef/adjustments.sexp's one Suppress directive replaced by an
empty directive list, colitur day 2026's stdout was byte-identical for
all 365 days and the whole suite still passed: ef-nativity-vigil already
outranks vigil-of-christmas in the RG91 contest regardless of whether
the overlay ever ran, so the suppression's only observable effect is
keeping vigil-of-christmas out of 24 December's Liturgical_day.omitted
-- a field no cram assertion reads. test/dune's own dep on
adjustments.sexp pinned the file's existence, never its content.
Confirmed the gap two ways: reverting the overlay to (directives ())
makes this new test fail (24 December's omitted gains
vigil-of-christmas), and confirmed test/cli.t's whole cram suite still
passes under that same mutation -- cram is structurally blind to this,
not merely undertested.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
search_from could walk up to 400 days past origin before Calendar's own
~start ~stop clamp is ever consulted, and nothing stopped it probing
occupant on a date past 31 December 9999 -- occupant chains through the
real EF rite's temporal, which calls Computus.gregorian_easter, not
total outside 1583..9999 (it Date.makes and failwiths on Error).
Not reachable with the shipped sanctoral data alone, but reachable
through the project's own primary extension path: an overlay adding an
I-class feast on 25 December leaves nothing but Class2 Nativity-octave
days for the rest of civil year 9999, so the unguarded search reached 1
January of year 10000 and crashed there with 'computus: year 10000 out
of range 1583..9999'. 9999 is an in-range year and the kernel's contract
is 'never raises on in-range input'.
search_from now also stops, without probing occupant again, once it
passes Date's own domain ceiling -- the same 'return a finite date, let
Calendar's own out-of-range handling record it, never pretend to have
found something admissible' contract the existing step-count guard
already follows.
Two new tests, both mutation-verified to actually reproduce the crash
when the guard is removed (see the task report): a precedence_ef.ml unit
test using the real Temporal_ef.temporal as occupant (a synthetic
occupant can never discriminate this, since it never calls Computus
itself), and a Calendar-level integration test reproducing the exact
overlay-based scenario the review found.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Assembles Rite_ef.context (lib/rites/rite_ef/rite_ef.ml[i]): temporal,
anchors and vocab from Temporal_ef; rules from Precedence_ef's band,
disposition and admit; season_runs = Vocab_ef.seasons; transfer_target
newly implemented here.
transfer_target (RG 96): the next following day that is not I or II
class, with the Annunciation's own exception (Monday after Low Sunday).
Terminates by a structural step bound on its internal search, independent
of Calendar's own round guard, which bounds rounds across a year, not one
call's walk; documented as an obligation on rite.mli's transfer_target
field, which did not previously state it.
Fixes the vigil-naming mismatch Task 7's review predicted: the sanctoral
bootstrap names its vigils with a vigil-of-X prefix (lectio's own
convention), while Precedence_ef's is_vigil only recognised the temporal
cycle's own X-vigil suffix. Both are now recognised, fixing RG 91 entries
21/26 and RG 33's vigil omission for the four affected celebrations.
Verified by unit test and by mutation-testing the fix (reverting it fails
exactly the new rows) and against real output across several years.
Suppresses data/ef/sanctoral.sexp's vigil-of-christmas via a new overlay,
data/ef/adjustments.sexp: it is the same celebration as the temporal
cycle's own ef-nativity-vigil, both dated 24 December.
colitur day <year>: one line per civil-year day, temporal and sanctoral
fully resolved through Layer, Overlay, Precedence_ef and Calendar -- the
first CLI path exercising the whole Plan 3 pipeline against real data.
Verified the All Souls transfer chain (Tasks 7-8-11) end to end against
real output for both a Sunday year (2025, lands on 3 Nov) and a
non-Sunday year (2026, observed directly on 2 Nov).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Convert lectio's tridentine-calendar.ini (322 entries) into
data/ef/sanctoral.sexp via a validating OCaml converter, tools/
bootstrap_sanctoral.ml, rather than a hand-written script: every field is
built through Slug.of_string, Colour.of_string and Vocab_ef.rank_of_string,
so the emitted sexp is valid by construction.
Two conversion decisions, both documented rather than buried:
- subject defaults to Subject.Saint, overriding Celebration.make's kernel
default of Subject.Temporal, for the 316 entries with no explicit class;
- rank = commemoration maps to status = Commemoration_only with an inferred
Class3 (not a citation -- it is what the 1960 reform reduced most simple
feasts from), recorded as an open item in the rules register for the
oracle to adjudicate.
Every celebration is tagged layer = Precedence_ef.universal_layer, the
provenance id RG 91's band classifier reads to tell the universal calendar
from proper/indult data.
The generated file carries a provenance header: source path, its SHA-256,
and the UTC conversion date, so re-bootstrapping against a newer lectio is
reproducible and diffable. Output is byte-identical across runs.
test/test_sanctoral_ef.ml loads the file through Layer.load and checks the
counts independently derived from the source INI (322 entries, 114
Commemoration_only, 12 Class1, no Subject.Temporal, every date resolves in
a leap year), plus two named spot-checks against the INI's own text -- one
entry with an explicit class field, one commemoration -- so a passing count
cannot hide the wrong 322 entries having been converted.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Adds test_ii_class_sunday_privileged_witness_admitted_end_to_end,
proving RG 111's "II-class Sundays: one, dropped if a privileged one is
due" clause through the real pipeline (band, disposition, privilege_of,
admit together), not only at the isolated admit level.
RG 109(b) is the one privileged category that is sanctoral and
rank-based rather than temporal-origin: a Commemoration_only, Class1
sanctoral candidate (the same shape disposition_cases already uses as
(b)'s witness) is held out of the band contest entirely by
Precedence.resolve, so it always loses regardless of what wins the
day. Paired with an ordinary sanctoral saint, both losing to an
ordinary Class2 Sunday, gives observed_is_sunday = true with one
privileged and one ordinary loser due at once, with no new fixture.
Documents, and mutation-confirms, what this fixture does and does not
prove: RG 109(b)'s only reachable witness is Class1 (the highest
dignity), so the privileged loser here is unavoidably also the
higher-dignity one, and the admission outcome alone cannot distinguish
"privilege overrides dignity" from "dignity alone picked the same
winner" -- that distinction remains admit_cases's job. What this test
does prove, and what a category-(b) regression in privilege_of breaks,
is the privilege tag itself surviving the real pipeline end-to-end.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
disposition's Class1 branch was unconditional on rank, so an impeded
I-class Sunday (Advent/Lent/Passiontide/Low Sunday) currently
transferred like a feast. RG 95 (register lines 323, 363) restricts the
right of translation to I-class FEASTS -- RG 91's own table lists
Sundays as a separate row (entry 6, line 332) from feasts (entries
11-13, lines 337-339) -- and RG 109(a) (line 374) lists "of a Sunday"
as a privileged commemoration category, which presupposes an impeded
Sunday stays put rather than moving to another day.
Excludes is_sunday_slug losers from the Transfer branch so they fall
through to the existing Commemorate (privilege_of loser) branch, which
already tags them Privileged via RG 109(a) with no further change.
Fires on real dates in the 2005-2050 differential window: 24 December
on Advent IV in 2023, 2028, 2034, 2045; 8 December on an Advent Sunday
in 2024, 2030, 2041.
Verified no previously-passing Transfer assertion used a Sunday-shaped
loser (grepped test_precedence_ef.ml, test_calendar.ml -- which uses
its own synthetic rite unrelated to Precedence_ef.disposition --
test_colitur.ml, test_validate.ml); confirmed by mutation-reverting the
fix and observing exactly the one new test fail, nothing else.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Precedence_ef.privilege_of classifies a commemoration candidate against
RG 109's closed list of privileged commemorations (a Sunday; a I-class
day; a day within the Octave of the Nativity; a September Ember day; a
feria of Advent, Lent or Passiontide; the Major Rogations in Mass), read
entirely off the candidate's own rank/slug/origin, no context needed.
Major Rogations (f) is left unimplemented rather than guessed: no
producer for the Major Litanies exists anywhere in this codebase yet.
disposition's two Commemorate sites now call privilege_of instead of
Task 8's interim_privilege placeholder, which is removed entirely
(binding and .mli export both gone).
Precedence_ef.admit applies RG 111's four admission counts, keyed on
the observed day's own class and Sunday-ness: a I-class day admits none
except one privileged commemoration; a II-class Sunday admits one, but
a privileged commemoration due displaces any ordinary one regardless of
dignity; any other II-class day admits one by dignity alone, with no
such override; III/IV-class days admit at most two by dignity. Ties
break on slug, matching Precedence.compare_by, so the admitted set
never depends on input order. Every admitted candidate is a value taken
unchanged from the input list, never rebuilt, so Precedence.resolve's
physical-equality-based dropped/omitted accounting keeps working --
closing a note left open since Task 2.
Tests: RG 109 category rows (one per reachable category, plus boundary
rows proving Advent/Lent Ember days and Minor Rogations are correctly
excluded), RG 111 admission rows checked on slug identity rather than
count, an order-independence check, and three end-to-end integration
tests proving the admission limit's drop lands in resolution.omitted
rather than vanishing.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Precedence_ef.disposition decides the loser's fate in an occurrence: a
Commemoration_only celebration is always commemorated (it can never win or
transfer); a I- or II-class vigil impeded by any Sunday or a I-class feast
is entirely omitted (RG 33), checked before the generic rule below or the
Nativity/Pentecost Vigil could wrongly transfer; any other I-class loser
transfers (RG 95 -- only I class has the right of translation); everything
else is commemorated, with the admit-or-omit decision left to RG 108-111's
admission count (Task 9). RG 94 needs no code: resolve always compares a
loser against the day's actual winner, never against a departed sibling, so
no commemoration can ride along with a transferred feast in this design.
This is the branch that completes Task 7's carried All Souls fix: once it
loses to an occurring Sunday, its untouched Class1 rank routes it to
Transfer via the generic rule, not a special case. Landing on 3 November is
Rite.transfer_target's job, not wired up yet.
Commemorate carries an interim Precedence.Ordinary privilege pending Task
9's RG 109 implementation, exposed as interim_privilege for that task to
replace.
Table-driven tests cover each rule, including RG 33's boundary from both
sides and a Commemoration_only loser that is also Class1 and vigil-shaped
to pin the branch ordering. Mutation-tested: disabling RG 33, either
direction of RG 95's rank condition, or the Commemoration_only priority
check each fail exactly the rows built to catch them.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Review of 436ba75 found two calendar defects and one coupling risk.
Entry 8 (All Souls) dropped register line 334's own qualifier,
"(yields to an occurring Sunday)" -- it returned 8 unconditionally,
so on 2 November falling on a Sunday (2025, 2031, 2036, 2042 in the
2005-2050 differential window), All Souls incorrectly outranked and
observed over the Sunday. 2 November is always Time_after_pentecost
and never coincides with any other entry's own date, so the only
rival this exception ever has is an ordinary entry-15 II-class
Sunday; on such a Sunday, band now returns one worse than entry 15's
own value rather than the literal 8 -- strictly worse, not merely
different, since an exact tie would fall to Precedence.resolve's slug
tie-break, which for "ef-all-souls" against a Sunday slug would make
All Souls win the tie anyway. Entry 8's own rank is untouched, so
Task 8's disposition still sees a true I-class candidate to transfer.
Entry 14 (Feasts of the Lord, II class) added a universal-layer
restriction the register's line 341 does not carry -- contrast entry
16 at line 342, which explicitly says "not of the Lord"; RG 37c
(register line 393) also speaks of "II-class feasts of the Lord"
with no universal qualifier. Dropped the layer test: a proper or
indult feast of the Lord now bands 14, not 19/20.
Also exposes vigil_suffix and ember_prefixes from precedence_ef.mli,
matching universal_layer/indult_prefix's existing "colitur convention,
not an RG citation" treatment -- both were previously private literals
duplicated in the test file, so a rename of temporal_ef.ml's slug
format could have drifted silently past both sides agreeing with each
other. Two test rows now build their candidate from Temporal_ef.temporal's
own real output (entry 18's Lent Ember day, entry 21's Ascension Vigil)
instead of a hand-typed slug, closing that specific coupling.
Adds the three cheap rows review named as closing the remaining
unpinned guards (a temporal-origin Class1 candidate on an unnamed
date; a universal Class2 vigil of the Lord; a non-universal Class3
vigil), plus a resolve()-level test proving the Sunday is actually
observed over All Souls, not just that band returns the right integer
in isolation.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Precedence_ef.band transcribes RG 91's 28-entry Table of Precedence
(rules-register.md §4) for the EF rite: given a day's context and a
candidate celebration, returns the table's own entry number, 1-28
(I class 1-13, II class 14-21, III class 22-26, IV class 27-28); lower
wins. Every branch carries its entry number and register citation in a
comment, checked in the table's own numeric order.
Two entries are transcribed as the register states them even though
they invert the pattern the rest of the table follows: at III class,
23 (particular calendars) outranks 24 (universal), the reverse of how
11/12 and 14/16/19/20 rank a universal feast ahead of a proper one at
I and II class.
Sanctoral-origin, layer-decided entries (11-13, 14/16/19/20, 23/24)
follow the brief's structural insight: a celebration whose layer is
not the universal base is an overlay -- proper, or indult if its
layer id also carries the indult prefix. Neither the universal-layer
id nor the indult prefix is an RG citation; both are colitur's own
data-modelling convention, exposed from the module so whichever task
loads the real EF sanctoral overlays can align to them.
Vigils (21, 26) are read off the temporal cycle's own -vigil slug
suffix rather than gated on origin, since a II/III-class vigil can be
either temporal-origin (Ascension, already produced by temporal_ef) or
sanctoral-origin (a saint's vigil, no task has loaded yet); Ember days
(part of entry 18) are read off temporal_ef's own ember slug prefixes
rather than re-derived, since the September anchor is independently
flagged there as one of the more contested dates in the calendar.
A candidate shape the table has no row for (e.g. a Class1 vigil that
is not Nativity or Pentecost, or a Class4 candidate marked as a vigil
-- RG 91 has no IV-class vigil either) returns a dedicated unclassified
sentinel (max_int) rather than being folded into a same-rank entry it
does not belong to.
test_precedence_ef.ml is table-driven: one Alcotest.test_case per RG
91 entry (55 rows total, several entries covered by more than one
named day so a single missed offset cannot hide behind a passing
sibling), each date computed from Computus.gregorian_easter rather
than hand-typed, so an arithmetic slip cannot pass by accident.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Four findings from Task 6 review, addressed on top of f15e44d.
1. transferred_out was a single Date.t option, so when RG 97-98 collides
three or more feasts on one date (more than one loser), only the last
one Hashtbl.iter happened to visit survived -- a genuinely lost move,
and which one survived depended on OCaml's hash seed
(OCAMLRUNPARAM=R), an environment read a kernel invariant forbids.
RG 97-98 says coinciding feasts transfer "in order" -- plural -- so
the type was wrong, not the fixture: transferred_out is now
(Celebration.t * Date.t) list. transferred_in stays a single option,
deliberately: a day receives at most one arrival (RG 96 sends each
departure to the next non-I/II-class day, and the first to arrive
occupies it). The per-day list is canonicalised (sorted by target
date, then slug) after accumulation, the same fix layer.ml already
applies to its own date-bucket index and for the same reason.
Verified clean across 15 runs under OCAMLRUNPARAM=R; disabling the
canonicalisation step showed the raw order genuinely flip between
seeds, confirming the fix is load-bearing.
2. Every deferred candidate in the fixture was the same rank, so
compare_deferred's band branch was unreachable and reversing it broke
nothing -- the RG 97-98 test was pinning slug order, not band order.
The fixture now has three ranks (Hi1 outranks Hi2, both transfer,
both outrank Lo), with slugs chosen so band order and slug order
disagree. Reversing the band comparison now fails the test on
"higher-band loser claims 2 Feb first", received the wrong slug
instead.
3. A transfer_target free to name any date could place a candidate
outside the liturgical year's own start/stop bounds: invisible to
year/build_day, so it would be observed nowhere and, since its
origin's re-resolution would report it as settled, omitted nowhere
either -- genuinely gone, contradicting calendar.mli's "never
silently dropped". place_transfers now checks the range on every
placement and routes an out-of-range one to a permanent-exclusion
table instead of assignment, with its own cited omitted reason.
4. Precedence.resolve folds Transfer and Repose into one deferred case,
and place_transfers routed all of it through transfer_target (RG
96's search), which is only correct for Transfer. Repose is RG
100-102's repositio, a distinct rubric this module does not
implement. Documented rather than split into a second mechanism:
nothing in the EF ruleset returns Repose (design spec section 1.3,
"declared, not exercised"), so the gap is latent, not a live bug.
Two new tests (origin records every departure; transfer target outside
year is recorded not lost); the RG 97-98 test's fixture and assertions
rewritten for finding 2.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Calendar.year now runs a placement pass after resolving every day: each
deferred candidate (RG 95's I-class-only right of translation, via
Precedence's Transfer disposition) is placed on the next day the rite's
new Rite.t.transfer_target names as admissible, transferred_in/out are
set on the two ends of the move, and the whole year is re-resolved to a
fixed point, bounded by a hard max_transfer_rounds = 64 guard.
transfer_target is rite-supplied rather than a generic search Calendar
drives itself: RG 96's 'not I or II class' is not derivable from band or
disposition alone (RG 91's own table lets a universal I-class feast
outrank an ordinary Sunday in a raw contest, yet RG 96 forbids landing a
translation there regardless), and the search's starting point is
rite-specific too (the Annunciation exception). It takes an occupant
callback exposing what Calendar currently resolves as observed on any
date, so the rite never has to re-implement occurrence resolution.
Two correctness properties drove most of the design:
- A candidate's permanent natural loss at its own origin (the layer entry
never moves) is rediscovered every round; left unfiltered this
oscillates a placed candidate between two dates forever, since its own
rank makes it look 'occupied' to a fresh search from its origin. Both
the round loop's gather and the final per-day omitted accounting filter
this out, keeping only sightings that are either brand new or losing at
a candidate's *current* target (a fresh RG 97-98 bump).
- RG 97-98's sort has to actually decide something, not just happen to
agree with Precedence.resolve's own tie-break next round: a
claimed-this-round overlay lets earlier-processed candidates in one
round block later ones in the same pass, so two coinciding I-class
feasts land on consecutive admissible days in the one round they
collide, in band order.
Also folds in Task 5's review finding: year_bounds clamps y to [1582,
9999] once, up front, rather than guarding start and stop independently
(each guard only ever covered one of the two rite.year_start calls,
leaving year 999 and year 100000 each able to call it out of domain
through the other branch).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Precedence.resolution already tracked what happened to every losing
candidate -- commemorated, deferred, or omitted with a reason -- but
Liturgical_day.t had nowhere for the deferred and omitted buckets to land,
so Calendar dropped them at the door. Task 12's no-celebration-lost
invariant needs to read that accounting off the day result itself, not
re-resolve every day to reconstruct it, so a reason recorded nowhere is not
recorded.
Add Liturgical_day.omitted : ('r Celebration.t * string) list, after
transferred_out and before citations. Calendar.resolve_day now folds
resolution.omitted (Precedence's own native omissions, reasons intact) and
resolution.deferred (mapped to "deferred: transfer placement not yet
implemented (Task 6)") into it.
Adds a full-day accounting test against the whole Calendar pipeline: four
colliding sanctoral entries plus the day's feria, checked as a slug set
(matching test_precedence.ml's own nothing-silently-lost test) so a
candidate silently dropped or duplicated into two buckets would fail it,
plus an identity check that the deferred and admission-limit reasons don't
get swapped.
|
| |
|
|
|
|
|
|
|
|
|
| |
Transfers make per-date resolution impossible to do correctly: resolving 25
March can push a feast onto 26 March, and RG 97-98 has coinciding I-class
feasts transfer in table order, which needs global knowledge. So year computes
a whole liturgical year in one pass and day indexes into it. Pure, no cache, no
mutable state.
This commit resolves each day but does not yet place deferred transfers; they
are recorded with a reason. Task 6 adds the placement pass.
|
