feat: nested sealed hierarchies for oneOf/anyOf subtypes

[halotukozak]

Summary

• Restructure polymorphic generation from sealed interfaces + separate files to sealed classes with nested data class subtypes
• Shape.Circle, Shape.Square instead of separate Circle.kt, Square.kt
• Add classNameLookup: Map<String, ClassName> to TypeMapping.toTypeName() for nested ClassName resolution
• Update SerializersModuleGenerator to use parentClass.nestedClass(variant)
• Wire classNameLookup through CodeGenerator → ClientGenerator
• anyOf-without-discriminator stays as sealed interface

Depends on: #27 (feat/12-unified-name-registry)

Test plan

• Nested sealed class assertions, one file per hierarchy
• SerializersModule uses qualified Shape.Circle::class
• @JsonClassDiscriminator + @SerialName preserved
• ClientGenerator resolves variant types via classNameLookup
• Full test suite passing

🤖 Generated with Claude Code

[Copilot]

Pull request overview

This PR updates the Kotlin model/code generation pipeline to emit polymorphic oneOf / discriminated anyOf schemas as sealed classes with nested subtypes (e.g., Shape.Circle) and wires a classNameLookup through generators so references resolve to nested ClassNames.

Changes:

• Generate sealed class hierarchies with nested data-class variants for oneOf / discriminated anyOf (keep anyOf without discriminator as sealed interface + JsonContentPolymorphicSerializer).
• Add classNameLookup: Map<String, ClassName> support to TypeMapping.toTypeName() and propagate it through CodeGenerator → ClientGenerator.
• Update SerializersModuleGenerator to register nested variant classes and expand polymorphic generation tests accordingly.

Reviewed changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
core/src/main/kotlin/com/avsystem/justworks/core/gen/ModelGenerator.kt	Implements sealed-class-with-nested-variants generation, builds classNameLookup, and adapts serializer generation paths.
core/src/main/kotlin/com/avsystem/justworks/core/gen/TypeMapping.kt	Extends type mapping API with classNameLookup for nested ClassName resolution.
core/src/main/kotlin/com/avsystem/justworks/core/gen/SerializersModuleGenerator.kt	Switches subclass registration to parentClass.nestedClass(variant).
core/src/main/kotlin/com/avsystem/justworks/core/gen/CodeGenerator.kt	Computes and passes classNameLookup into ClientGenerator.
core/src/main/kotlin/com/avsystem/justworks/core/gen/ClientGenerator.kt	Uses TypeMapping.toTypeName(..., classNameLookup) for params/return types to resolve nested models.
core/src/test/kotlin/com/avsystem/justworks/core/gen/ModelGeneratorPolymorphicTest.kt	Updates/extends tests to assert nested sealed hierarchies and classNameLookup behavior.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 15 out of 15 changed files in this pull request and generated 3 comments.

Comments suppressed due to low confidence (3)

core/src/main/kotlin/com/avsystem/justworks/core/gen/model/ModelGenerator.kt:227

• generateSealedHierarchy doesn't add the UUID-related file annotations (@OptIn(ExperimentalUuidApi) + @UseSerializers(UUIDSerializer::class)) that generateDataClass adds when a schema has UUID properties. For nested variants, this means a UUID field inside a variant would not trigger the required file-level annotations, likely breaking compilation/serialization. Consider scanning nested variant schemas for UUID usage and adding the same annotations to the parent file builder when needed.

            val serialName = schema.resolveSerialName(variantName)
            val nestedType = buildNestedVariant(variantSchema, variantName, className, serialName)
            parentBuilder.addType(nestedType)
        }

        val fileBuilder = FileSpec.builder(className).addType(parentBuilder.build())

        if (schema.discriminator != null) {
            fileBuilder.addAnnotation(
                AnnotationSpec
                    .builder(OPT_IN)
                    .addMember("%T::class", EXPERIMENTAL_SERIALIZATION_API)

core/src/main/kotlin/com/avsystem/justworks/core/gen/Hierarchy.kt:46

• Hierarchy.lookup is built via ...flatMap { ... }.toMap(). If the same schema name appears as a variant in multiple discriminated hierarchies, toMap() will silently keep only the last mapping, making hierarchy[name] nondeterministic/incorrect and potentially generating/using the wrong nested ClassName. Either detect and fail fast on duplicates, or change the lookup to include parent context (or store a multimap and resolve based on the referencing parent).

            .flatMap { (parent, variants) ->
                val parentClass = ClassName(modelPackage, parent)
                variants.map { variant -> variant to parentClass.nestedClass(variant) } +
                    (parent to parentClass)
            }.toMap()
    }

    operator fun get(name: String): ClassName = lookup[name] ?: ClassName(modelPackage, name)
}

private fun SchemaModel.variants() = oneOf ?: anyOf

core/src/main/kotlin/com/avsystem/justworks/core/gen/shared/SerializersModuleGenerator.kt:10

• This file still imports ModelPackage and ModelGenerator, but neither is used after switching the context to Hierarchy. With ktlint enabled in the repo, unused imports are likely to fail CI/lint. Remove the unused imports.

import com.avsystem.justworks.core.gen.GENERATED_SERIALIZERS_MODULE
import com.avsystem.justworks.core.gen.Hierarchy
import com.avsystem.justworks.core.gen.ModelPackage
import com.avsystem.justworks.core.gen.POLYMORPHIC_FUN
import com.avsystem.justworks.core.gen.SERIALIZERS_MODULE
import com.avsystem.justworks.core.gen.SUBCLASS_FUN
import com.avsystem.justworks.core.gen.invoke
import com.avsystem.justworks.core.gen.model.ModelGenerator

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[github-actions]

Coverage Report

Overall Project	95.58% -0.9%	🍏
Files changed	93.5%	🍏

File	Coverage
ParametersGenerator.kt	100%	🍏
Memo.kt	100%	🍏
SerializersModuleGenerator.kt	100%	🍏
ClientGenerator.kt	99.64%	🍏
Hierarchy.kt	99.08% -0.92%	🍏
Utils.kt	96.55%	🍏
SpecParser.kt	94.03%	🍏
ModelGenerator.kt	93.41% -4.13%	🍏
CodeGenerator.kt	85.83%	🍏
Utils.kt	84.96% -0.41%	🍏

[mzielu]

Consider using sealed interfaces instead of sealed classes.

Based on DeviceStatus example:
The parent type has no constructor parameters or shared state, so sealed class is unnecessarily heavy. It forces every variant to emit : DeviceStatus() with ugly empty parens, and requires the addSuperclassConstructorParameter("") hack in buildNestedVariant. With sealed interface the output is cleaner (: DeviceStatus), and @JsonClassDiscriminator works identically - the anyOf-without-discriminator path already uses sealed interface in generateSealedInterface, so this would be consistent.

[mzielu]

Cosnider sanitizing variant class names. Again on DeviceStatus example:
Schema names like "true" and "false" are used verbatim as Kotlin class names, producing backtick-escaped true/false. These should be capitalized to produce valid identifiers (True, False) while @SerialName("true") preserves the wire format.

[mzielu]

Filter out discriminator property from variant schemas

Again based on DeviceStatus example:

When an OpenAPI spec defines discriminator.propertyName: "online", that property typically also appears in each variant's schema (per OpenAPI convention). But kotlinx.serialization manages the discriminator field automatically via @JsonClassDiscriminator - having it as a regular constructor parameter is redundant and can cause serialization conflicts (duplicate key).

[mzielu]

Also, use object for zero-property variants.
After filtering the discriminator property (previous comment), some variants may end up with zero properties. These should generate as object

[mzielu]

CacheGroup should be changed to MemoScope I guess

[mzielu]

Shouldn't it be just above addSchemas function?

[mzielu]

shouldnt be .sanitizeKdoc() included here?