Found by a rule-registry symmetry audit. This is an investigation, not a confirmed bug, because request/response contravariance flips which direction is safe.

Observation

Request property/body changes are split by safety:

• request-*-type-generalized (INFO) carves the safe widening out of request-*-type-changed (ERR).
• request-*-pattern-generalized carves the safe loosening out of request-*-pattern-changed.

Response property/body changes are not split: there is only response-property-type-changed and response-property-pattern-changed. The generalize/specialize split exists for response media-type names (response-media-type-name-generalized/specialized) but not for response property type or pattern.

Why it matters (contravariance)

For a response, the safe direction is the opposite of a request:

• Response type specialization (server returns a narrower type, a subset of before) is safe for clients; response type generalization (wider) can break them.
• Same for patterns: tightening a returned pattern is safe, loosening can break.

So if response-property-type-changed fires at ERR on a safe response narrowing, that is a false positive that a response-*-type-specialized (INFO) carve-out would fix, mirroring what the request side already does for widening.

Asks

1. Confirm the current severity/behavior of response-property-type-changed and response-property-pattern-changed on a safe narrowing/tightening (write a reproducer).
2. If they over-report, add response-*-type-specialized / response-*-pattern-specialized (INFO) carve-outs, the contravariant mirror of the request generalize rules.

Related to the type-refinement work in #702 and #1018.