codegen-conformance

codegen-conformance/ — REJECTED (FR-007 will not be built)

⚠️ This corpus is NOT going to be built. FR-007 was formally rejected 2026-05-26 (docs/superpowers/specs/2026-05-25-fr-007-codegen-conformance-corpus-design.md §0), and the 2026-05-31 conformance-hardening pass (A/B) re-confirmed the rejection with empirical evidence. This README is kept only so a newcomer who lands here understands why there is no codegen corpus, instead of re-proposing one.

Why it was rejected

A dedicated cross-port codegen-output corpus would add ~0 net coverage at real maintenance cost, because codegen is a substrate and the behavior corpora already gate its observable consequences:

• Field-type semantics (field.long→64-bit, field.currency→minor-units long), required/nullable, and @maxLength propagation are gated by persistence-conformance/ executing the generated DDL + queries — a wrong mapping explodes there.
• The FR-004 payload-VO field tree is gated by render-conformance/ (a missing/renamed VO field changes the byte-identical rendered output).
• Generated validators, filters, and routes are gated by api-contract-conformance/.
• "Generator-catalog membership" was a false premise — each port's catalog is idiomatic-divergent by design (TS entityFile/queriesFile/... ≠ C# entities/AppDbContext/routes ≠ Kotlin Entity/ExposedTable/Payload/...); there is no shared catalog to gate.

Empirical confirmation (2026-05-31): the Phase-B normalization+projection work surfaced a real codegen bug in every port (C#'s MIN/MAX projection result-type + enum-over-view conversion, Kotlin's missing TimeField arm, etc.) — and every one was caught by the behavior (persistence round-trip) corpus, exactly as the rejection predicted. Codegen drift that matters shows up in behavior; codegen drift that doesn't is, by definition, not a correctness issue.

The one residual gap — handled opportunistically, not by a corpus

Codegen/type drift could go uncaught for vocabulary no behavior corpus exercises — the "type-universe-shrinks" long tail (validator.{length,regex,numeric,array}, non-cascade @onDelete/@onUpdate, @kind: storedProc|tableFunction|materializedView, the view.* UI subtypes). This is the lowest-priority backlog tier (hardening-review R10), and it is closed the project's normal way: adding new metamodel behavior ⇒ add a behavior-corpus fixture that exercises it (spec/conformance-tests.md). No standing codegen-manifest corpus is needed; add a persistence/api-contract fixture when one of those types/validators is touched.

shared-provided-enum/ is a shared input with a decision table, not an output corpus

shared-provided-enum/ holds one metadata input every port's FR-019 test loads, and expected-enum-types.json, a port-neutral DECISION TABLE: for every object-hosted enum field in that input, the shared declaration its type resolves to (or null), whether that declaration is @provided, and the declarations that must be materialized. It records a RESOLUTION, never generated bytes, so each port stays free to emit its own idiom.

It meets the bar this README sets. The incident: a two-hop enum field (A.x extends B.y, where B.y extends a shared abstract enum) generated a per-object copy of the enum in one port and the shared type in the others, and every behavior corpus stayed green, because both shapes store and validate the same members. The rule it gates is ADR-0026 Amendment 1.

Do not delete this README / do not re-propose FR-007

Keep this file so the gap-that-isn't stays documented. If you believe a codegen corpus is warranted, the bar (per the rejection) is a concrete codegen-drift incident that slipped past the behavior corpora — not a coverage-completeness argument.