From d0b78ca2ef533080d4621b22071718bb8d3a6158 Mon Sep 17 00:00:00 2001 From: Lukasz Kasprzak Date: Wed, 12 Aug 2026 11:19:51 +0200 Subject: docs: close the final review's four documentation residues precedence_ef.mli said "there is no fifth, unclassified case" after the same commit renumbered the disposition list from four cases to five; the count is now six. precedence.mli's physical-equality obligation described the failure mode as counting a drop "a SECOND time (once because it is genuinely absent, once because its identity no longer matches)" -- the same condition stated twice. What actually happens to a rebuilt candidate record is that the celebration surfaces in BOTH commemorations (the copy) and omitted (the original), one admission double-reported. precedence_ef.ml carried the same muddled sentence, which is where the kernel's copy came from; both now say it plainly. vocab.ml/.mli referenced {!Rite_ef.rite_ef.ml} -- a filename inside an odoc reference, which is malformed. Now plain [Rite_ef.rite]. README documented only `dune test`, so the exhaustive 1583-9999 Validate sweep was discoverable only by reading test_validate.ml's own comment. With no CI in this repo, that line is what stands between a committed artifact and one anyone runs. No behaviour change: `colitur day` output is byte-identical across 1583, 1900, 1902, 2008, 2011, 2026, 2038 and 9999 (2921 days, both domain edges). 259 tests by default, 260 with the sweep. --- lib/kernel/precedence.mli | 12 +++++++----- lib/kernel/vocab.ml | 2 +- lib/kernel/vocab.mli | 2 +- 3 files changed, 9 insertions(+), 7 deletions(-) (limited to 'lib/kernel') diff --git a/lib/kernel/precedence.mli b/lib/kernel/precedence.mli index 4225eb7..ae054dd 100644 --- a/lib/kernel/precedence.mli +++ b/lib/kernel/precedence.mli @@ -47,11 +47,13 @@ type ('s, 'r) rules = { {!resolve}'s own [omitted] accounting distinguishes an admitted candidate from a dropped one by PHYSICAL equality ([==]) on the candidate value, not structural equality -- a rebuilt record is - [=] to the original but not [==], so {!resolve} would then count - it as dropped a SECOND time (once because it is genuinely absent - from the admitted set, once because its identity no longer - matches its own admitted copy), silently double-counting rather - than raising. This obligation previously lived only in one rite's + [=] to the original but not [==], so {!resolve} cannot match the + rebuilt copy against the original it was given. The celebration + then surfaces TWICE in the same day's result -- once in + {!resolution.commemorations} (the rebuilt copy, admitted) and once + in {!resolution.omitted} (the original, which nothing in the + admitted set matches). One admission, double-reported, silently + rather than raising. This obligation previously lived only in one rite's own module documentation (Rite_ef.Precedence_ef.admit); stated here because this signature -- not any one rite's implementation of it -- is what an author of the next rite reads. *) diff --git a/lib/kernel/vocab.ml b/lib/kernel/vocab.ml index bcb48b8..a4e61a3 100644 --- a/lib/kernel/vocab.ml +++ b/lib/kernel/vocab.ml @@ -14,7 +14,7 @@ type ('s, 'r) t = { carried item 1: EF has each season in one run, but the modern form's Ordinary Time does not, so the expected run sequence had to become rite-supplied rather than derived from this field). - For EF specifically {!Rite_ef.rite_ef.ml} sets season_runs to + For EF specifically [Rite_ef.rite] sets season_runs to this very list, so the two happen to agree there, but Validate itself no longer reads [seasons] to build its expectation. *) season_to_string : 's -> string; diff --git a/lib/kernel/vocab.mli b/lib/kernel/vocab.mli index bcb48b8..a4e61a3 100644 --- a/lib/kernel/vocab.mli +++ b/lib/kernel/vocab.mli @@ -14,7 +14,7 @@ type ('s, 'r) t = { carried item 1: EF has each season in one run, but the modern form's Ordinary Time does not, so the expected run sequence had to become rite-supplied rather than derived from this field). - For EF specifically {!Rite_ef.rite_ef.ml} sets season_runs to + For EF specifically [Rite_ef.rite] sets season_runs to this very list, so the two happen to agree there, but Validate itself no longer reads [seasons] to build its expectation. *) season_to_string : 's -> string; -- cgit v1.3