feat(ipa): Add IPA-111 validation rules

[mongodb-sage-bot]

Proposed changes

Add three new Spectral validation rules enforcing lintable IPA-111 (Default Values) constraints to the IPA Validation Framework:

• xgen-IPA-111-optional-fields-no-default: optional (non-required) fields must not define a default value. Boolean fields are delegated to the boolean rule below, and fields marked with the new x-xgen-server-computed-when-client-omitted extension are exempt.
• xgen-IPA-111-effective-fields-read-only: effective-value fields (property names prefixed with effective) must be readOnly: true and must not appear in request schemas.
• xgen-IPA-111-optional-boolean-fields-default-false: optional boolean fields must default to false.

Also adds the IPA-111.yaml ruleset, registers it in ipa-spectral.yaml, regenerates the ruleset README, and introduces shared helpers isRequiredProperty (schemaUtils) and hasServerComputedWhenClientOmittedExtension (extensions).

Jira ticket: CLOUDP-439595

Checklist

• I have signed the MongoDB CLA
• I have added tests that prove my fix is effective or that my feature works

Changes to Spectral

• I have read the README file for Spectral Updates

---

Important

MongoDB Contribution Guidelines

This pull request was generated by sage-bot on behalf of yeliz.henden@mongodb.com (ticket assignee). The assignee must self-review the changes before requesting review from another engineer.
The assignee is not allowed to merge their own PR without approval from another engineer.

• yeliz.henden@mongodb.com has read and agrees to the MongoDB AI Policy
• yeliz.henden@mongodb.com has self-reviewed this PR before requesting review from another engineer

[mongodb-sage-bot]

Sage Bot can help with this pull request. Just @sage-bot in comments and I'll start working on changes in this branch.
_{Learn more about Sage Bot}

[mongodb-sage-bot]

❌ Sage Bot - Unexpected Error

Sage Bot ran into an unexpected error processing your request. If you need help, reach out in #ask-devprod.

[wtrocki]

The 3 new rules are correctly implemented and all tests pass. The issue is the override list only covered ~64 of 318 actual violations in the Atlas v2 spec — running ipa-validation against v2.yaml would fail with 254 errors.
I expanded the override list to cover all 318 violations:

• xgen-IPA-111-optional-boolean-fields-default-false: 44 → 209 entries
• xgen-IPA-111-optional-fields-no-default: 19 → 96 entries
• xgen-IPA-111-effective-fields-read-only: 1 → 13 entries

Concern — sheer volume of exceptions: 318 overrides for a single IPA rule is a red flag. The majority are boolean fields in response-only schemas (e.g., BackupSnapshot, DiskBackupSnapshotRestoreJob, ClusterDescriptionProcessArgs) where default: false is semantically irrelevant — the server computes these values.

@yelizhenden-mdb Once we you back we should align and consider:

1. Scoping optional-boolean-fields-default-false to request schemas only — responses don't benefit from default annotations
2. Similarly for optional-fields-no-default — response defaults serve as API documentation
3. Whether the effective-fields rule should only fire in request contexts (already partially done via pathIsForRequestVersion)
   If scoped to requests only, the override list would shrink from 318 to ~50 entries (rough estimate). Worth a follow-up before CLOUDP-439952 gets too large.

I'm going to do provisional change for this so it is easier to make follow up IPA change.

[wtrocki]

LGTM. Needs additional review as I authored several follow up commits

[yelizhenden-mdb]

@wtrocki I agree with the argument that default values only make sense in requests, since the default is what the server applies when the client doesn't supply the parameter value in the request. So maybe we can add a validation to prevent default values defined in response schema fields. How does it sound?

Because, based on my analysis of the current OpenAPI spec, we have default values defined on the fields of some legacy schemas, and most of them are referenced by both request bodies and responses. It might be worth adding a validation that covers the existing legacy cases and prevents future ones.

[wtrocki]

@wtrocki I agree with the argument that default values only make sense in requests, since the default is what the server applies when the client doesn't supply the parameter value in the request. So maybe we can add a validation to prevent default values defined in response schema fields. How does it sound?

Do we have and if no should we prioritize validation that prevents schema objects from being reused across request and response? If so, that gives us a natural extension point for the "default" response validation.

if we are aligned I'd suggest making small targeted fixes. Starting with IPA clarification, then refining the broader steps. I think an AI bot handles the immediate task well — addressing the sensible, non-negotiable IPA gaps.

Because, based on my analysis of the current OpenAPI spec, we have default values defined on the fields of some legacy schemas, and most of them are referenced by both request bodies and responses. It might be worth adding a validation that covers the existing legacy cases and prevents future ones.

Yes. Thus this will create +300 exceptions overall and will make even more in future due to reusal of the existing legacy objects in the new feature work.

[wtrocki]

Discussed offline. @wtrocki to create set of tickets to cover gaps. PR addressing very specific problem as of now and can be approved.