There is no way to enforce existence of some node (not property) with configurable rules

Is your feature request related to a problem? Please describe.

There is no way to enforce existence of some node (not a property) with configurable rules.

For example, if we want to ensure that the license info exists we can set the following rule on the parent object:

rule/license-exists:
  subject:
    type: Info
    property: license
  assertions:
    defined: true

But what if we want to ensure that Operation has at least one Parameter with in: header?

There is no way to achieve it right now with the current syntax. The following rule won't work:

rule/header-param-exists:
  where:
    - subject:
        type: Operation
      assertions:
        defined: true
    - subject:
        type: Parameter
        property: in
      assertions:
        const: header
  subject:
    type: Parameter
  assertions:
    defined: true

Because we never hit the context (e.g. if there are no parameters at all) the defined assertion won't be even executed.

We can't change the behavior of the defined assertion as it will make the opposite case impossible: check something if only it is defined (e.g. check that all Parameters have schema defined but do not fail if there are no parameters at all).

We need some solution for this.

Describe the solution you'd like

I have two main ideas: new assertion and new subject modifier.

Idea A (new assertion):

This assertion enforces existence of the node in the parent context. It can be also used without context, then it will enforce existence globally. It may a bit confusing for users to understand the difference from the defined assertion.

Some ideas for assertion names:

• A1: exists
• A2: definedAndExists

See example below:

rule/header-param-exists:
  where:
    - subject:
        type: Operation
      assertions:
        defined: true
    - subject:
        type: Parameter
        property: in
      assertions:
        const: header
  subject:
    type: Parameter
  assertions:
    definedAndExists: true

Idea B (new subject modifier):

This may look the same but it's different because it can modify all the other assertions so they are not enforcing all the matching objects to comply but enforcing the context to have at least one compliant instance. So we can avoid extra context.

Some ideas for subject modifier names:

• mode: exists - the mode can be default (default behavior) or exists - enforces that at least 1 matching node exists.
• mode: presence
• exists: true
• mustExist: true
• atLeastOne: true
• minimumMatches: 1 - not sure if this can be implemented but should be possible

I lean towards the first or second because the other ones do not imply that other instances can be not matching (not sure if this is clear).

See the example below:

rule/header-param-exists:
  where:
    - subject:
        type: Operation
      assertions:
        defined: true
  subject:
    type: Parameter
    property: in
    mode: exists # other mode: every (default), exists
  assertions:
    defined: true
    const: header # we can now combine assertion here as it won't enforce all the parameters to be `header`

Any other ideas anyone?

Describe alternatives you've considered

Do not support it in configurable rules, it can be always handled by custom rules.

Additional context

Related issue: https://github.com/Redocly/redocly-cli/issues/1254

Start by reviewing the configurable-rule evaluation behavior described here, especially the missing-context case and the distinction between defined and existence. Compare the two proposed designs and related issue #1254; done means an agreed syntax and behavior that can enforce at least one matching Parameter without changing defined semantics.