Register LiturgicalCalendarAPI in the consumer expectations registry - #30
Register LiturgicalCalendarAPI in the consumer expectations registry#30JohnRDOrazio wants to merge 2 commits into
Conversation
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>
|
Warning Review limit reached
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 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 configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThe change registers ChangesConsumer registry activation
Estimated code review effort: 2 (Simple) | ~10 minutes Possibly related PRs
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
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. Comment |
There was a problem hiding this comment.
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
📒 Files selected for processing (4)
.github/workflows/validate-models.ymlauth/models/consumers.README.mdauth/models/consumers.jsondocs/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>
Completes the last step of the model-contract chain:
auth/models/consumers.jsonnow has an entry, sovalidate-modelsenforces a real contract instead of trivially passing an empty registry.Why this was deferred
PR #29 shipped
consumers.jsonas[]deliberately. The entry points atauthz/openfga-expectations.jsonon LiturgicalCalendarAPI’sdevelopmentbranch; registering it before that file existed would have made every model-touching PR here fail on a fetch error (exit 2) — enforcing nothing while turningmainred. 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:
And it can fail — one perturbation of
auth/models/LiturgicalCalendar.jsonper rule class the expectations file declares, each restored afterwards:wider_region.member_nationrequired_relations: type "wider_region" missing required relation "member_nation"diocesan_calendarrequired_types: type "diocesan_calendar" not found in model(+2 knock-onrelation_includes)deletertonational_calendarforbidden_relations: type "national_calendar" has forbidden relation "deleter"general_roman_calendar.editorto barethisrelation_includes: ... "editor" does not include "admin" via computedUsersetExit status confirmed separately as
1on violation and0restored, measured without a pipe — a first attempt read the exit code through agrepand got the wrong number.21-case self-test: still
all 21 case(s) behaved as declared.Corrections to the record
validate-models.yml’s header justified the separate self-test step with "consumers.jsonis 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 redvalidate-modelsonmainis not necessarily caused by the commit under test. The registry step also now depends on a network fetch, which can fail independently. Both noted inconsumers.README.mdand the workflow header.🤖 Generated with Claude Code
Summary by CodeRabbit
New Features
Documentation