aboutsummaryrefslogtreecommitdiff
path: root/internal
Commit message (Collapse)AuthorAgeFilesLines
* caldata: two Judith citations lost a chapter boundaryLukasz Kasprzak2026-08-171-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | The Assumption's epistle is Iudith 13, 22-25 et 15, 10 -- two chapters. It was recorded as "Judith 13:22-25; 13:15; 13:10", carrying chapter 13 across the boundary and inventing two verses that are not in the Mass at all, on a I-class feast. The Seven Sorrows' is Iudith 13, 22 et 23-25. It was recorded as "Judith 13:22; 13:25", keeping only the range's endpoint. Both verified in the photographic scans of the 1962 Missal: Assumption IN ASSUMPTIONE B.M.V. "Iudith 13, 22-25; 15, 10" Seven Sorrows SEPTEM DOLORUM B.M.V. "Iudith 13, 22 et 23-25", printed identically at its Mass and in the votive Mass of the same feast. Found by comparing a full liturgical year (2028-12-03 .. 2029-12-01) against missalemeum's live API, day by day, while giving colitur a lectionary of its own. 333 of 364 days already agreed; these were two of three genuine divergences in the remainder. The third was St Monica (4 May): missalemeum serves Prov 31:10-17, this data serves 1 Tim 5:3-10. The Missal gives her a proper epistle -- "Lectio Epistolae beati Pauli Apostoli ad Timotheum", 1 Tim 5, 3-10, "Carissime: Viduas honora, quae vere viduae sunt" -- in both scans. No change: the oracle is wrong there, not this data.
* release: v0.46.1v0.46.1Lukasz Kasprzak2026-08-171-1/+1
|
* caldata: the Lenten Ember days were serving Lent I Sunday's MassLukasz Kasprzak2026-08-172-3/+65
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Three lectionary sections were keyed ef-lent-1-{wednesday,friday,saturday} while temporal_ef.go's efEmberSlug computes ef-lent-ember-{wed,fri,sat}. The lookup in caldata.Readings takes the observed slug and has no alias table, so it missed the entries entirely and fell through to the preceding-Sunday fallback. Every Lenten Ember day since the data was added has served Lent I Sunday's Mass -- three days a year, in a season that prints a proper Mass daily. The values were already right; only the keys were wrong, and they were stale rather than mistaken: they predate Lent being added to efEmberSlug, and scripts/genlect.go keys off day.Observed.Slug, so re-running it would already write the correct names. Advent and September were never affected -- both already use the -ember- form. Renamed, and verified the whole file: every one of the 119 section names is now a slug the calendar actually computes, checked by sweeping 2005-2050. Those three were the only dead keys. Added TestEFLectionaryKeysAreReachableSlugs to make the class detectable rather than just this instance. Mutation-tested: reverting the three keys fails it, naming all three. Found by differencing against colitur, the sibling OCaml engine, while giving it a lectionary of its own. Worth recording how nearly it escaped: colitur inherited the same wrong keys from this file during its bootstrap, so both engines produced the same wrong Mass and the differential between them was silent. It only surfaced when colitur's data was checked against the Missal itself. Two implementations agreeing is not evidence when one was seeded from the other.
* release: v0.46.0v0.46.0Lukasz Kasprzak2026-08-141-1/+1
|
* gen-sanctoral-ef, caldata: fix round 3 -- guard coverage, rank pins, name ↵Lukasz Kasprzak2026-08-121-19/+95
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | test, Anastasia Second external re-review returned Spec pass on round 2 (all ten prior findings addressed, C1/C2 fixed at the root, mechanism claims held under mutation) and found two blocking items in the I3 guard itself, plus three recommended hardenings. All verified independently before fixing. BLOCKING 1: refYearExplainsAbsence's own doc comment said the id-rank exclusion covers "6-31 December"; the code implemented `Day() >= 26`. A typo (26 -> 6), but the wrong kind to have on the one comment this whole review chain exists to keep honest -- fixed as part of the rewrite below, not left as an isolated one-character correction. BLOCKING 2: the guard covered only 6 of the 13 MM-DD values round 1's own temporal_ef.go changes actually made refYearExplainsAbsence couple to. Measured, not just reasoned about: running the function's body against the branch-point engine versus HEAD over the six reference years flips its verdict on 50 dates across 12-17 through 12-23 (round 1's late-Advent promotion, RG 91 entry 18, a 140-day change) AND 12-26 through 12-31 (the Nativity-octave promotion, RG 67/68, already guarded). The late-Advent half was unguarded. No live bug today -- confirmed by regenerating: the ini is BYTE-IDENTICAL before and after this fix. The only sanctoral entry in 17-23 December is `thomas` (21 December), reached via harvestDate's `obs` (observed-office) path, never refYearExplainsAbsence's commemoration-id-trust path at all. Widened the guard to 17-31 December anyway, on the side of the known-safe default (RankCommemoration) rather than wait for the first real entry in that range to repeat I3's exact failure shape. The two sub-ranges are NOT the same strength of evidence, and the doc comment says so explicitly now: 26-31 December rests on a positive RG 68(d)/(e) citation naming Thomas Becket and Silvester directly as bare "Commemoratio, no class"; 17-23 December is a precautionary exclusion with no equivalent citation -- RG 91 entry 18 ranks the FERIA, not any commemoration that might coincide with it, and (per defect 2's own finding) a genuine class-2 feast there would actually WIN against the ferias's own privilege, so "the day is class-2" does not reliably explain a class-2 saint's absence here the way it does for the Nativity octave's two named cases. Recorded as a real asymmetry, not smoothed over. RECOMMENDED 3: rank = commemoration is now pinned for all four entries this task's two review rounds touched -- romanus, eusebius-confessor (C2), thomas-becket, silvester (I3) -- not just their presence and date. `git grep` before this commit returned zero hits for thomas-becket or silvester rank anywhere in *_test.go; a future regeneration could have rewritten either back to class-4, the exact I3 failure mode, with the suite green throughout. RECOMMENDED 4: TestTridentineNamesPreservedAcrossRegeneration rewritten on both axes the review found loose. It counted name.pl only -- a hardcoded single language, the identical "whitelist of two" mistake C1's own generator fix exists to stop repeating, just moved into the test instead. Now DISCOVERS every name.<lang> key actually present in the data (so a regeneration dropping name.la, or losing a future name.de, is caught the same way as name.pl) and asserts the discovered language set is exactly {en, pl} -- not just each count. The >= 315 floor had 7 entries of slack (the review proved 6 missing Polish names still passed it); tightened to the exact, independently verified true count (322), zero slack. RECOMMENDED 5: the 25 December Anastasia gap and its cause are now recorded, not just her absence. Two compounding, independently checked causes: fetchOnce reads only `data[0]`, missalemeum's FIRST of Christmas Day's three Masses, so a commemoration attached to a second or third Mass (the calendarium's own "In secunda Missa: Commemoratio S. Anastasiae Mart.") is structurally invisible to this harvester for ANY date, not just this one -- but ALSO, checked live, missalemeum's own "commemorations" list is empty on all three of the date's records, not just the first, so a fetchOnce rewritten to merge all of a date's Masses would still not recover her. Documented at both fetchOnce's own definition and the PRIMARY-SOURCE NOTE, since the two facts belong to different questions (a real code limitation worth fixing someday vs. an upstream data gap this generator cannot close at all). Witnesses: TestTridentineCommemorationRanksPinned (new), TestTridentineRomanusAndEusebiusPresent (extended with rank), TestTridentineNamesPreservedAcrossRegeneration (rewritten). No pre-fix failure to report for the two new/tightened tests specifically -- these are regression GUARDS against a bug class already fixed in round 2, not fixes for a currently-red state; their value is in what they would now catch, not what they catch today. internal/caldata/ tridentine-calendar.ini is NOT regenerated by this commit -- confirmed byte-identical before and after re-running the generator, exactly as "no live bug today" predicts.
* oracle_ef_test: three structural coverage gaps in the strengthened testLukasz Kasprzak2026-08-121-5/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Cheap fixes flagged in review, all confirmed against the committed snapshot before being applied: 1. An unmapped season phrase skipped the RANK AND COLOUR checks too, not just the season comparison -- `continue` in the wrong place. Confirmed live: neither Holy Thursday ("maundy"/"holy week" do not match the title "Holy Thursday" itself) nor any of the six September Ember days (no "ember" case exists at all; the Advent and Lent Ember days only ever passed by an incidental substring match on "advent"/"lent") had any oracle coverage at all -- reverting the Holy Thursday colour fix left this test green. Season skip and rank/colour checks are now independent. 2. Colour membership alone cannot catch a Rose regression: violet is a member of every rose/violet pair by construction (Gaudete/ Laetare), so "got violet, want one of [rose violet]" passed even with RG 131's Rose support removed entirely. On the day the pair actually names (oracle rank 1, the Sunday itself, not a weekday reusing its propers), a colour set containing rose now demands rose specifically. 3. `has("sexagesima")` never matched missalemeum's own ligatured "Sexagesimæ" -- confirmed in the committed snapshot: the ligatured form appears 10 times, the unligatured form only 4, and every ligatured instance mapped to season "" (skipped from ALL coverage, not merely a season miss, given finding 1 above). Normalised once, generally (æ -> ae), not as a single hardcoded word, so any other ligature this generator's own data may carry is covered too. Net effect on TestOracleEF: 730 checked (up from 691), 29 skipped (down from 39) -- the 10 reclaimed by fix 3. Still green: 0 unallow-listed rank or colour mismatches over the full snapshot.
* calendar: record the RG 95 chained-transfer gap in the sourceLukasz Kasprzak2026-08-121-0/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | transferIfImpededEF resolves one candidate's own transfer walk in isolation and has no way to notice a SECOND, separately-transferred I-class candidate landing on the same destination day -- St Joseph (19 March) and the Annunciation (25 March) can both walk to the Monday after Low Sunday in the same year (2008, 2035, 2046, e.g. 2035-04-02: annunciation-of-the-blessed-virgin-mary +joseph-spouse- of-the-bl-virgin-mary). RG 95 grants the right of translation "solummodo festis I classis" to I-class feasts only, so both candidates genuinely have it, and the collision they land in together is an ordinary RG 97/98 occurrence question this function does not resolve: pickEF's plain alphabetical slug tie-break settles it instead of re-walking the loser. RG 98 itself supplies the determinism rule this collision needs and does not have: "in paritate autem Officium prius impeditum praecedit" -- at equal table position, the office impeded FIRST takes precedence, which is chronological (Joseph, impeded on the 19th, before the Annunciation's own walk begins on the 25th) and may favour Joseph over the current alphabetical fallback. No functional change -- this collision is left unfixed, defensible against scope (it needs resolving occurrence between two ALREADY- TRANSFERRED candidates, not a single one, a bigger shape than this function currently has). Leaving it unrecorded was not defensible: nothing in internal/calendar/ named RG 95, 97, 98, or chained transfers anywhere before this comment.
* gen-sanctoral-ef, caldata: fix round 2 -- review found five real problemsLukasz Kasprzak2026-08-123-13/+461
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | External review of the seven-defect fix (round 1) confirmed all seven correctly and structurally fixed, then found five further problems in what shipped alongside, two of them critical. All five verified independently before being fixed, not applied on the review's say-so alone -- see each item below for the primary-source check performed. CRITICAL 1: the regeneration destroyed all 322 Polish display names. main() preserved name.la across a regeneration (missalemeum has no Latin titles) but had no equivalent for name.pl, and never emitted one -- name.pl count went 322 -> 0 (confirmed: `git show 2386a45:internal/caldata/tridentine-calendar.ini | grep -c '^name.pl'` = 322; the pre-round-2 file = 0). naming.CelebrationName's own name[lang] -> name.en fallback then silently substituted English for every Polish EF display, reaching mobile.Day(date, "ef", version, "pl") -- a shipped dlectio entry point -- with no error anywhere in the chain, and nothing in this repo's test suite asserting any name.* field at all. Fixed at the root, not by re-adding name.pl specifically: `entry.la` (one hardcoded language) is replaced by `entry.otherNames map[string]string`, populated from every "name.<lang>" field already present except name.en (English always comes fresh from missalemeum) and re-emitted verbatim, sorted for deterministic output -- a third or fourth language added later survives a regeneration without this function changing again. CRITICAL 2: St Romanus was deleted, and St Eusebius (14 August) excluded, on a primary-source claim the primary source itself contradicts. The exclusion cited the calendarium's 9 August row as reading only "Vigilia, III classis.", no "Com." line -- checked against ONE of the three local Missal scans, "1962-06-23,...LT.pdf", an ELECTRONIC TRANSCRIPTION. The other two, PHOTOGRAPHIC scans of the actual 1962 Missale Romanum, both carry it: "missale-romanum-1962.pdf" calendarium, 9 August: "XVI d V 9 Vigilia, III classis, Commemoratio S. Romani Mart.", with the saint's own proper text elsewhere in the same scan ("Et fit commemoratio S. Romani Mar-") and its own back-of-book index ("Romani Mart., 9 augusti ... 621"). The transcription silently drops vigil commemorations generally (also missing there, present in both photographic scans: 7 August Donatus, 25 December Anastasia). 14 August's "St. Eusebius" is the identical shape (calendarium: "XI b XIX 14 Vigilia, II classis, Commemoratio S. Eusebii Conf.") and genuinely a DIFFERENT person from 16 December's "St. Eusebius, Ep. et Mart." (calendarium: "V XVII S. Eusebii Ep. et Mart., III classis.") -- a Confessor and a Bishop-and-Martyr, not the same saint duplicated. knownSpuriousComm (both entries) is removed outright; slugOverride gains "08-14/eusebius" -> "eusebius-confessor" so the two no longer collide by slug. Going forward: the photographic scans are the primary source; the electronic transcription is a convenience index only; where they disagree, the scan wins -- recorded in the generator's own comments, not just here. IMPORTANT 3+4: Thomas Becket (29 Dec) and Silvester (31 Dec) were silently promoted to class-4 by a hidden coupling. RG 68(d)/(e): "die 29 decembris, fit commemoratio S. Thomae Episcopi et Mart.; die 31 decembris, fit commemoratio S. Silvestri I Papae et Conf." -- both a bare "Commemoratio" with NO class of their own; the DAY they fall on (within the Nativity Octave) is II class, confirmed in the same calendarium row. refYearExplainsAbsence calls calendar.Compute and trusts a commemoration's own id-rank when the temporal day looks class-1/2-strong; after this task's own earlier fix promoted 26-31 December from class-4 to class-2 (RG 67/68), that trust flipped for these two from "not explained" to "explained" purely as a side effect of an unrelated temporal_ef.go change -- the generator's data inference reads the engine's own computed ranks, so a temporal_ef.go rank change can silently rewrite generated data. Fixed narrowly (6-31 December excluded from ever trusting the id-rank, citing RG 68(d)/(e) directly) and the coupling itself documented in refYearExplainsAbsence's own doc comment as a standing hazard for the next temporal_ef.go rank change, not just this one instance. Separately, the SAME function's doc comment overstated its own guarantee ("ANY class-1..4 saint would lose there") -- false for its Lent/Passiontide limb, where a III-class privileged feria does not beat a I- or II-class feast (RG 109(e) is privilege over an equal-or-lower class only) -- and the "commemoration id names the saint's TRUE rank" claim at the call site was falsified by its own worked example (St Blaise's id claims rank 4, and he is still correctly ruled RankCommemoration). Both rewritten to describe this as the rank-blind sampling heuristic it actually is, not a rubric evaluator. IMPORTANT 5: the Purification's own citation, strengthened. Three fixes to classOf's doc comment, no data change (the tag stays "lord", per round 1's own decision): the colitur cross-reference is removed (colitur bootstraps from lectio and was reading the same oracle a second time, not independent corroboration, and citing a sibling project's in-flight branch is not itself an argument); the rule that actually makes the occurrence pattern diagnostic is now named -- RG 91 entry 14 ("Festa Domini II classis") above entry 15 ("Dominicae II classis") above entry 16 ("Festa II classis... quae non [sunt Domini]"), each verified directly against the scan, not paraphrased; RG 120(b) is recorded as genuine primary-text counter-evidence ("Adhibetur color albus... b) B. Mariae Virg., etiam in benedictione et processione candelarum die 2 februarii" -- 2 February filed under the white-colour rule's OWN "B. Mariae Virg." heading, separate from 120(a)'s "Domini" heading), and RG 112(b) ("Officium, Missa aut commemoratio de dominica excludit commemorationem... de festo vel mysterio Domini, et vicissim") is cited as independently backing the empty commemoration list. A new committed fixture test replaces reliance on the report alone, since the deciding years (2 February on a Sunday) fall outside this repo's committed 2026-2027 oracle snapshot: TestPurificationBeatsFebruarySunday (internal/calendar/precedence_ef_repro_test.go), five independently fetched years. One of the years this reasoning is sometimes quoted against, 2036, is corrected in passing: 2 February 2036 is in fact a Saturday, not a Sunday (`date -d 2036-02-02 +%A`) -- checked here rather than repeated, 2042 used instead. Witnesses (internal/caldata/caldata_test.go): TestTridentineNamesPreservedAcrossRegeneration, TestTridentineRomanusAndEusebiusPresent (replaces TestTridentineNoSpuriousRomanus, whose own name asserted the now-corrected wrong claim). Pre-fix failures (captured against the committed pre-round-2 state, commit 50e3970): name.pl coverage = 0 entries, want >= 315 assumption-of-the-blessed-virgin-mary: name.pl = "", want the preserved Polish name romanus missing: the calendarium's photographic scans both carry "Commemoratio S. Romani Mart." on 9 August missing "eusebius-confessor" (08-14) internal/caldata/tridentine-calendar.ini regenerated from the ORIGINAL branch-point data (`git show 2386a45:...`), not from this session's own already-damaged intermediate file -- regenerating from an already-corrupted source would have preserved nothing, since the preservation mechanism can only preserve what is actually on disk when it runs. Verified directly (not merely re-tested): all 322 name.en/name.pl values byte-identical to the branch point; 15 rank fields and 2 class fields differ (the round-1 Lenten-rank and class-tag fixes, unchanged by this round); 5 new slugs added (agnes-secundo, boniface-martyr, eusebius-confessor, evaristus, theodore); 0 slugs removed.
* gen-sanctoral-ef: keep the Purification tagged lord -- the brief was wrong hereLukasz Kasprzak2026-08-122-14/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Disagreement with the task brief, found and corrected before landing, not after: the brief's defect 7 named the Purification (2 February) as "wrongly tagged lord... a BVM feast", citing the calendarium's own title, "IN PURIFICATIONE B. MARIAE VIRG." That citation is accurate -- but the tag's actual job is not naming or colour categorisation, it exists solely to drive one occurrence rule ("a II-class feast of the Lord takes an occurring Sunday's place outright"), and on THAT question the title is not the decisive evidence. Checked directly against missalemeum (this data's own oracle, live, not archival): the Purification takes a II-class Sunday's place OUTRIGHT, commemorations EMPTY (2014-02-02, 2020-02-02, 2025-02-02, all fetched fresh) -- the exact "festum Domini" pattern. Control: the Nativity of the BVM (8 September, an undisputed ordinary Marian feast) on a Sunday (2019-09-08) shows the opposite shape, the Sunday observed and the feast merely commemorated. The Purification's occurrence behaviour does not match an ordinary BVM feast's. Independent corroboration, found while comparing lectio's output against colitur's (the sibling engine this task's brief points to): colitur's own git history shows the identical retag, made and then reversed within the same review cycle it landed in -- cab8b07 "retag the Purification... as BVM, not Lord" (the brief's own reading), followed by 7d3b5ec "follow the oracle on the Purification" (the reversal, on the same live evidence independently re-derived here). That commit records the calendarium-title counter-evidence too and calls it "a genuinely contested point... a different project could reasonably rule the other way" -- not a clean-cut error either direction, but the weight of evidence for THIS tag's actual purpose favours keeping it lord. most-holy-name-of-mary (the OTHER entry the brief named) is untouched by this reversal and stays retagged away from lord -- its own occurrence behaviour matches the ordinary-BVM pattern, not contested by either project. internal/caldata/tridentine-calendar.ini regenerated; only the Purification's class field changes back (empty -> lord), 6 civil days 2005-2050 (every year 2 February falls on a Sunday: 2014, 2020, 2025, 2031, 2042, 2048) revert to matching what the branch point (and colitur's own current state) already had -- net zero change to PUBLISHED output on this specific point relative to before this task started, despite the intermediate wrong-then-reverted state along the way.
* calendar, precedence_ef: two more RG 91 gaps exposed by defect 4Lukasz Kasprzak2026-08-123-4/+101
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Found during the mandated 2005-2050 before/after verification (not one of the seven, but caused by defect 4's own fix, so fixed in the same pass rather than left as a self-introduced regression). Neither is a hypothetical: both are live in the fixed calendar and both were individually confirmed via cmd/lectio-ef-dump before being written up as tests. 1. RG 91 entry 4 (Immaculate Conception, Assumption BVM) sits ABOVE entry 6 (Sundays of Advent/Lent/Passiontide) -- unlike an ORDINARY I-class feast (entry 11, e.g. St Joseph), the Immaculate Conception (8 December) is not impeded by an Advent Sunday at all. Before defect 4, Advent Sundays were wrongly II class, so this was accidentally right (I beats II outright, no tie reached); once Sundays became I class the tie-break mattered for the first time, and precedenceEF had no branch for it -- the Sunday wrongly won. 2. RG 91 entry 5 (Vigil & Octave day of the Nativity) sits above entry 6 the same way, and its own gap was worse than a wrong winner: the Vigil of Christmas (24 December) falling on Advent IV, once defect 4 made that a genuine I-class tie, sent the Vigil into transferIfImpededEF's forward walk -- which has no way to re-place a transfer crossing the Dec 31/Jan 1 boundary (celebrationDate re-resolves a fixed date using the YEAR OF THE DAY BEING QUERIED, so a walk landing in the following January can never match the query that produced it). The Vigil did not move to the wrong day; it vanished for the whole year, for every year 24 December is a Sunday (2006, 2017, 2023, 2028, 2034, 2045). Both fixed the same way as the existing II-class-feast-of-the-Lord bonus in precedenceEF (a one-line precedence adjustment keyed on slug), generalised into a single beatsClass1Sunday helper covering both RG 91 entries. A separate, unrelated bug surfaced by the SAME verification pass and fixed alongside it: transferIfImpededEF's destination check reused precedenceEF's tie-break BAND to decide "is this day I or II class", but band encodes a different question (which of two EQUAL-class candidates wins a tie) -- an ordinary, non-Sunday II-class temporal candidate YIELDS under defect 2's own fix (band 5), even though it is genuinely II class. A day within the Octave of the Nativity (26-31 Dec, RG 67) is exactly such a day, so band<=3 alone let a transfer wrongly land inside it (a real reproduction: "vigil-of-christmas" would have landed on 29 December 2006 instead of vanishing outright, caught while tracing the entry-5 bug above). Replaced with a direct class test (isHighClass), which is both correct and simpler -- it no longer needs the Sunday flag at all for this particular check. Witnesses (precedence_ef_repro_test.go): TestImmaculateConceptionBeatsAdventSunday, TestVigilOfChristmasSurvivesAdventSunday. Fail before this commit with: 2013-12-08 observed = "ef-advent-sunday-2" want immaculate-conception-of-the-blessed-virgin-mary (RG 91 entry 4 beats entry 6) 2006-12-24 observed = "ef-advent-sunday-4" want vigil-of-christmas (RG 91 entry 5 beats entry 6; must not vanish) (full set: 2013/2019/2024 for the first, 2006/2017/2023/2028 for the second)
* scripts/gen-sanctoral-ef: fix rank inference, dedup, and class tagging ↵Lukasz Kasprzak2026-08-122-352/+190
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (defect 7) Six root-cause fixes to the generator, all in scripts/gen-sanctoral-ef.go, then a full regeneration of internal/caldata/tridentine-calendar.ini (323 -> 325 entries) against live missalemeum data: 1. Rank misinferred as "commemoration". A saint never OBSERVED in any of the six reference years was unconditionally hardcoded to RankCommemoration. 15 III-class feasts, all falling 6 March - 5 April, were always demoted by Lent's own privileged ferias in every reference year -- a sampling artifact, not their true rank. Fixed properly, not by hardcoding the 15: the commemoration object's own id names the SAINT's true rank (idParts already extracted it; only the colour half was kept before). But trusting that rank unconditionally for every commemoration-only entry over-corrected: some saints (St Blaise, St Canute, and others) really are without an independent Mass in the 1960-reformed books, demoted even on an ordinary, unprivileged day -- live-confirmed against missalemeum, not inferred. refYearExplainsAbsence distinguishes the two: the id's rank is trusted only when every reference year's OWN temporal day (ignoring sanctoral data entirely) was already strong enough to explain the demotion -- I/II class, an Ember day, or a privileged Lent/Passiontide feria. A single unprivileged-day counter-example keeps RankCommemoration. 2. Two silent slug collisions. entries (the generator's global map) is keyed by slug alone; two different fixed dates whose English titles are identical ("St. Agnes" 21 Jan and 28 Jan; "St. Boniface" 5 June and 14 May) silently dropped the second one add() ever saw. Fixed at the dedup itself: a same-slug collision on a DIFFERENT date is now disambiguated (a small curated slugOverride for these two -- 28 January is the traditional "secundo" commemoration of the same saint; 14 May's Boniface is a different martyr from 5 June's Boniface of Mainz) rather than dropped. 3. Two early-exit bugs in harvestDate, both replaced with `continue`: returning on the FIRST reference year that showed an observed office discarded commemorations only visible in a LATER year (St Theodore, 9 November, missing only from 2025, the first year tried); the Christ-the-King skip used to abandon the whole date outright instead of only that one movable year (St Evaristus, 26 October, invisible because 2025 -- tried first -- happens to be the one reference year Christ the King lands there). 4. A new class of artifact the fix for (2) exposed rather than caused: a movable-transfer feast displayed on whatever civil date it actually landed on in one reference year (St Joseph pushed to 20 March by a Sunday of Lent; the Annunciation deferred past Holy Week; All Souls moved to the Monday; St Matthias shown on the 25th in a leap year) was being harvested as if it were a genuine fixed-date office for THAT transferred date. idHomeDate compares info.id's own embedded date against the mmdd being queried (live-confirmed: 2023-03-20's id is "sancti:03-19:1:w") and skips a mismatch. 5. classOf's substring matching, checked against the calendarium's own verbatim titles: "purification" was never a Lord check at all (calendarium "IN PURIFICATIONE B. MARIAE VIRG.", a BVM feast) and is removed; "holy name" alone matched both "Holy Name of Jesus" and "Most Holy Name of MARY" (calendarium "Sanctissimi Nominis Mariae") and is now conditioned on the title not also naming Mary; "baptism" is a new case -- "Commemoration of the Baptism of the Lord" (13 January) ends "of THE Lord", not "of OUR Lord", the only suffix classOf checked, so it was missing the marker entirely. 6. One curated exclusion, NOT a generator bug: missalemeum's own "St. Romanus" commemoration on 9 August has no calendarium support (the row there reads only "Vigilia, III classis.", no "Com." line) -- an upstream data quirk, recorded in knownSpuriousComm rather than silently reproduced. "St. Eusebius" on 14 August (already known, register M6) gets the same treatment for the same reason. Witnesses (internal/caldata/caldata_test.go): TestTridentineClassOfLord, TestTridentineLentRankNotCommemoration, TestTridentineGenuineCommemorationStaysCommemoration, TestTridentineNoMissingEntries, TestTridentineNoSpuriousRomanus, TestTridentineNoTransferArtifacts, plus TestTridentineLoads' own Purification class assertion corrected from its previous (wrong) "lord" expectation. All fail against the pre-fix ini with messages such as: purification-of-the-blessed-virgin-mary: class = "lord", want "" sts-felicitas-perpetua: rank = "commemoration", want class-3 (not commemoration) missing "theodore" (11-09) romanus present: the calendarium's 9 August row has no Com. line to support it See the report for the full set. internal/caldata/tridentine-calendar.ini is regenerated output (go run scripts/gen-sanctoral-ef.go against live missalemeum data), not hand-edited.
* test(ef): un-gate the oracle test now the seven defects are fixedLukasz Kasprzak2026-08-121-10/+0
| | | | | | | | | Remove the LECTIO_EF_ORACLE_STRICT gate added when the strengthened rank/colour assertions first landed. All seven defects are fixed as of the previous four commits; TestOracleEF now passes unconditionally as part of the normal go test ./... run, with its small, cited allow-list (four entries, none of them one of the seven) doing the only remaining filtering.
* precedence_ef: a II-class privileged feria yields to a feast (defect 2)Lukasz Kasprzak2026-08-123-22/+110
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | precedenceEF's equal-class tie-break only distinguished "ordinary III/IV-class feria yields" from "everything else wins" -- Sundays, named feasts, Lent/Passiontide ferias, AND II-class privileged ferias (the Ember days, the late-Advent 17-23 Dec ferias) were all bucketed into the same "wins its tie" branch. RG 91 disagrees at class 2: entry 15 (Sundays) sits ABOVE entry 16 (II-class feasts of the universal Church), so a Sunday wins -- but entry 16 sits ABOVE entry 18 (II-class ferias, including the Ember days), so those FERIAS yield instead, the opposite direction from a Sunday. St Matthew (21 September, II class) was losing to the September Ember Wednesday every time the two coincided; St Thomas (21 December, II class) was losing to an ordinary late-Advent feria the same way once the previous commit correctly promoted those ferias to II class. The fix distinguishes a II-class Sunday from a II-class feria using a Sunday flag that already existed on `candidate` (used by the OF path) but was never wired up for EF: temporal_ef.go's efCel always set Sunday: false, even on an actual Sunday. A new efSunday helper (efCel plus the flag) replaces the three efCel calls inside temporalEF's Sunday branch, and computeEF now propagates td.Sunday into the day's temporal candidate. precedence_ef_test.go's own pre-existing witness ("at equal class, the temporal office wins") encoded exactly the bug: a bare class-2 temporal candidate with no Sunday/season information, standing in for "the temporal office" in general. It is rewritten into two explicit cases (Sunday wins its tie; a privileged feria yields) plus the existing Lent/Passiontide-vs-ordinary III/IV-class case restated explicitly rather than left implicit. Witness (precedence_ef_repro_test.go): TestMatthewBeatsSeptemberEmberWednesday. Fails before this commit with: 2016-09-21 observed = "ef-september-ember-wed" want matthew (RG 91 entry 16 beats entry 18) 2022-09-21 observed = "ef-september-ember-wed" want matthew (RG 91 entry 16 beats entry 18) With this commit, all seven named defects are fixed: LECTIO_EF_ORACLE_STRICT=1 go test ./internal/calendar/... -run TestOracleEF passes (0 unallow-listed rank/colour mismatches over 730 days). The gate stays in place for this commit; a following commit removes it.
* calendar: RG 96 transfers must skip II-class days too (defect 1)Lukasz Kasprzak2026-08-122-12/+86
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | transferIfImpededEF's forward walk only skipped days whose temporal office was I class. RG 96 requires skipping to "the next following day that is not I or II class" -- II class also blocks. 2011: the Sacred Heart (Friday after the Corpus Christi octave) falls on 1 July and impedes the Precious Blood, also fixed on 1 July. The walk landed the Precious Blood on 2 July, displacing the Visitation (II class, fixed) outright, and never reached 3 July (an ordinary II-class Sunday) at all. Two changes were needed together, not one: 1. The walk's continuation threshold widens from "temporal band <= 2" to "<= 3", which is what actually captures every II-class temporal day (an ordinary Sunday, or a II-class named feast) as well as every I-class one -- band 3 is precedenceEF's own value for any non-Sunday-privileged II-class temporal candidate, unchanged by this commit. 2. A FIXED sanctoral II-class feast (the Visitation) has no temporal band at all -- the walk needs to also check whether some OTHER fixed celebration, class 1 or 2, already resolves onto the candidate day. computeEF now builds this check once (occupiedByRank, parameterised by which ranks count) and passes it in. Widening (1) alone is wrong on its own: a class-1 feast is NEVER actually impeded by a mere II-class day (I class always outranks II class outright, no tie exists) -- naively applying the wide "<=3" threshold to decide whether the ORIGINAL date is impeded, not just where to land afterwards, wrongly bumped unimpeded feasts landing on an ordinary Sunday (caught while testing this: All Saints, 1 Nov 2026, a Sunday that year, was wrongly pushed to 3 Nov). transferIfImpededEF now uses two different thresholds for two different questions -- class 1 only to decide IF a candidate is impeded at all, class 1 OR 2 to decide where an already-impeded one may land -- see its own doc comment for the full reasoning. Witness (precedence_ef_repro_test.go): TestTransferSkipsBothIAndIIClass. Fails before this commit with: 2011-07-02 observed = "precious-blood-of-our-lord-jesus-christ" want visitation-of-the-blessed-virgin-mary (RG 96: the Precious Blood must skip past it, not displace it) 2011-07-04 observed = "ef-time-after-pentecost-3-monday" want precious-blood-of-our-lord-jesus-christ (RG 96: first day that is neither I nor II class)
* temporal_ef: Sunday ranks, Rose Sundays, Holy Thursday whiteLukasz Kasprzak2026-08-123-18/+200
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Four fixes to internal/calendar/temporal_ef.go, all found by the strengthened oracle test (previous commit): 1. Sunday ranks (defect 4). The generic Sunday branch assigned class-2 to every Sunday except Advent I. RG 11-12 / RG 91 entry 6: every Sunday of Advent and every Sunday of Lent is I class (as are Passiontide's own two Sundays and Low Sunday, already correct via their named-feast cases). Fixes St Joseph wrongly taking a Sunday of Lent (defect 3, precedence_ef_repro_test.go's TestJosephYieldsToSundayOfLent) as a direct consequence: once Lent Sundays are I class, Joseph (also I class) no longer wins the tie outright and correctly transfers to the 20th via the existing RG 96 walk -- no separate code change was needed for defect 3. 2. Rose (defect 5). efColour had no Rose case at all; Gaudete (Advent III) and Laetare (Lent IV) now get Rose on that Sunday specifically (RG 131: rose vestments may be used "in Officio et Missa diei dominici tantum", for that Sunday's Office and Mass only), not the surrounding Sundays. 3. Holy Thursday's colour (defect 6). RG 128(b) names the Missa in Cena Domini as a whole-Mass exception to Passiontide's violet; RG 122 states the same fact affirmatively, in the White section itself. Good Friday and Holy Saturday, either side, are unchanged (still violet -- their own black/no-colour treatment is a separate, unmodelled gap, noted in precedence_ef.go's own doc comments). 4. Beyond the seven, found by the same strengthened test and fixed for the same RG 91 entry 18 reason defect 2 (next commit) relies on: the Ember days of Lent had no case in efEmberSlug at all (only September and Advent did), so they fell through to the ordinary III-class Lenten-feria rank instead of the II class RG 91 entry 18 requires. The late-Advent ferias (17-23 Dec, RG 91 entry 18) and the days within the Octave of the Nativity (26-31 Dec, RG 67-68) had no elevation at all, defaulting to III/IV class. All three are one-line, unambiguous, primary-cited additions to the same rank logic already being touched here -- left unfixed, the strengthened oracle test could only reach green by allow-listing them as if they were defensible divergences, which they are not. Witnesses (temporal_ef_test.go): TestTemporalEFSundayRanks, TestTemporalEFRoseSundays, TestTemporalEFHolyThursdayColour, TestTemporalEFEmberDayRanks. All fail before this commit; see the report for the exact pre-fix failure messages.
* test(ef): strengthen the oracle test to assert rank and colourLukasz Kasprzak2026-08-122-2795/+5201
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | internal/calendar/oracle_ef_test.go asserted Season only. lectio's own EF oracle test comment said as much ("rank/colour are reported informationally"), which is exactly why several precedence/colour defects in precedence_ef.go and temporal_ef.go shipped without ever failing a test: the suite was green while the observed office's own rank and liturgical colour could be wrong. Rebuild the oracle from the committed missalemeum snapshot (sources/snapshot.tar.gz, missalemeum/en/YYYY-MM-DD.json, 2026-01-01 .. 2027-12-31, 730 days) instead of a live 2025-2026 fetch, via a rewritten scripts/build-oracle-ef.sh -- offline, reproducible, and correctly separating info.rank/info.colors from info.id (whose embedded rank is the rank of the propers REUSED that day, not the day's own rank -- e.g. 2026-01-02 is a class-4 feria carrying id "sancti:01-01:1:w" because it reuses the Circumcision's propers). info.colors is an array (14 of 730 days carry two values -- Gaudete/ Laetare "pv", Palm Sunday "rv", Good Friday "bv", Holy Saturday "vw"), so the new Colour assertion is membership, not equality. The strengthened assertions immediately expose several real defects (rank mismatches on every Advent/Lent Sunday, the Ember days, the late-Advent and Christmas-octave ferias, and more) -- that is the point, this is the regression net subsequent commits fix against. Since the repo's convention is go test ./... green at every commit, TestOracleEF is gated behind LECTIO_EF_ORACLE_STRICT=1 for now rather than landed red; a later commit removes the gate once the fixes are in. Season alone stays green throughout (unchanged, always was). A small, cited allow-list (efAllowList) is included from this commit: genuine, defensible divergences unrelated to the fixes ahead of it -- RG 91 entry 27's un-built BVM Saturday Office, the pre-existing 6-13 January Christmastide/time-after-Epiphany season-boundary divergence, missalemeum's own RG 33 gap on a Sunday 9 August, and one collision (St Joseph vs the Friday of Passion Week, 2027) left explicitly unresolved even by the sibling project's much deeper primary-source pass. None of the four is one of the seven defects this branch fixes.
* calendar/readings: report Sunday as its own display rank, not solemnityLukasz Kasprzak2026-08-057-6/+103
| | | | | | | | | | | | | | | | The Ordinary Form's Table of Liturgical Days treats Sunday as its own category, never a solemnity. temporal.go's sundayDay() already marks these days distinctly from named solemnities (Class stays unset, unlike solemn()'s ClassLord); internal/readings/offline.go now reads that existing signal to relabel the REPORTED rank to "sunday" for ordinary and privileged-season Sundays alike, leaving Celebration.Rank, ofRankOrder and all precedence untouched. Named solemnities landing on a Sunday (Easter, Pentecost, ...) and feasts of the Lord (Holy Family) keep reporting their own rank. The 1962 form is untouched. Added calendar.RankSunday (display-only, deliberately excluded from ofRankOrder), the i18n Sunday/niedziela words, and a test pinning the exact dates from the original bug report.
* readings: PartIDs(new) stops declaring aklamacja, which the engine never emitsLukasz Kasprzak2026-08-052-2/+14
| | | | | | | | | | | | | | | | | | | | | caldata.go:42 parses only first/psalm/second/gospel out of the lectionary data, so no OF reading ever carries Part == "acclamation". PartIDs("new") listed aklamacja anyway, so the app built a checkbox from it that filters an ID that never appears -- a dead control, same defect class the app previously shipped for the whole 1962 form. ofPartOrder stays the full five-ID set: it also drives render.LocalizeHeading's label matching, where a scraped heading can still read "Aklamacja" even though this engine's own readings never produce that section. PartIDs now draws from a new, narrower ofEmittedPartOrder instead. Rewrote TestPartLabelsMatchesWhatTheEngineEmits's OF half: it compared PartLabels("of") to a hand-copied duplicate of ofPartOrder, asserting a declaration against itself, which cannot fail for this class of bug. It now sweeps Days over calendar year 2026 and asserts PartLabels("of") matches the observed part-ID set exactly (0.5s). Confirmed red against the pre-fix code, green after.
* i18n: pin the Polish part labels; cross-reference the part-ID ordersLukasz Kasprzak2026-08-043-0/+48
|
* readings: 1962 part labels become i18n data; export PartIDsLukasz Kasprzak2026-08-035-13/+90
|
* i18n: correct rank doc comments and pin the Polish wordingLukasz Kasprzak2026-08-034-6/+36
|
* liturgy: carry the observed rank on DayInfoLukasz Kasprzak2026-08-033-0/+36
|
* i18n: drop the colour word table, it has no consumerLukasz Kasprzak2026-08-035-36/+1
|
* i18n: rank and colour vocabulary tablesLukasz Kasprzak2026-08-035-2/+124
|
* caldata(ef): trim redundant trailing ', Apostołów' from Peter&Paul basilicasLukasz Kasprzak2026-07-301-1/+1
|
* caldata(ef): fix Apostołow -> Apostołów typo (Simon & Jude)Lukasz Kasprzak2026-07-301-1/+1
|
* caldata(of): capitalise the Apostoł/Ewangelist title in Polish namesLukasz Kasprzak2026-07-301-6/+6
| | | | | | | | | | Per the review, the apostle title was split ("św. X, apostoła" vs ", Apostoła") and the evangelist title too (Mark/Matthew already "Ewangelisty", John/Luke lowercase). Standardise both high author-ranks to uppercase -- all apostles "Apostoła"/"Apostołów", all four evangelists "Ewangelisty" -- matching the entries that were already capitalised. The functional titles (biskupa, prezbitera, męczennika, doktora, dziewicy...) stay lowercase, as they consistently were.
* caldata(of): fix Philip & James Polish name (was Queen of Poland)Lukasz Kasprzak2026-07-291-1/+1
| | | | | | | | | | | The universal [saints-philip-and-james-apostles] entry carried name.pl = "Najświętszej Maryi Panny, Królowej Polski" -- Our Lady Queen of Poland, the Polish NATIONAL feast that supersedes Philip & James on that date, pasted in during the pl backfill instead of translating the universal celebration. name.la and the readings correctly say Philip & James. Set name.pl = "świętych Apostołów Filipa i Jakuba" (matching the "świętych Apostołów Piotra i Pawła" style). Scanned the rest of both universal calendars for other national-feast contamination -- none.
* calendar: name the liturgical form fully in the printed title; v0.45.1v0.45.1Lukasz Kasprzak2026-07-296-3/+16
| | | | | | | | | | | The exported month calendar's title showed the terse dropdown word ("August 2026 — traditional"). Spell the form out: "traditional roman calendar" / "novus ordo calendar". Add dedicated i18n labels CalModern/CalTraditional (translatable like the rest of the chrome; pl = "kalendarz Novus Ordo" / "tradycyjny kalendarz rzymski") rather than overloading the short OptModern/OptTraditional the settings dropdown uses. Bump version to 0.45.1.
* release: bump version to 0.45.0v0.45.0Lukasz Kasprzak2026-07-291-1/+1
| | | | | | | | The version constant sat at 0.44.0 while 44 commits landed on top of it: the engine-flawlessness pass, the localization + bible-corpora-split epic (any-language day/saint names, embedded-chrome-as-data, EF Polish sanctoral 322/322), the web UI rework, the EF Christmas-ferial name fix, and the cli test-config isolation. Mark the release as 0.45.0.
* test(cli): isolate the suite from the real ~/.config/lectioLukasz Kasprzak2026-07-291-0/+26
| | | | | | | | | | | | | | The ref/rand cli tests assume English book abbreviations ("Jn 3:16"), but with no LECTIO_CONFIG set they read the developer's real user config. On a machine whose config has ui_language = pl (sigla_style = auto -> Polish dialect), "Jn" is not a valid abbreviation and TestRefSingle, TestRefEnglishDialect, TestRefRejectsPolishAbbrevInEnglish, TestRefCompare and TestRandVerse fail -- while passing on a clean CI. Add a package TestMain that points LECTIO_CONFIG at a throwaway temp path, forcing built-in defaults for every cli test and guaranteeing the suite never reads or writes the real user config. Suite now green on a Polish config too.
* caldata(ef): finalise the 4 review-flagged Polish namesLukasz Kasprzak2026-07-291-5/+1
| | | | | | | | | | Reviewed the four EF names missalemeum never returns. George (Martyr), Stanislaus (Bishop and Martyr), and Zephyrinus (Pope and Martyr) were correct as best-guessed -- flags cleared as-is. Alexander & Companions had enumerated only three of the martyrs (omitting Juvenal); since the English name is the shortened "& Companions", match it with the faithful Polish "śś. Aleksandra i Towarzyszy, Męczenników". No more # review-pl flags; all 322 EF names stand.
* naming(pl): localise the Christmas-season name in composed ferial namesLukasz Kasprzak2026-07-291-0/+2
| | | | | | | | | | | | EF ferials in the Christmas season rendered with an English season word in a Polish UI -- "Poniedziałek Christmas" (2026-01-05) -- because the Polish [seasons] table had no "christmas" key, so season() fell back to the English title-cased slug. Add christmas = "Narodzenia Pańskiego" (and the empty season_prep entry), matching the existing genitive style (Adwentu, Wielkiego Postu). Now "Poniedziałek Narodzenia Pańskiego". Verified across the whole Christmas-Epiphany window for both forms; English output unchanged.
* web(settings): drop the terminal "versions" field; it is CLI-onlyLukasz Kasprzak2026-07-292-8/+7
| | | | | | | | | | | | | The settings page showed two near-identical version checkbox rows -- "versions" (the terminal compare set) and "web_versions" (the web page's own default ticks). The first only affects the CLI, so editing it from the web is pointless and was actively confusing (both rows list the same wuj/vul/grb/drb boxes). Remove the "versions" row from the form and stop reading it in settingsPost, so cfg.Versions is preserved from the live config (same pattern as offline/width/pager). The web settings now expose only what the web uses: default_version and web_versions.
* web: pin settings/download to the top-right corner, never wrap it downLukasz Kasprzak2026-07-291-2/+15
| | | | | | | | | | | | | | Per the target layout: the utility cluster (settings + the pobierz disclosure) must hold the top-right corner on the same row as the reader link, not drop onto a second full-width line below the controls. Make #controls itself non-wrapping so the side cluster keeps the corner; the left controls (.controls-main) absorb any tightness by wrapping their OWN items onto a further line (min-width:0 lets them shrink). At the 64rem page width the whole bar cannot fit every left control AND the corner cluster on one line, so a trailing control (layout) wraps beneath -- the intended block-on-the-left, cluster-in-the-corner shape. A tighter column gap buys a little room; on phones (<=40rem) the bar wraps normally.
* web: reader link to the left, downloads into a "pobierz" disclosureLukasz Kasprzak2026-07-293-13/+88
| | | | | | | | | | | | | | | | | Finish the top-bar rework. The reader entry point now leads the controls bar on the far left (it was in the right-hand cluster); settings stays in the top-right cluster. The flat "download: txt md pdf · kalendarz" strip becomes a single "pobierz" summary that opens a small floating panel with two rows: - a month calendar with its own month + year <select> pickers (localised month names, both pre-selected from the shown date) and a PDF button that hits /calendar?month=YYYY-MM; - the shown day's readings as txt/md/pdf, labelled with the date. The panel is absolutely positioned under the link so opening it doesn't reflow the bar. indexData gains MonthOpts/YearOpts (a calOpt list); the year picker is a small window around the shown year.
* caldata(ef): add Polish names to the traditional sanctoralLukasz Kasprzak2026-07-291-0/+326
| | | | | | | | | | | | | | | | | | The EF (traditional) calendar showed English memorial names even with the UI switched to Polish, because tridentine-calendar.ini carried only name.en. Add name.pl to all 322 sanctoral entries. Source: missalemeum.com's Polish propers (/pl/api/v5/proper/DATE), the authoritative Polish traditional-calendar naming -- paired to each entry by the celebration id shared across its /en/ and /pl/ responses, fetched across two years so saints superseded by a Sunday in one year are still resolved. 318 entries matched that way; a missalemeum source typo ("Dokotra" -> "Doktora") is corrected in the two it affected. The remaining 4 -- George, Alexander & Companions, Stanislaus, Zephyrinus -- are never returned by missalemeum in the fetched years (superseded every time); they carry a best-guess Polish name tagged with a "# review-pl" comment for a human to verify.
* web: move lectionary + mono to settings only; make reader link prominentLukasz Kasprzak2026-07-292-12/+11
| | | | Lectionary becomes settings-only (kept as a hidden field so readings/export/calendar still use the configured value); mono toggle removed (settings has it). The reader link is uppercased + bold as the primary action.
* web: pin the utility cluster to the top-right of the controls barLukasz Kasprzak2026-07-292-3/+17
| | | | | | | Wrap the essential controls in a single .controls-main block that wraps internally, so reader/settings + downloads stay at the TOP-right instead of dropping to a second row. #controls (index only) becomes top-aligned; the reader's .controls form is untouched.
* web: declutter the UI, fix date arrows, red * for bookmarked verses in readerLukasz Kasprzak2026-07-2910-82/+93
| | | | | | | | | | | | | | | | | | | | | | | | | Daily page (index.html): - Date arrows now step the date input client-side and dispatch its change, so they move relative to the CURRENT day and update the shown date (they were stuck one step from the initial date, computed server-side). - Theme picker removed (theme lives only in /settings now); bookmarks link removed (bookmarks belong to the reader, not the daily readings). - reader/settings nav + the download links move to a right-aligned .controls-side cluster; essential controls (date, lectionary, versions, parts, layout, mono) stay on the left. mono stops its change bubbling so it no longer refetches. Reader (reader.html + RenderPassage): a bookmarked verse now shows a red "*" (end of line in columns, after the verse number interlinear). Threaded a marked set (keyed "chap:verse") through the reader render path only; the daily RenderReadings path is untouched. Settings (settings.html): Save button moved to the top; removed offline (dead), width and pager (CLI/TUI-only, no web effect) -- their config values are preserved since the handler no longer reads/zeroes them. Footer: source/licence centred. Web tests + full suite green both build modes.
* tui(reader): flag bookmarked verses with a red * in the reading paneLukasz Kasprzak2026-07-292-7/+71
| | | | | | | A verse that has a bookmark now shows a red "*" at the end of its last line, so saved verses are visible while reading. The set of bookmarked verses for the current book+chapter is refreshed on chapter load, on save, and on returning from the bookmarks list (one store read each). Test covers the flag + render.
* tui(reader): filter bookmarks by tag, and show tags in the listLukasz Kasprzak2026-07-295-45/+157
| | | | | | | | | Bookmarks stored tags but the list neither showed them nor let you use them. Now each row shows "Ref — note #tag1 #tag2", and `/` opens a live tag filter (case-insensitive substring over a bookmark's tags): type to narrow, Enter keeps the filter while j/k navigate the filtered list, Esc clears it. Navigation, open and delete all act on the visible (filtered) list. Reuses the store's existing tag data; help keybar (en/pl) updated; test covers filter/keys.
* bible(wuj): strip leaked verse numbers from the deuterocanon textLukasz Kasprzak2026-07-291-3797/+3797
| | | | | | | | | | | | | | ~3,800 verses carried their own verse number at the start of the text (a biblia.info.pl harvest artifact concentrated in the deuterocanonical books -- Sirach, 1-2 Maccabees, Wisdom, Judith, Baruch, at 90-98% of each, plus 3 strays in Ezra/Proverbs). E.g. Sirach 4:4 read "4 Nie odrzucaj..." instead of "Nie odrzucaj...". It passed every check: verse counts are unaffected, and the verses aren't short. Strip a leading token only where it exactly equals the verse number (so a genuine "40 dni" in a non-matching verse is untouched), and only when text follows. 3797 verses fixed; 35,810-row parity preserved, no verse emptied, no new warnings; --corpus-check wuj still clean; make test green.
* bible(corpus-check): warn on a verse present but stubbed vs the VulgateLukasz Kasprzak2026-07-294-4/+59
| | | | | | | | | | | | | | | | | | The count-based checks (gap, duplicate, missing chapter) only see a verse's presence, so a verse that IS there but truncated -- a lost opening line, a merge artifact, the exact class that lost 44 psalm openings and Acts 6:5 from the old Wujek scrape -- passes silently. Add a warning for it, compared CROSS-CORPUS to the aligned Vulgate verse (never within the chapter). That is deliberate: a genuinely terse verse ("Non occides", "Jesus wept") is short in the Vulgate too, so it is not flagged; only a corpus stub against a substantial Vulgate verse fires (corpus <12 chars, <1/4 of a Vulgate verse >=40). Rune-counted (script-agnostic) and skipped on the Psalms when the corpus renumbers them (psalm_system != vulgate), where per-verse alignment with the Vulgate would not hold. Warning only, never an error. Zero false positives across vul/wuj/drb/grb; a `stub` testdata fixture (Genesis 1:1 = "x") exercises a real hit.
* test(bible): skip corpus-dependent tests when optional corpora aren't embeddedLukasz Kasprzak2026-07-2910-101/+287
| | | | | | | | | | | | | | | | | | | | | | | | Since 51c0f4e split the corpora (only vul embedded by default; wuj/drb/grb behind -tags fullbible), `go test ./...` on the default build was red across six packages -- every failure was a test assuming an optional corpus is present. Guard those assertions with a skip keyed on bible.Meta(code), so they run under -tags fullbible and skip -- not fail -- on the default vul-only build. Mixed tests are split into subtests so the always-embedded vul assertions and pure logic (pl->vul fallback, explicit passthrough, bt-rejection, i18n labels) keep running on both builds. Test-only change; no product code or corpora touched. - internal/bible: TestVerses, TestLookup, TestCorpusBooks, TestChapters, TestGrbNoApparatusMarkers, TestCrossChapterRange* (requireCorpus helper). - internal/cli, config, render, tui, web: the same pattern for their corpus-dependent tests. - Fixes an index-out-of-range panic in internal/tui's reader tests that was aborting the package binary and masking 3 further corpus-absence failures (TestReaderBookmarkFlow, TestReaderChapterJump, TestReaderRemembersPlace). Verified: `go test ./...` and `go test -tags fullbible ./...` both green (0 FAIL); guards active only on the default build (29 skips vs 1 unrelated pre-existing); gofmt and go vet clean.
* bible(grb): restrict to the Vulgate canon; restore Hosea and ZechariahLukasz Kasprzak2026-07-291-26696/+22951
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | grb failed corpus-check outright: 15 errors, and two whole books absent from lectio at runtime with no error and no warning. Upstream grb is a standalone Septuagint reader carrying 87 books. lectio needs one uniform canon, so scripts/gen-grb-lectio.py derives the 73 books vul has rather than forking -- upstream stays intact and keeps everything. Eleven books have no Vulgate counterpart and are dropped, including 2 Esdras, which upstream's README explains IS Ezra + Nehemiah under the Septuagint's name; verified byte-identical, so nothing is lost. Five books ARE canonical under other names and are remapped, and the verse counts show which witness the Vulgate follows -- Jerome translated Theodotion, not the Old Greek: Bel and the Dragon (Theodotion) 42 = vul Daniel 14 (42) exact Bel and the Dragon (LXX) 37 no Sussana (Theodotion) 64 = vul Daniel 13 (65) Sussana (LXX) 37 no Letter of Jeremiah 73 = vul Baruch 6 (72) Wisdom of Solomon 435 = vul Wisdom (439) Upstream's plain "Daniel" is the Old Greek and is missing chapter 4 outright, so Theodotion supplies Daniel throughout: complete, and the tradition the lectionary actually cites. lectio thereby GAINS Wisdom, Daniel 4, Daniel 13-14 and Baruch 6 in Greek rather than losing them. Three upstream defects are repaired in transit: * 408 rows carried 5 fields, not 6 -- a lost tab fused the book number and chapter ("281" = book 28, chapter 1). Every one was in Hosea or Zechariah, and neither book had a single well-formed row, so bible.go skipped both entirely. Hosea (197 verses) and Zechariah (211) are back. * 5 merged verse labels ("27-28") that strconv.Atoi turns into verse 0. * A UTF-8 BOM welded to the first book name, making "Genesis" a phantom 74th book matching nothing. The SBLGNT apparatus sigla are stripped, as TestGrbNoApparatusMarkers requires; regenerating from raw upstream reintroduces ~8700 of them. grb now passes. The remaining warnings are the Septuagint being itself -- Jeremiah is LXX-numbered (grb 33:2 is the Vulgate's 26:2), Esther integrates its additions into chapters 1-10, LXX Malachi has three chapters, and 3 Kingdoms carries supplements like 10:22a that upstream stores as a duplicate verse 22. Silencing those would mean deleting real Greek text.
* bible(drb): renumber three chapters, fill eight absent versesLukasz Kasprzak2026-07-291-4618/+4626
| | | | | | | | | | | | | | | | | | | | | | Eight corpus-check warnings, of two kinds. Three chapters (Exodus 40, Genesis 49, Song of Solomon 1) held exactly as many verses as the Vulgate but numbered with a gap. The count pins the mapping, so renumbering 1..N is safe and changes no text. Five chapters were genuinely short. The missing verses came from get.bible's douayrheims -- the same public-domain source and API scripts/gen-deutero.py already uses for this corpus, so no new provenance is introduced. Scope was deliberately narrowed to the flagged chapters. A first pass over every chapter shorter than the Vulgate pulled in 938 verses, 820 of them in Psalms -- but drb.ini declares psalm_system = drb, a different numbering, so matching by Vulgate verse number there would have inserted the wrong text under the wrong numbers across the Psalter. One warning remains and is not a defect: Baruch 6 runs 1-72 with verse 37 absent in drb and in get.bible alike, a genuine Douay/Vulgate versification difference faithfully represented.
* bible(wuj): rebuild from source, repair to exact Vulgate parityLukasz Kasprzak2026-07-291-362/+314
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Wujek corpus was missing text and mis-numbering what it had: 453 corpus-check warnings, 8 absent chapters, 84 duplicate rows, and 357 chapters holding fewer verses than the Vulgate. Most of it was never a sourcing problem. The original harvest of biblia.info.pl assumed one verse is one <p>, but many psalms print the superscription in the anchored paragraph and the psalm's opening line in an unanchored one behind a drop cap -- so 44 psalms lost their first line, and Acts 6:5 and others went the same way. Re-harvested with the anchor treated as a verse START rather than a whole verse (scripts/scrape-wujek.py), which also had to cope with four anchor shapes across books, hidden page markers opening paragraphs mid-verse, chapter ids that are simply wrong (Mark labels 87 anchors "15:*" across chapters 14-16), and Psalms heading its divisions "Psalm CXVII" where every other book says "Rozdzial N". Structure was then repaired against the Clementine Vulgate, by hand where a rule would have guessed: * The Acts 5 interleaved three streams -- Acts 4:27-37 duplicated, the real 5:1-37, and 5:38-39 mislabelled 28-29. Verified against the Latin, the duplicates dropped, the two renumbered. Acts 4:27 kept the site's own wording in place of a 1962 reading, removing a seam. * The site heads psalms by Hebrew division; its "Psalm 114" is two psalms. Split into Vulgate 113:9-26 and 114:1-9, confirmed at all four boundaries. * A corrupt anchor for 1 Chronicles 9:11 pushed 34 paragraphs of genealogy into chapter 10. Counts corroborate: 10 + 34 = 44 verses, remainder 14, both exactly the Vulgate's. * 16 chapters looked short at the end; only two verses were truly absent. The rest were merges, split at anchors read off the Latin -- including one across a chapter boundary (Colossians 4:1 sat inside 3:25) and four numbering offsets where a mid-chapter merge shifted everything after it. wuj now carries exactly the Vulgate's verse set: 35810 rows, every one of the 1334 chapters matching, no duplicates, no gaps. corpus-check: 0 warnings. The ~300 verses that could not come from biblia.info.pl are recorded in NOTICE; they are not public domain.
* feat(clectio-gen): apply a calendar layer/sanctorale when generatingLukasz Kasprzak2026-07-291-1/+14
| | | | | | | | | | | | | | | | | | | Add opt-in flags so clectio's tables can be regenerated from a customized calendar instead of only the embedded universal one: clectio-gen -caldir DIR -use a,b [-sanctorale DIR] <new|old> y0 y1 out/ - -caldir + -use stack calendar layers (rank, colour, name, reading.*) over the calendar; -sanctorale DIR applies a full of.ini/ef.ini replacement. - The BOOK table stays hermetic (LECTIO_CONFIG still points nowhere), so the generator can't read a stale user books.ini -- calendar customization and the book aliases are kept separate concerns. - config.SetCalendarsDir lets CalendarsDir be pointed at an explicit layer dir without a full config tree (and without an unrelated books.ini there). Verified end to end: a layer adding a feast with a proper gospel regenerates into liturgy_of.h + verses_of.keys, and the rebuilt clectio shows it. Default (no flags) output is byte-identical to before. make test green.
* feat(cli): --cal-dump NAME to generate a commented calendar templateLukasz Kasprzak2026-07-292-1/+110
| | | | | | | | | | | | | | | Replace the static examples/sanctorale-of.ini with a `--cal-dump NAME` flag that writes the running universal calendar to ~/.config/lectio/calendars/NAME.ini as a fully-commented layer template (every celebration present, all commented). Uncomment one day and edit a field to override it; enable with `use = NAME`. - Form-aware: respects -l/--lectionary, so `-l trad --cal-dump x` dumps the 1962 calendar (322 entries) and the default dumps the OF calendar (212 entries). - Entries sorted by date then slug; refuses to overwrite an existing file. - Always in sync with the embedded (or sanctorale-overridden) calendar, so no stale checked-in template to maintain. - Update help text, man page (OPTIONS/FILES/EXAMPLES) and README to match; drop examples/sanctorale-of.ini.
generated by cgit v1.3 (git 2.53.0) at 2026-09-19 17:36:07 +0000