Register LiturgicalCalendarAPI in the consumer expectations registry

[JohnRDOrazio]

Completes the last step of the model-contract chain: auth/models/consumers.json now has an entry, so validate-models enforces a real contract instead of trivially passing an empty registry.

Why this was deferred

PR #29 shipped consumers.json as [] deliberately. The entry points at authz/openfga-expectations.json on LiturgicalCalendarAPI’s development branch; registering it before that file existed would have made every model-touching PR here fail on a fetch error (exit 2) — enforcing nothing while turning main red. That file merged as Liturgical-Calendar/LiturgicalCalendarAPI#757 on 2026-08-06, so the entry can now land.

Verification

Not assumed — measured against the real model, since this validator produced nine false passes during its own development.

Satisfied, and the fetch resolves:

$ ./auth/validate-expectations.sh
[validate-expectations] Validating models against 1 registered consumer(s).
[validate-expectations] Fetching expectations for LiturgicalCalendarAPI (LiturgicalCalendar) from https://raw.githubusercontent.com/...
    ✓ [LiturgicalCalendarAPI/LiturgicalCalendar] satisfied.
    ✓ All 1 consumer(s)' expectations satisfied.
exit=0

And it can fail — one perturbation of auth/models/LiturgicalCalendar.json per rule class the expectations file declares, each restored afterwards:

Perturbation	Reported
drop wider_region.member_nation	required_relations: type "wider_region" missing required relation "member_nation"
rename diocesan_calendar	required_types: type "diocesan_calendar" not found in model (+2 knock-on relation_includes)
add deleter to national_calendar	forbidden_relations: type "national_calendar" has forbidden relation "deleter"
collapse general_roman_calendar.editor to bare this	relation_includes: ... "editor" does not include "admin" via computedUserset

Exit status confirmed separately as 1 on violation and 0 restored, measured without a pipe — a first attempt read the exit code through a grep and got the wrong number.

21-case self-test: still all 21 case(s) behaved as declared.

Corrections to the record

• The plan had the ordering backwards. Task 8’s interfaces note said Task 6’s registry entry would "go live when this merges", which is what made the empty registry look unfinished rather than deliberately deferred. Corrected at Task 6 Step 6 and Task 8.
• validate-models.yml’s header justified the separate self-test step with "consumers.json is legitimately empty right now". That is no longer true, but the self-test is still not redundant: it is the only thing exercising the schema rejections, the wildcard scope split, and the TTU/intersection/difference boundaries, none of which this one consumer’s expectations reach. Rewrote the rationale.

Standing consequence worth knowing

The registered URL tracks development, not a tag or commit. So the contract enforced here is whatever that branch says now — a consumer can tighten its own expectations and turn this repo’s CI red with no commit landing here. That is the intended direction (the consumer owns its contract), but it means a red validate-models on main is not necessarily caused by the commit under test. The registry step also now depends on a network fetch, which can fail independently. Both noted in consumers.README.md and the workflow header.

🤖 Generated with Claude Code

Summary by CodeRabbit

• New Features

  • Added the LiturgicalCalendarAPI integration to the authorization registry.
  • Connected the integration with its calendar data store and authorization expectations.

• Documentation

  • Clarified registration timing, contract behavior, and setup requirements.
  • Documented validation coverage, including failure scenarios, boundary cases, and network-related outcomes.
  • Updated implementation plans to reflect the completed integration and testing steps.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: ae0ad08c-74e0-4158-9744-9e600822cdb0

📥 Commits

Reviewing files that changed from the base of the PR and between a287169 and 641278a.

📒 Files selected for processing (1)

• docs/superpowers/plans/2026-08-04-openfga-1182-upgrade.md

🚧 Files skipped from review as they are similar to previous changes (1)

• docs/superpowers/plans/2026-08-04-openfga-1182-upgrade.md

Included review availability: Your plan includes up to 1 review per rolling hour; 0 remain after this review.

---

📝 Walkthrough

Walkthrough

The change registers LiturgicalCalendarAPI with its LiturgicalCalendar store and expectations file. Documentation describes registry validation, fetch failures, and the completed activation sequence.

Changes

Consumer registry activation

Layer / File(s)	Summary
Register LiturgicalCalendarAPI auth/models/consumers.json, auth/models/consumers.README.md	Adds the LiturgicalCalendarAPI registry entry and documents its expectations file, registration timing, and contract behavior.
Document validation sequencing .github/workflows/validate-models.yml, docs/superpowers/plans/...	Documents registry coverage, self-test outcomes, network-fetch failures, and the completed registry activation steps.

Estimated code review effort: 2 (Simple) | ~10 minutes

Merge Risk: ⚪ Minimal · up to 64127

The change registers one consumer contract and enables validation against it; the supplied checks pass, so no actionable merge-blocking risk remains beyond normal checks and review.

Possibly related PRs

• CatholicOS/cdcf-infra#25: Updates the same OpenFGA upgrade plan and task sequencing.
• CatholicOS/cdcf-infra#29: Introduces the related registry, README, workflow, and validation documentation.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly and concisely describes the primary change: registering LiturgicalCalendarAPI in the consumer expectations registry.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch feat/register-litcal-consumer

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@docs/superpowers/plans/2026-08-04-openfga-1182-upgrade.md`:
- Around line 601-609: Update the merge date in the documentation around the
shipped-empty registry explanation, changing the
Liturgical-Calendar/LiturgicalCalendarAPI#757 merge date from 2026-08-06 to
2026-08-05 while preserving the surrounding ordering-dependency explanation.

🪄 Autofix

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: b57ea52f-069c-40e1-851f-0a5decb11750

📥 Commits

Reviewing files that changed from the base of the PR and between 5ce7ecc and a287169.

📒 Files selected for processing (4)

• .github/workflows/validate-models.yml
• auth/models/consumers.README.md
• auth/models/consumers.json
• docs/superpowers/plans/2026-08-04-openfga-1182-upgrade.md