Merge worktree-fr006-java-complete-2026-05-27 — Java payload-VO codegen complete (all template subtypes + origin.* resolution)

Author: dmealing

docs/features/templates-and-payloads.md

@@ -208,25 +208,34 @@ const out: string = await render({
 ### Java
 
 `metaobjects-render` ships `Renderer` + `Provider` (Classpath, Filesystem,
-InMemory) + `Verify`. Payload-VO codegen is **not** shipped on the Java side — host
-code consumes the payload as a Java `Map<String,Object>` or a hand-coded value
-object.
+InMemory) + `Verify`. `SpringPayloadGenerator` (in `metaobjects-codegen-spring`)
+emits a Java 21 `record` payload per template, resolving all three origin
+subtypes (matches the Kotlin reference). Host code may also pass a
+`Map<String,Object>` to the renderer if it doesn't want the generated type.
 
 ```java
 import com.metaobjects.render.*;
 
 Provider provider = new FilesystemProvider(Path.of("./prompts"));
 String out = Renderer.render(RenderRequest.builder()
     .ref("lobby/welcome")
-    .payload(Map.of(
-        "displayName", "Ada",
-        "postCount", 12L,
-        "posts", List.of(Map.of("title", "Hello"))))
+    .payload(new WelcomePayload("Ada", 12L, List.of(new PostSummary("Hello"))))
     .provider(provider)
     .format("xml")
     .build());
 ```
 
+```java
+// generated/acme/blog/prompts/WelcomePromptPayload.java
+public record WelcomePromptPayload(
+    String displayName,
+    Long postCount,
+    java.util.List<PostSummary> posts
+) {}
+
+public record PostSummary(String title) {}
+```
+
 ### Kotlin
 
 `metaobjects-metadata-ktx` wraps `Renderer` in an idiomatic Kotlin builder.

server/java/codegen-spring/src/main/java/com/metaobjects/generator/spring/KNOWN_GAPS.md

@@ -38,37 +38,6 @@ needs either `Optional<T>` arms (verbose) or a builder + nullable
 representation, neither of which is a one-liner. A follow-up can add
 these once the partial-update story is settled cross-port.
 
-## Payload `origin.*` resolution not honoured (FR-006, Day-1)
-
-**Status:** intentional Day-1 simplification.
-
-`SpringPayloadGenerator` emits a `<TemplateShortName>Payload` Java record
-with components mirroring the `@payloadRef` value-object's scalar fields,
-using `SpringTypeMapper.javaTypeName` for type resolution. `origin.*`
-children on payload fields (passthrough / aggregate / collection) are
-NOT yet honoured — each field's type comes from its own subtype, not
-from the dotted source it references.
-
-The cross-port reference (Kotlin's `KotlinPayloadGenerator`) resolves
-these:
-- `origin.passthrough @from "Entity.field"` → source field's type
-- `origin.aggregate @agg count` → `Long`; `@agg avg` → `Double`;
-  `sum/min/max` → source `@of` field's type
-- `origin.collection @via "Parent.rel"` → `List<TargetPayload>` (recurses
-  into a nested payload class)
-
-**Why deferred:** the cross-port `template-output-simple` and
-`template-output-and-prompt` corpus fixtures both use plain VO field
-projection (no origins), so payload codegen is honest at the
-straightforward fixture level. Origin support is tracked here as a
-follow-up so a future entity-projection consumer who needs it has a
-clear known-gap rather than a silent type mismatch.
-
-**Workaround:** consumers needing typed origin-driven payloads today can
-hand-edit the generated record's field types. The `GENERATED` banner is
-advisory — regeneration overwrites, so the hand-edit needs to be
-preserved out-of-band until origin resolution lands.
-
 ## Output parser is throw-only (no try-style variant)
 
 **Status:** by design, per ADR-0010 §3.