feat(conformance): SP-G Java recon Unit8 — re-enable Java+Kotlin registry gates (all 5 ports green); constrain Kotlin runner to metamodel provider set; docs

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Author: dmealing

.github/workflows/conformance.yml

@@ -49,9 +49,9 @@ jobs:
           cd server/typescript/packages/metadata && bun test test/conformance.test.ts test/yaml-conformance.test.ts test/object-model-conformance.test.ts
           # Registry-conformance gate (TS is the reference emitter — byte-matches
           # the committed canonical) + untested-vocabulary coverage report.
-          # C#/Python run theirs via the whole-project/whole-dir scope below;
-          # Java/Kotlin's runner is @Disabled (pending the Java reconciliation, #36)
-          # and is intentionally NOT added to their scoped -Dtest= lists.
+          # All five ports run the gate now (SP-G reconciliation landed): C#/Python
+          # via the whole-project/whole-dir scope below; Java + Kotlin via the
+          # RegistryManifestConformanceTest added to their scoped -Dtest= lists.
           bun test test/registry-conformance.test.ts test/registry-coverage.test.ts
           # Byte-exact render / verify / extract / output-prompt corpora (packages/render).
           cd ../render && bun test test/render-conformance.test.ts test/verify-conformance.test.ts test/extract/extract-conformance.test.ts test/output-prompt-conformance.test.ts
@@ -83,8 +83,9 @@ jobs:
           # ("No type registered for: field.uuid") when the render module's tests
           # reference the freshly-built metadata artifact.
           mvn -pl metadata,render,codegen-spring -am install -DskipTests -q
-          # Loader + YAML + object-model corpora (metadata module).
-          mvn -pl metadata test -Dtest='ConformanceTest,YamlConformanceTest,ObjectModelConformanceTest' -q
+          # Loader + YAML + object-model corpora (metadata module)
+          # + registry-conformance gate (metamodel-vocabulary manifest byte-match, SP-G).
+          mvn -pl metadata test -Dtest='ConformanceTest,YamlConformanceTest,ObjectModelConformanceTest,RegistryManifestConformanceTest' -q
           # Byte-exact render / verify / extract / output-prompt corpora (render module).
           mvn -pl render test -Dtest='RenderCrossPortReportTest,VerifyConformanceTest,ExtractConformanceTest,OutputPromptConformanceTest' -q
           # Validator-parity corpus (generated DTO jakarta.validation, codegen-spring module)
@@ -128,8 +129,10 @@ jobs:
           # artifacts.
           mvn -pl codegen-kotlin -am install -DskipTests -q
           # object-model + output-prompt + validator-parity corpora (the corpora Kotlin has)
-          # + generator stable-name registry conformance (ADR-0021 D3).
-          mvn -pl codegen-kotlin test -Dtest='ObjectModelConformanceTest,OutputPromptConformanceTest,ValidationConformanceTest,GeneratorRegistryConformanceTest' -q
+          # + generator stable-name registry conformance (ADR-0021 D3)
+          # + registry-conformance gate (metamodel-vocabulary manifest byte-match, SP-G;
+          #   composes the metamodel provider set so codegen-base/om classpath SPI does not pollute it).
+          mvn -pl codegen-kotlin test -Dtest='ObjectModelConformanceTest,OutputPromptConformanceTest,ValidationConformanceTest,GeneratorRegistryConformanceTest,RegistryManifestConformanceTest' -q
 
   completeness-gate:
     needs: [conformance, conformance-kotlin]

CLAUDE.md

@@ -406,7 +406,7 @@ import { CurrencyInput } from "@metaobjectsdev/react";
 
 Preserve the following contracts exactly across all language ports:
 
-**Metamodel subtype vocabularies (must be identical across languages):** the `registry-conformance` gate (`fixtures/registry-conformance/`) is the structural enforcer of this rule — each port emits its registry as a canonical manifest byte-matched to `expected-registry.json` (TS/C#/Python live + green; Java/Kotlin gated pending reconciliation). See `fixtures/registry-conformance/README.md`.
+**Metamodel subtype vocabularies (must be identical across languages):** the `registry-conformance` gate (`fixtures/registry-conformance/`) is the structural enforcer of this rule — each port emits its registry as a canonical manifest byte-matched to `expected-registry.json`. **All five ports (TS / C# / Java / Kotlin / Python) are live + green** (SP-G Java/Kotlin reconciliation complete; the JVM runners compose from the defined metamodel provider set so codegen-base/om classpath SPI does not pollute the measured vocabulary). See `fixtures/registry-conformance/README.md`.
 - Filter operators: `eq`, `ne`, `gt`, `gte`, `lt`, `lte`, `in`, `like`, `isNull`
 - Source subtypes: `rdb` (paradigm; ADR-0007). The pre-v2 `dbTable`/`dbView` subtypes are RETIRED — `source.rdb` + `@kind: table|view|materializedView|storedProc|tableFunction` is the form, with read-only-ness derived from `@kind`. Multi-source via `@role` (exactly one `primary` per object). Source physical name = `@table` (NOT `@name`); field physical name = `@column` (renamed from `@dbColumn`). Referential actions on relationships: `@onDelete` / `@onUpdate`.
 - Origin subtypes: `passthrough`, `aggregate`

docs/superpowers/specs/2026-06-02-sp-g-java-registry-divergence-analysis.md

@@ -1,8 +1,19 @@
 # SP-G — Java registry divergence classification (A/B/C/D buckets)
 
-_Analysis only. No code/registration/canonical changes were made. This document
-drives the decision of whether to (a) fix Java, (b) expand the cross-port
-contract, or (c) treat divergences as out-of-scope._
+**STATUS: RECONCILED — Java/Kotlin gates re-enabled (SP-G Unit 8).** Every
+divergence classified below was reconciled at source across SP-G Units 2-7 (the
+Phase-1 emitter exclusions + the Phase-2 vocabulary convergence). The Java
+manifest now byte-matches the canonical; SP-G Unit 8 re-enabled both JVM runners
+(`RegistryManifestConformanceTest` in `metadata` + `codegen-kotlin`), constrained
+them to the defined metamodel provider set (`RegistryManifest.composeMetamodelRegistry()`,
+so the `codegen-kotlin` classpath's `om` + `codegen-base` SPI providers no longer
+pollute the measured vocabulary), and wired both into `.github/workflows/conformance.yml`.
+All five ports (TS / C# / Java / Kotlin / Python) are now live + green on the gate.
+The analysis below is retained as the historical classification record.
+
+_Originally analysis only — no code/registration/canonical changes at authoring
+time. This document drove the decision of whether to (a) fix Java, (b) expand the
+cross-port contract, or (c) treat divergences as out-of-scope._
 
 ## Method
 

fixtures/registry-conformance/README.md

@@ -199,12 +199,29 @@ divergence:
 | TypeScript | **live + green** (reference emitter; produces the canonical) | `packages/metadata/test/registry-conformance.test.ts` | `conformance` job, `typescript` matrix leg (scoped `bun test`) |
 | C# | **live + green** (byte-identical) | `MetaObjects.Conformance.Tests/RegistryManifestConformanceTests.cs` | `conformance` job, `csharp` matrix leg (whole `MetaObjects.Conformance.Tests` project) |
 | Python | **live + green** (byte-identical) | `tests/conformance/test_registry_conformance.py` | `conformance` job, `python` matrix leg (whole `tests/conformance` dir) |
-| Java | **gated (`@Ignore`)** — Phase-2 vocabulary divergence | `metadata/src/test/java/com/metaobjects/registry/RegistryManifestConformanceTest.java` | n/a — intentionally NOT in the scoped `-Dtest=` list while gated |
-| Kotlin | **gated (`@Disabled`)** — shares the Java JVM registry | `codegen-kotlin/src/test/kotlin/com/metaobjects/generator/kotlin/RegistryManifestConformanceTest.kt` | n/a — intentionally NOT in the scoped `-Dtest=` list while gated |
+| Java | **live + green** (byte-identical; reconciled SP-G Units 4-7, gate re-enabled Unit 8) | `metadata/src/test/java/com/metaobjects/registry/RegistryManifestConformanceTest.java` | `conformance` job, `java` matrix leg (in the metadata `-Dtest=` list) |
+| Kotlin | **live + green** (byte-identical; composes the metamodel provider set) | `codegen-kotlin/src/test/kotlin/com/metaobjects/generator/kotlin/RegistryManifestConformanceTest.kt` | `conformance-kotlin` job (in the codegen-kotlin `-Dtest=` list) |
 
-The three live ports (TS / C# / Python) genuinely run on every CI build (`.github/workflows/conformance.yml`, `conformance` job). The Java + Kotlin runners are wired and compile, but their assertions are `@Ignore`/`@Disabled` pending the Java metamodel-vocabulary reconciliation (tracked as a dedicated follow-on; see the **divergence analysis**:
+All five ports now genuinely run the gate on every CI build (`.github/workflows/conformance.yml`). TS / C# / Python were live from the start; Java + Kotlin were re-enabled in SP-G Unit 8 after the Java metamodel-vocabulary reconciliation (Units 4-7) landed (see the **divergence analysis**:
 [`docs/superpowers/specs/2026-06-02-sp-g-java-registry-divergence-analysis.md`](../../docs/superpowers/specs/2026-06-02-sp-g-java-registry-divergence-analysis.md) and the
-[reconciliation plan](../../docs/superpowers/plans/2026-06-02-sp-g-java-reconciliation-plan.md)). They are left out of the Java/Kotlin scoped `-Dtest=` lists so they neither run nor error — re-add them (and drop the annotation) once the reconciliation lands.
+[reconciliation plan](../../docs/superpowers/plans/2026-06-02-sp-g-java-reconciliation-plan.md)).
+
+**Why the Java + Kotlin runners compose from a defined provider set.** Both JVM
+runners build their registry from the explicit metamodel provider set
+(`RegistryManifest.composeMetamodelRegistry()` — mirroring the TS reference's
+`composeRegistry(coreProviders)`), NOT from the process-global
+`MetaDataRegistry.getInstance()` singleton. The metadata module's classpath holds
+only the metamodel providers, but a downstream module that also runs the gate
+(`codegen-kotlin`) has the `om` + `codegen-base` modules on its test classpath —
+whose SPI providers register an extra `object.managed` subtype and ~22
+codegen-tooling attrs (`ai*` / `json*` / `has*`, self-registered by the doc
+generators `MetaDataAIDocumentationGenerator` / `MetaDataFileJsonSchemaGenerator`).
+Those are per-port codegen tooling, NOT the cross-port logical metamodel
+vocabulary the gate measures (the same category as the EXCLUDED native type
+bindings / codegen targets). Composing from the defined provider set makes every
+module's runner measure the identical vocabulary — the gate stays meaningful (it
+still catches a real attr/subtype divergence in any metamodel provider) while
+being immune to classpath pollution.
 
 Detail per port:
 
@@ -230,11 +247,13 @@ Detail per port:
   never-registered constants (`RELATIONSHIP_ATTR_FK_FIELD` / `_PARENT_FIELD`)
   were removed. No structural (Java-class) divergence — Python uses the same attr
   vocabulary and registry model.
-- **Java + Kotlin (shared JVM registry)** — emitter (`RegistryManifest.emit`,
+- **Java + Kotlin (shared JVM emitter)** — emitter (`RegistryManifest.emit`,
   `metadata` module) + runners (`RegistryManifestConformanceTest` in `metadata`
-  and `codegen-kotlin`) are wired and functional, but the assertions remain
-  **`@Ignore`/`@Disabled` — ESCALATED** (Phase-2 divergences below remain).
-  SP-G Phase 1 (Units 2-3) settled three of the divergences cross-port via the
+  and `codegen-kotlin`) are **live + green** (both re-enabled in SP-G Unit 8;
+  each composes from the defined metamodel provider set — see "Why the Java +
+  Kotlin runners compose from a defined provider set" above). The historical
+  divergence inventory below records what the gate surfaced and how it was
+  reconciled. SP-G Phase 1 (Units 2-3) settled three of the divergences cross-port via the
   uniform emitter exclusions documented in "EXCLUDED" above (no Java behavior
   change): the structural keywords `isArray`/`isAbstract` + the `description`
   per-type duplicate are filtered from the `attrs` list, the `metadata.base`
@@ -267,8 +286,9 @@ Detail per port:
   + owned-object `@storage="jsonb"`, with consumers in `omdb` + `codegen-mustache`
   migrated; the DDL/migration-only remnants `dbForeignKey`/`previousName`/
   `dbIndexName`/`dbSequenceName`/`dbTablespace` dropped as dead under ADR-0015).
-  The Java manifest now byte-matches the canonical (residual EMPTY); the gate stays
-  `@Ignore`/`@Disabled` only until SP-G Unit 8 flips it atomically with CI wiring.
+  The Java manifest now byte-matches the canonical (residual EMPTY); SP-G Unit 8
+  re-enabled the gate (dropped `@Ignore`/`@Disabled`), constrained both JVM
+  runners to the defined metamodel provider set, and wired both into CI.
 
 ## Regenerating the canonical
 

server/java/codegen-kotlin/src/test/kotlin/com/metaobjects/generator/kotlin/RegistryManifestConformanceTest.kt

@@ -1,50 +1,56 @@
 package com.metaobjects.generator.kotlin
 
-import com.metaobjects.registry.MetaDataRegistry
 import com.metaobjects.registry.RegistryManifest
 import java.nio.charset.StandardCharsets
 import java.nio.file.Files
 import java.nio.file.Path
 import kotlin.test.Test
 import kotlin.test.assertEquals
 import kotlin.test.assertTrue
-import org.junit.jupiter.api.Disabled
 
 /**
  * SP-G Registry Conformance — the Kotlin runner.
  *
- * Kotlin runs on the JVM and REUSES the shared Java [MetaDataRegistry] and the Java
- * [RegistryManifest] emitter (the same classes the Java runner validates). This test obtains
- * the shared JVM registry and asserts the emitted manifest is byte-identical to the single
- * committed canonical `fixtures/registry-conformance/expected-registry.json` — proving the
- * JVM-view of the registry matches the cross-port contract from the Kotlin module too.
+ * Kotlin runs on the JVM and REUSES the shared Java [RegistryManifest] emitter (the same
+ * class the Java runner validates). This test composes a registry from the DEFINED metamodel
+ * provider set ([RegistryManifest.composeMetamodelRegistry]) and asserts the emitted manifest
+ * is byte-identical to the single committed canonical
+ * `fixtures/registry-conformance/expected-registry.json` — proving the metamodel vocabulary
+ * matches the cross-port contract from the Kotlin module too.
  *
- * Byte-identity to the Java runner holds by construction (same registry, same emitter); the
- * value here is the gate existing in the Kotlin module's test surface as well.
+ * It composes from the metamodel provider set rather than the process-global
+ * `MetaDataRegistry.getInstance()` ON PURPOSE: this module's test classpath also carries the
+ * `om` + `codegen-base` SPI providers, which register an extra `object.managed` subtype and
+ * ~22 codegen-tooling attrs (`ai*`/`json*`/`has*`, self-registered by the doc generators).
+ * Those are per-port codegen tooling, not the cross-port logical metamodel vocabulary this
+ * gate measures. Composing from the defined provider set makes this runner measure exactly
+ * what the metadata-module runner does — immune to classpath pollution while still catching
+ * real metamodel-vocabulary drift. See `fixtures/registry-conformance/README.md`.
+ *
+ * Byte-identity to the Java runner holds by construction (same provider set, same emitter);
+ * the value here is the gate existing in the Kotlin module's test surface as well.
  *
  * Like the Java runner, this is a drift-finding gate: any mismatch is a real divergence
  * between the JVM metamodel registry's logical vocabulary and the cross-port canonical. Fix
  * the Java registration to match the canonical (TS is the reference) — do NOT loosen the
  * canonical. Escalate if TS itself is wrong versus the documented vocabulary.
- *
- * `@Disabled` — ESCALATED, same root cause as the Java runner
- * (`com.metaobjects.registry.RegistryManifestConformanceTest`): the shared JVM registry's
- * attribute vocabulary diverges pervasively from the cross-port canonical that TS, C#, and
- * Python agree on. See that Java test's Javadoc for the full divergence inventory. The
- * canonical is correct and is NOT edited; re-enable once the Java vocabulary reconciliation
- * lands.
  */
 class RegistryManifestConformanceTest {
 
     @Test
-    @Disabled(
-        "SP-G ESCALATED: the shared JVM metamodel registry vocabulary diverges pervasively " +
-            "from the cross-port canonical (TS/C#/Python agree). See the Java runner's Javadoc " +
-            "for the inventory. Re-enable once the Java vocabulary reconciliation lands; the " +
-            "canonical is correct and is NOT to be edited.",
-    )
     fun manifestMatchesCanonical() {
-        val registry = MetaDataRegistry.getInstance()
+        // Compose from the DEFINED metamodel provider set (RegistryManifest.
+        // composeMetamodelRegistry) rather than the process-global
+        // MetaDataRegistry.getInstance(): this module's test classpath ALSO
+        // carries the `om` + `codegen-base` SPI providers, which register an
+        // extra `object.managed` subtype and ~22 codegen-tooling attrs
+        // (`ai*`/`json*`/`has*`, self-registered by the doc generators). Those
+        // are per-port codegen tooling, NOT the cross-port logical metamodel
+        // vocabulary this gate measures. Composing from the metamodel provider
+        // set makes the Kotlin runner measure exactly what the metadata-module
+        // runner does — byte-identical to the canonical, and still catching real
+        // metamodel-vocabulary drift.
+        val registry = RegistryManifest.composeMetamodelRegistry()
         val got = RegistryManifest.emit(registry).replace("\r\n", "\n")
         val want = readCanonical().replace("\r\n", "\n")