PayloadCodegen.FindObject bare-name match can pick the wrong object.value on cross-package short-name collision

[dmealing]

Context

Discovered while reviewing #389255c57 (fix(csharp): payload-generator resolves bare @payloadRef in a named package).

PayloadCodegen.FindObject (server/csharp/MetaObjects.Codegen/PayloadCodegen.cs:44) matches an object.value by bare short name only:

private static MetaData? FindObject(MetaData root, string name) =>
    root.Children().FirstOrDefault(c => c.Type == TYPE_OBJECT && c.Name == name);

The just-merged fix strips the package qualifier off a resolved @payloadRef before calling FindObject — correct for the common case, but it means the top-level payload lookup now inherits the same cross-package short-name collision risk that fixtures/template-output-render-conformance/xpkg-collision/ was built to describe (see that fixture's README: "the two colliding VOs share the BARE payload-record type name Note; each port's runner hand-authors ... the payload record for that reason").

Failure scenario

Two different packages each declare an object.value named Note with different fields. A template.output's bare @payloadRef resolves (ADR-0042) to pkgB::Note, gets stripped to Note, and FindObject returns whichever Note root.Children() enumerates first — silently emitting the WRONG package's shape under the right file/record name, with no error.

Note

This is a pre-existing, systemic characteristic of the C# port's bare-name-match convention — the SAME pattern (CSharpNaming.StripPkg + bare FindObject) is used by ~7 other generators (RoutesGenerator, EntityGenerator, M2MNavigation, OutputParserGenerator, DbContextGenerator, ReverseFinders, PackageBindingResolver), so this isn't unique to PayloadCodegen — fixing it properly likely means auditing/fixing the pattern port-wide, not just here. PayloadCodegen already has an FQN-exact resolver (ResolveObjectRef, used by the verify field-tree path) that could be a model for a safer variant.

Suggested fix direction

Prefer FQN-exact resolution when the ref contains :: (mirroring ResolveObjectRef's own logic) before falling back to bare-name match, across the affected generators — scoped as its own effort given the number of call sites.

[dmealing]

Stage 1 landed on main: 44d7d885 (ADR-0044) + 89b10c36 (TS + C# fix). Not yet released.

Scope correction — this is a five-port bug, not a C# one

Investigating turned up that every port is broken, by three different mechanisms, and none of them was caught because the corpus works around the collision:

Port	Failure
C#	bare lookup + bare dedupe → wrong shape, first-wins
TS	resolves correctly, then bare-name dedupe drops the second VO
Java	correct resolution, but both write NotePayload.java → silent file clobber, last-wins
Kotlin	same clobber; its xpkg test only asserts "file exists" and notes it cannot compile
Python	both classes emitted into one module → class shadowing, last-wins

The reason this stayed invisible: every port's runner hand-authors a merged Note { alphaText?, betaText? } rather than using generated output, because no generator could emit two same-named records. So payload record emission was ungated everywhere — the bug lived exactly in the gap the fixture papered over.

Also note this issue's premise is stale: 389255c5 is not on main — it sits unmerged on origin/fix/csharp-payload-generator-bare-payloadref. That branch's strip-then-bare-lookup band-aid should not merge as-is; ADR-0044 supersedes it (its test is worth keeping).

The ruling — ADR-0044

One distinct emitted type per resolved VO FQN. Bare short name when unique in the artifact's reference closure; on collision every colliding member takes a package-derived name (AcmeAlphaNote) in its declaration, file name, and all references. Resolution always FQN-exact, dedupe always FQN-keyed, naming a pure function of the closure (order-independent — no first-wins/last-wins). If derived names still collide, fail loud with ERR_PAYLOAD_NAME_COLLISION.

Rejected: language-native namespacing (TS has no in-file namespace, and it breaks layout/imports for the common case), fail-loud-alone (ADR-0041/0042 made this metadata valid — refusing it would be a regression), and the merged/union record (erases @required; it is a shape no metadata declares).

Not breaking — names change only where output is silently wrong today; non-colliding output is byte-identical, pinned by new exact-string no-churn tests on both ports.

Stage 1 (done)

ADR-0044 · TS payload codegen (FQN-keyed dedupe + closure-scoped naming) · C# EmitRecord now resolves through the FQN-exact resolver BuildTree already used, plus the GenerateRenderHandle raw-FQN-as-type fix · the corpus contract now prohibits hand-authored payload records, and the TS and C# runners were switched to real generated types with the render pins kept byte-exact — so the gate got stronger, not weaker.

Proof: Digest.fromAlpha → AcmeAlphaNote, fromBeta → AcmeBetaNote — two distinct emitted types. TS 1001/1001 · C# 310/310 + 808/808 · workspace build/typecheck green.

Remaining

• Stage 2 — Python (class shadowing in one module).
• Stage 3 — Java + Kotlin (file clobber), plus Java render-helper-conformance has no xpkg-collision (ADR-0041) coverage #220's missing Java xpkg coverage and an upgrade of Kotlin's "file exists" assertion to a real compile+render.
• Stage 4 — coordinated patch release across all four registries.
• Carry-over: ERR_PAYLOAD_NAME_COLLISION is currently a per-port local constant, deliberately NOT yet in the shared fixtures/conformance/ERROR-CODES.json ledger — registering it now would redden Python's error-code coverage test. It must be promoted to the shared ledger when stage 2 lands, or it will be silently forgotten.
• Follow-up: C# has the same bare-lookup pattern at 8 other grep-confirmed call sites; worth its own issue.