summaryrefslogtreecommitdiff
path: root/lib/kernel/precedence.mli
diff options
context:
space:
mode:
authorLukasz Kasprzak <lukas@labunix.xyz>2026-08-12 13:33:03 +0200
committerLukasz Kasprzak <lukas@labunix.xyz>2026-08-12 13:33:03 +0200
commit3d8bafa9c5b0f3ac2b16128413ea7ae977b1856a (patch)
tree1e88377749c5ead0da118ccf7f2645839ba2a193 /lib/kernel/precedence.mli
parent7d3b5ec831a60e8b63466251d63b2bd564acba2b (diff)
downloadcolitur-3d8bafa9c5b0f3ac2b16128413ea7ae977b1856a.tar.gz
colitur-3d8bafa9c5b0f3ac2b16128413ea7ae977b1856a.zip
docs(rite-ef): correct a false band-value comparison in the RG16(a) comment
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.
Diffstat (limited to 'lib/kernel/precedence.mli')
0 files changed, 0 insertions, 0 deletions