Follow-up from #12 review.
PropertyResolver.kt ignores JSON Schema format and always types number as Double. This is wire-correct but lossy for two categories of field:
Monetary fields (CPM, bid, budget, price) — Double round-trips most values but isn't bit-exact and will fail strict storyboard equality checks. Both reference SDKs handle this differently:
@adcp/sdk (TS) lives with number precision lossadcp (Python) uses Decimal
Recommend BigDecimal for any property with format: decimal or in a curated property-name allowlist (*_price, cpm, bid, budget, floor).
Datetime / URI / UUID fields — string is always typed as java.lang.String, even though AdcpObjectMapperFactory registers JavaTimeModule. The generated type tells the caller nothing about format; round-tripping through String works but loses type safety.
Suggested mapping:
format: date-time → java.time.OffsetDateTimeformat: date → java.time.LocalDateformat: uri / uri-reference → java.net.URIformat: uuid → java.util.UUIDformat: email → String (no good JDK type)
Acceptance: PropertyResolver.resolve() returns the format-appropriate type, round-trip tests added in CodegenRoundTripTest, generated Instant/OffsetDateTime fields deserialize via the already-registered JavaTimeModule.
Refs:
build-logic/src/main/kotlin/codegen/PropertyResolver.kt:75-82adcp/src/main/java/org/adcontextprotocol/adcp/schema/AdcpObjectMapperFactory.java:46-51
Follow-up from #12 review.
PropertyResolver.ktignores JSON Schemaformatand always typesnumberasDouble. This is wire-correct but lossy for two categories of field:Monetary fields (CPM, bid, budget, price) —
Doubleround-trips most values but isn't bit-exact and will fail strict storyboard equality checks. Both reference SDKs handle this differently:@adcp/sdk(TS) lives withnumberprecision lossadcp(Python) usesDecimalRecommend
BigDecimalfor any property withformat: decimalor in a curated property-name allowlist (*_price,cpm,bid,budget,floor).Datetime / URI / UUID fields —
stringis always typed asjava.lang.String, even thoughAdcpObjectMapperFactoryregistersJavaTimeModule. The generated type tells the caller nothing about format; round-tripping throughStringworks but loses type safety.Suggested mapping:
format: date-time→java.time.OffsetDateTimeformat: date→java.time.LocalDateformat: uri/uri-reference→java.net.URIformat: uuid→java.util.UUIDformat: email→String(no good JDK type)Acceptance:
PropertyResolver.resolve()returns the format-appropriate type, round-trip tests added inCodegenRoundTripTest, generatedInstant/OffsetDateTimefields deserialize via the already-registeredJavaTimeModule.Refs:
build-logic/src/main/kotlin/codegen/PropertyResolver.kt:75-82adcp/src/main/java/org/adcontextprotocol/adcp/schema/AdcpObjectMapperFactory.java:46-51