Codegen reads inherited attrs via own-only accessor (ownAttr/attr) — drops inherited @required/@maxLength/@objectRef and (TS) inherited identity @fields #56

Tracking the ownAttr()-should-be-attr() bug class (codegen reading metadata attributes own-only, so attributes inherited via extends are invisible). Includes a confirmed repro (#1) and a full cross-port audit inventory (#2) so this can be fixed as a port-parallel set, not one symptom.

The model that decides bug-vs-not

There are two inheritance models, and own-only is only sometimes wrong:

• Node-level inheritance (the dominant BaseEntity pattern, Child extends BaseEntity inheriting whole field/identity nodes): the effective child iterators (fields()/identities()/primaryIdentity() etc.) return the inherited node itself, which carries its own @fields/@generation/@required. So node.ownAttr(x) on a node from an effective iterator is correct by construction → TS / C# / Java codegen are largely clean.
• Attr-level inheritance (ADR-0029 nested extends: a field/identity node whose attrs are inherited via its own super-pointer — e.g. abstract-field reuse field.string label extends Base.label, or identity.primary extends Base.primary without restating @fields): ownAttr(x) returns undefined while attr(x) returns the inherited value. This is the trap.

Do NOT blanket-convert ownAttr→attr — most ownAttr-on-an-effective-node reads are correct. Fix only the attr-level reads below.

#1 — Confirmed repro (TS)

A node-level extends that inherits an identity's @fields without restating it drops the entity from the PK map (pk-resolver.ts:33 reads primary.ownAttr("@fields"); line 34 continues when empty → no PK, and downstream FK references to it break):

// Loaded model: BaseEntity (abstract) { id, identity.primary @fields:[id] }
//               Widget { source.rdb, id, identity.primary extends "test::BaseEntity.primary" }  // @fields NOT restated
const widget = result.root.objects().find(o => o.name === "Widget")!;
const primary = widget.ownChildren().find(c => c.type === "identity")!;
expect(primary.attr("fields")).toEqual(["id"]);       // effective: sees inherited value ✓
expect(primary.ownAttr("fields")).toBeUndefined();    // own-only: misses it  ← root cause
const pkMap = buildPkMap(result.root);
expect([...pkMap.keys()]).toContain("Widget");        // FAILS: pkMap keys = ["BaseEntity"] — Widget dropped

Today the corpus's extends-on-identity always restates @fields, so this latent hole is unexercised; it should be gated (the repro converts to a green assertion once the read is attr()).

#2 — Cross-port audit inventory

Kotlin confirmed/strong: KotlinTypeMapper.kt:415-417 (@maxLength→255 fallback), KotlinExposedTableGenerator.kt:487-488 + 481-482 (@objectRef, @storage), KotlinEntityGenerator.kt:224-225 (@objectRef), KotlinFilterAllowlistGenerator.kt:170-171 (@filterable — parity gap vs Java's effective SpringFilterAllowlistGenerator).

Python confirmed (move attr()→attrs()): type_map.py:38(@isArray),:69(@objectRef); entity_model.py:60(@maxLength),:113(@objectRef),:119(@required),:120(@default); payload_vo_generator.py:175(@required),:189(@objectRef); extract_delegate_emitter.py:50; render_helper_generator.py:117; fr010_field_mapping.py:37/42/60; filter_allowlist_generator.py:120(@filterable); loader/validation_passes.py:1390/1394(warning). The correct template already exists in-repo: type_map.effective_enum_values (type_map.py:55) uses attrs() for @values with a docstring explaining inheritance — the rest of Python codegen just didn't follow it.

Don't break this: the validation reference-walk is CORRECT-AS-OWN

In all five ports the reference-walk (relationship @objectRef, identity.reference FK derivation, origin.*, template/source validators) intentionally reads own-only — it validates a reference at its declaration site (FR5d requires the error to point at the declaring node; origin.* is contractually non-inheriting; M:N requires the junction to declare its references locally). Do NOT sweep these into attr() or it regresses into double-reporting / wrong error envelopes. The genuinely-suspect validation sites are the checkFilterableFields own-only-over-effective reads (Java ValidationPhase.java:1611-1680, Python validate_discriminator.py:109), flagged UNSURE.

Suggested fix shape

• Python: the big one — convert the ~15 field-attr reads to attrs() (the effective_enum_values pattern). Highest-impact: @required nullability.
• Kotlin: convert the 1 confirmed + 4 field-attr reads; bring KotlinFilterAllowlistGenerator to parity with the effective Java generator.
• TS / C# / Java: largely correct — verify the ADR-0029 nested-child-extends edge for identity/field accessors + resolve the checkFilterableFields own-only-over-effective inconsistency.
• Gate it: add the fix(cli): scaffold outDir defaults to src/generated, not ./src/db #1 repro (and a field-level @required-inherited variant) to the conformance corpus so codegen + a runtime roundtrip exercise inherit-without-restate in every port — TDD red → green.

cc the session already working this — this inventory is the full map so the fix lands as a set.