Module compat 

Consumer compatibility: what changed, and whether it breaks anyone.

Once a spec is generated it can no longer disagree with the code, so the question worth gating shifts: not “does this match?” but “did this break the people calling it?”. Every generated dialect asks that same question, and the payload half of the answer is always a JSON Schema comparison, so it lives here rather than in any one dialect.

Requiredness means opposite things in the two directions, which is the subtlety the whole module turns on:

• Request (consumer → us): growing stricter breaks them. A newly required field is breaking; dropping a requirement is not.
• Response (us → consumer): providing less breaks them. A field that stops being guaranteed is breaking; a new one is not.

Structs

Change

One difference between two versions of a spec.

SchemaDiff

Compares schemas belonging to two revisions of a document.

Enums

Direction

Which way the data flows, which decides what “required” costs.

Severity

Whether a change can break an existing consumer.

Functions

compare_keys

Compare two maps of named entries, reporting bare presence changes and handing matched pairs to both.

deref

Follow a local $ref to the schema it names, once.

is_compatible

True when nothing in the diff would break an existing consumer.

render

A JSON value as it should read inside a diff message.

required_set

The required names of an object schema.

sort

Order a diff for reporting: breaking first, then by location, so output is stable between runs.