Record LiturgicalCalendar model 01M1FHYEDWG8E1CKD4VAKCYZ9V

auth/handoffs/liturgicalcalendar.md

@@ -69,14 +69,14 @@ Everything in this Zitadel section was re-verified against production on 2026-08
 - **API URL**: `https://authz.catholicdigitalcommons.org`
 - **Store name**: `LiturgicalCalendar`
 - **Store ID**: `01KRSCF4GVX0X4ZNXXJQEC4XXJ`
-- **Authorization model ID**: `01M05SBDS2F7EQFGRW7D997S6K` — the latest model in the store, uploaded 2026-08-16T17:19Z. Supersedes `01KW4FW2ZCT1E693PY8D9TJEFM` (2026-06-27T12:11Z), `01KW40P7AM87W4Y864D2RZDR0B` (same day, 07:46Z) and `01KRSCF4K9W2EWZ1X2PP1QVH3B` (the original 2026-05-16 upload this handoff used to record).
-- **Model source**: `cdcf-infra/auth/models/LiturgicalCalendar.json` — this repo owns it as of 2026-08-04; the copy in `LiturgicalCalendarAPI` was removed. Schema 1.1. Deployed types: `user`, `wider_region`, `national_calendar`, `diocesan_calendar`, `general_roman_calendar`, `national_calendar_test`, `diocesan_calendar_test`, `general_roman_calendar_test`, `rite_calendar_test`; relations `admin`/`editor`/`viewer` throughout, plus `member_nation` on `wider_region`. The current model ID is recorded in `auth/models/LiturgicalCalendar.lock.json`.
+- **Authorization model ID**: `01M1FHYEDWG8E1CKD4VAKCYZ9V` — the latest model in the store, uploaded 2026-09-01T22:41Z. Supersedes `01M05SBDS2F7EQFGRW7D997S6K` (2026-08-16T17:19Z), `01KW4FW2ZCT1E693PY8D9TJEFM` (2026-06-27T12:11Z), `01KW40P7AM87W4Y864D2RZDR0B` (same day, 07:46Z) and `01KRSCF4K9W2EWZ1X2PP1QVH3B` (the original 2026-05-16 upload this handoff used to record).
+- **Model source**: `cdcf-infra/auth/models/LiturgicalCalendar.json` — this repo owns it as of 2026-08-04; the copy in `LiturgicalCalendarAPI` was removed. Schema 1.1. Deployed types: `user`, `wider_region`, `national_calendar`, `diocesan_calendar`, `general_roman_calendar`, `rite_calendar`, `national_calendar_test`, `diocesan_calendar_test`, `general_roman_calendar_test`, `rite_calendar_test`; relations `admin`/`editor`/`viewer` throughout, plus `member_nation` on `wider_region`. The current model ID is recorded in `auth/models/LiturgicalCalendar.lock.json`.
 
   Both `test_definition` and the `deleter` relation are **gone** — dropped by the LitCal team in `ea6fdd6c` ("drop test_definition type") and `76033bfb` ("admin-superset model … drop deleter"), with the calendar-scoped test types added in `2060b19a`. Both are gone from the current (latest) model only; a consumer still pinned to an earlier model ID (e.g. `01KRSCF4K9W2EWZ1X2PP1QVH3B`) still sees them, since a pin names a specific model ID and that model still exists in the store's history.
 
   `rite_calendar_test` (relations `admin`/`editor`/`viewer`, identical to `general_roman_calendar_test`, which it generalises — its object id is the bare rite, e.g. `rite_calendar_test:roman`) is **deployed** as of model `01M05SBDS2F7EQFGRW7D997S6K`. It is purely additive: `general_roman_calendar_test` is untouched, so pre-migration tuples on it keep authorizing until `scripts/migrate-rite-test-tuples.php --apply --prune` has run in every environment.
 
-  **Not yet deployed:** `rite_calendar` was added to the model *file* (cdcf-infra #41), mirroring `general_roman_calendar` exactly — relations `admin`/`editor`/`viewer`, no `deleter`. It is the production-tier counterpart of the test type above: `general_roman_calendar`'s single fixed id could only ever name the Roman rite-level calendar, so the new type's object ids carry their rite (`rite_calendar:roman/decrees`, `rite_calendar:ambrosian/EDITIO_TYPICA_2024`). The type list above deliberately still describes model `01M05SBDS2F7EQFGRW7D997S6K`, which does **not** contain it. It becomes deployed only when an operator runs `./setup-openfga.sh --target production --create-litcal-store` in `/opt/cdcf-auth/auth` and the resulting model ID lands in `LiturgicalCalendar.lock.json` via a follow-up PR; update both this list and the model ID above at that point. Purely additive: `general_roman_calendar` is untouched, so live editor grants on it keep authorizing until `scripts/migrate-rite-calendar-tuples.php --apply --prune` (LiturgicalCalendarAPI#965) has run in every environment. Dropping `general_roman_calendar` and `general_roman_calendar_test` is a separate, later model version.
+  `rite_calendar` (relations `admin`/`editor`/`viewer`, mirroring `general_roman_calendar` exactly, no `deleter`) is **deployed** as of model `01M1FHYEDWG8E1CKD4VAKCYZ9V`. It is the production-tier counterpart of the test type above: `general_roman_calendar`'s single fixed id could only ever name the Roman rite-level calendar, so the new type's object ids carry their rite (`rite_calendar:roman/decrees`, `rite_calendar:ambrosian/EDITIO_TYPICA_2024`). Purely additive: `general_roman_calendar` is untouched, so live editor grants on it keep authorizing until `scripts/migrate-rite-calendar-tuples.php --apply --prune` (LiturgicalCalendarAPI#965) has run in every environment. Dropping `general_roman_calendar` and `general_roman_calendar_test` is a separate, later model version.
 
   Consumers pinning `OPENFGA_MODEL_ID` do **not** pick this up by redeploying — a pin names a specific model ID, so they keep resolving against whatever they pinned until the value below is updated.
 

auth/models/LiturgicalCalendar.lock.json

@@ -1,5 +1,5 @@
 {
   "store_name": "LiturgicalCalendar",
   "store_id": "01KRSCF4GVX0X4ZNXXJQEC4XXJ",
-  "model_id": "01M05SBDS2F7EQFGRW7D997S6K"
+  "model_id": "01M1FHYEDWG8E1CKD4VAKCYZ9V"
 }