Per-edition precedence and commemoration limits #332

New issue

Closed

opened 2026-07-01 06:56:39 +00:00 by manlycucumber · 1 comment

manlycucumber commented

2026-07-01 06:56:39 +00:00

(Migrated from github.com)

Problem

Precedence rules AND the number of commemorations allowed differ by edition (1960 cut commemorations sharply). Calendar comparison is only correct if these are per-edition, not assumed universal.

Acceptance criteria

The rubric-family abstraction makes precedence rules + commemoration-count limits per-edition
Tested across editions

Notes

Load-bearing for the comparison tool.

## Problem Precedence rules AND the number of commemorations allowed differ by edition (1960 cut commemorations sharply). Calendar comparison is only correct if these are per-edition, not assumed universal. ## Acceptance criteria - [ ] The rubric-family abstraction makes precedence rules + commemoration-count limits per-edition - [ ] Tested across editions ## Notes Load-bearing for the comparison tool.

manlycucumber commented

2026-07-06 21:02:25 +00:00

(Migrated from github.com)

Done in PR #457 (be94e04). The output contract's commemorationLimit now reports the active edition's class cap via PrecedenceRules::commemorationClassLimit() (the unguarded per-edition figure, distinct from the day-specific commemorationLimit() the selector and trace use): 1962 1/1/2/2, 1954 3/3/3/3, 1955 0/1/2/2. The resolver stamps it onto LiturgicalDay; the hardcoded Calendar\CommemorationLimit 1960 static is retired (the per-edition data is now the single source of truth). 1960 data == the old static, so the 1962 golden is byte-identical. Tested across editions by PrecedenceTableTest and MultiSystemContractTest.

Done in PR #457 (`be94e04`). The output contract's `commemorationLimit` now reports the **active edition's** class cap via `PrecedenceRules::commemorationClassLimit()` (the unguarded per-edition figure, distinct from the day-specific `commemorationLimit()` the selector and trace use): 1962 `1/1/2/2`, 1954 `3/3/3/3`, 1955 `0/1/2/2`. The resolver stamps it onto `LiturgicalDay`; the hardcoded `Calendar\CommemorationLimit` 1960 static is retired (the per-edition data is now the single source of truth). 1960 data == the old static, so the 1962 golden is byte-identical. Tested across editions by `PrecedenceTableTest` and `MultiSystemContractTest`.

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

Directorium/Core#332

No description provided.

Rows
Columns