Skip to content

Register LiturgicalCalendarAPI in the consumer expectations registry - #30

Open
JohnRDOrazio wants to merge 2 commits into
mainfrom
feat/register-litcal-consumer
Open

Register LiturgicalCalendarAPI in the consumer expectations registry#30
JohnRDOrazio wants to merge 2 commits into
mainfrom
feat/register-litcal-consumer

Conversation

@JohnRDOrazio

@JohnRDOrazio JohnRDOrazio commented Aug 5, 2026

Copy link
Copy Markdown
Member

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.

auth/models/consumers.json shipped empty in PR #29 on purpose: the entry
points at authz/openfga-expectations.json on LiturgicalCalendarAPI's
development branch, and registering it before that file existed would have
made every model-touching PR here fail on a fetch error (exit 2) rather
than enforce anything. That file merged as
Liturgical-Calendar/LiturgicalCalendarAPI#757, so the entry can now land.

Verified against the real model rather than assumed: the validator reports
the contract satisfied (exit 0), and it fails (exit 1) for each of the four
rule classes the file declares — dropping wider_region.member_nation,
renaming a required type, adding deleter to national_calendar, and
collapsing general_roman_calendar.editor so it no longer includes admin.
The 21-case self-test still passes.

The plan asserted the reverse ordering — that Task 6's registry entry would
go live when Task 8 merged — which is why the registry looked unfinished
rather than deliberately deferred. Corrected in place at both Task 6 Step 6
and Task 8's interfaces note.

validate-models.yml's header claimed the registry "is legitimately empty
right now" as the reason for running the self-test separately. The registry
step now does real work, 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 that rationale and noted that the
registry step now depends on a network fetch, so its red states are not
always about the commit under test.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@coderabbitai

coderabbitai Bot commented Aug 5, 2026

Copy link
Copy Markdown

Review Change Stack

Warning

Review limit reached

@JohnRDOrazio, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 55 minutes

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details
⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 7e1a323b-6427-4648-b27e-57ed89dda703

📥 Commits

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

📒 Files selected for processing (1)
  • docs/superpowers/plans/2026-08-04-openfga-1182-upgrade.md
📝 Walkthrough

Walkthrough

The change registers LiturgicalCalendarAPI with its LiturgicalCalendar store and expectations file. Documentation now 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

Possibly related PRs

🚥 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 main 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

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

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Comment thread docs/superpowers/plans/2026-08-04-openfga-1182-upgrade.md
Wrote 2026-08-06, which was the local CEST date; GitHub records the merge
at 2026-08-05T22:24:40Z. Stated with the Z suffix rather than as a bare
date, matching how this plan and docs/SYSADMIN.md already timestamp
deployment events — a bare date is what made the two readings look
interchangeable.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant