[CaffeinatedCoder]

Closes #232

Problem

ASP.NET leaves out items and additionalProperties for a converter-backed element, and PatchSchemaTransformer acted only on a Patch<T> itself. So in 3.1, 3.0 and 2.0 a Dictionary<string, Patch<string>> was {"type":"object"} and a List<Patch<int>> was {"type":"array"}, and a client generator typed a map of patches as a map of anything. A Patch<T> property was described properly.

Running the fix over its input class found a sibling with another cause. A Patch<T>? property was an empty PatchOfstring component ({}), and required. A List<Patch<T>?> had no items.

Change

src/CodoMetis.TypeKit.AspNetCore/PatchSchemaTransformer.cs, in two commits:

1. Containers (Found-By: CA). A list, an array or a dictionary of patches gets the patch's own schema back where ASP.NET left it out. The schema is asked for through the context, so it's filled as a property's is: a described or replaced argument, a value object through its wrapped type, 3.0's nullable.
2. Nullable patches (Found-By: VA). A patch is now Patch<T> or its Nullable, so a Patch<T>? is inlined, optional, and its argument's schema admitting null. It isn't described as a merge-patch field: System.Text.Json reads a null there as a null patch, the same as a property left out (measured by a request). The docs say so and point to Patch<T>. The serializer gives a Nullable<T> the element type T, and that caused two more problems, both fixed. The container check reads the kind first. ASP.NET's second visit to a nullable patch's items/additionalProperties as the patch is skipped; before, a Patch<int[]>?'s numbers admitted null.

Docs: docs/merge-patches.md and the AspNetCore README say how a container of patches and a nullable patch are described. design/patch.md's row, a CHANGELOG line under 2.3.1 "Fixed", 5 claims in test/oracles/claims.json (all held by PatchSchemaTests), and PatchSchemaTests in axes.md for the version and placement axes.

Tests

PatchSchemaTests:

• A_patch_in_any_position_is_described_as_a_patch_property_is: the catalogue's 14 arguments (now with Lines[] and Dictionary<string, int>) in 8 positions (property, list, array, Dictionary<string,>, IReadOnlyDictionary<string,>, a nullable element, a list in a dictionary, a nullable property), plus a list as the whole body, and an MVC controller. It runs over OpenAPI 3.1, 3.0 and 2.0 × components / InlineValueObjects / inlined by the host (9 rows). A host that inlines everything has no polymorphic argument, because ASP.NET rejects a plain property of one too.
• A_patch_in_a_container_accepts_null_and_otherwise_exactly_what_its_argument_accepts: a JSON Schema validator judges each element against the argument's own schema (3.1, 3.0).
• A_map_of_patches_reads_a_value_and_a_null_as_the_document_says: a real request, so the document's words match what the endpoint reads.

Reverted per verify-the-guard: with the fix reverted, the 11 new document rows fail. Seeded one at a time, the dictionary arm, the nullable argument, the kind check, the nullable description and the guard's items and additionalProperties arms each fail 9 or 11. A registration of a component target that no seed caught was measured unneeded and dropped.

Locally through tools/BuildVerdict: AspNetCore 2088 passed, Conventions 2016, Samples 150.

🤖 Generated with Claude Code