Record LiturgicalCalendar model 01M1K7XY1RKYD3G984Z7Q7S3WW

auth/handoffs/liturgicalcalendar.md

@@ -69,16 +69,16 @@ 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**: `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`.
+- **Authorization model ID**: `01M1K7XY1RKYD3G984Z7Q7S3WW` — the latest model in the store, uploaded 2026-09-03T09:00Z. Supersedes `01M1FHYEDWG8E1CKD4VAKCYZ9V` (2026-09-01T22:41Z), `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`, `rite_calendar`, `national_calendar_test`, `diocesan_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.
 
   `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.
 
-  **Not yet deployed:** `general_roman_calendar` and `general_roman_calendar_test` were REMOVED from the model *file* at the #955 prune milestone (LiturgicalCalendarAPI#970 dropped the last code paths that named them, and `scripts/migrate-rite-calendar-tuples.php --apply --prune` deleted the last legacy tuple on 2026-09-01). The list above deliberately still describes model `01M1FHYEDWG8E1CKD4VAKCYZ9V`, which still HAS both. They go away 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. Unlike every earlier change in this family this one is SUBTRACTIVE — a consumer still pinned to an older model ID keeps seeing both types, since a pin names a specific model that still exists in the store's history, but anything re-pinned to the new model loses them. The API's `authz/openfga-expectations.json` now lists both under `forbidden_types`, so `validate-expectations.sh` fails until this model change is the one being validated.
+  `general_roman_calendar` and `general_roman_calendar_test` are **gone** as of model `01M1K7XY1RKYD3G984Z7Q7S3WW`, the #955 prune milestone. This is the first SUBTRACTIVE change in the family: every earlier one added a type alongside its predecessor. It was safe only because the tuples went first — `scripts/migrate-rite-calendar-tuples.php --apply --prune` deleted the last legacy tuple on 2026-09-01, and LiturgicalCalendarAPI#970 removed every code path that named either type, including the authorization middleware's legacy fallback. A consumer still pinned to an EARLIER model ID keeps seeing both types, since a pin names a specific model that still exists in the store's history; anything re-pinned to this model loses them. The API's `authz/openfga-expectations.json` now lists both under `forbidden_types`, so a future re-introduction fails `validate-expectations.sh` rather than passing quietly.
 
   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": "01M1FHYEDWG8E1CKD4VAKCYZ9V"
+  "model_id": "01M1K7XY1RKYD3G984Z7Q7S3WW"
 }