Problem
The fidelity report (openapi-laravel.unsupported.json) today is a CURATED set: it deterministically lists the correctness-affecting constructs the generator knows it cannot faithfully represent. It does not report spec keys the typed reader simply did not consume. So a brand-new or exotic spec key that nobody has triaged yet passes through invisibly.
Impact
There is no way for a user to discover "the generator read my spec but ignored this key" beyond the hand-maintained correctness set. New OpenAPI/JSON-Schema keywords, vendor conventions, or constructs we have not yet catalogued are silently unconsumed with no signal.
What correct support looks like
- an opt-in Tier-2 sweep mode (
--strict / --warn-unknown, both CLI surfaces; consider a config key too) that reports EVERY spec key the typed reader did not consume during hydration
- exclude
x-* extensions and known/intentional metadata keys (the documented metadata exclusions: Link objects, allowReserved, externalDocs, etc.) from the sweep
- output the unconsumed keys as a natural SUPERSET of the curated fidelity report (same artifact shape or a clearly delineated section), deterministic and drift-checkable like the base report
- default behavior unchanged: the curated correctness set stays the default; the sweep is strictly opt-in
Current behavior (recorded in fidelity report)
The fidelity report (openapi-laravel.unsupported.json) records only the curated correctness set. The unconsumed-key sweep does not exist yet; this issue tracks adding it as the opt-in superset of the current report.
Problem
The fidelity report (
openapi-laravel.unsupported.json) today is a CURATED set: it deterministically lists the correctness-affecting constructs the generator knows it cannot faithfully represent. It does not report spec keys the typed reader simply did not consume. So a brand-new or exotic spec key that nobody has triaged yet passes through invisibly.Impact
There is no way for a user to discover "the generator read my spec but ignored this key" beyond the hand-maintained correctness set. New OpenAPI/JSON-Schema keywords, vendor conventions, or constructs we have not yet catalogued are silently unconsumed with no signal.
What correct support looks like
--strict/--warn-unknown, both CLI surfaces; consider a config key too) that reports EVERY spec key the typed reader did not consume during hydrationx-*extensions and known/intentional metadata keys (the documented metadata exclusions: Link objects,allowReserved,externalDocs, etc.) from the sweepCurrent behavior (recorded in fidelity report)
The fidelity report (
openapi-laravel.unsupported.json) records only the curated correctness set. The unconsumed-key sweep does not exist yet; this issue tracks adding it as the opt-in superset of the current report.