GET /meta/email_template can collapse an i18n bundle back to one row — the list merge dedups by (package, name), no locale

[os-zhuang]

What

MetadataProtocol's unscoped metadata list merges the registry's items with the
MetadataService's items under metaItemKey(packageId, name)
(packages/metadata-protocol/src/protocol.ts:988, used at :4363 and :4377).
That key is (package, name) with no discriminator, so two rows of the same
email template in different locales — an i18n bundle, per
EmailTemplateDefinitionSchema — map to ONE map entry and the second
itemMap.set(...) in the first loop overwrites the first. The list serves one
locale of the bundle.

Why it is filed now

Found while fixing #7730. Until that fix, SchemaRegistry itself held only one
locale per name, so this collapse was masked — there was never a second row to
drop. With the registry keeping the bundle (<packageId>:<name>@<locale>),
listItems('email_template') returns both members and this merge is the next
place they can be lost.

Not a regression from #7730 and not on that issue's reported path: the
sys_email_template materializer (bootstrapDeclaredEmailTemplates) reads
registry.listItems directly and never goes through this merge, so the reported
symptom is fixed. What is affected is GET /meta/email_template (Studio's
metadata list), and only when a metadata service is installed and returns a
non-empty list for the type — the merge block is skipped otherwise.

Why it was not fixed in the same PR

The discriminator table lives in @objectstack/objectql
(ITEM_KEY_DISCRIMINATORS, packages/objectql/src/registry.ts), and
@objectstack/metadata-protocol does not depend on @objectstack/objectql —
so sharing it needs a home decision (@objectstack/metadata-core is a
dependency of both and is the obvious candidate) rather than a new package
dependency added in passing. #7730's claimed file surface was
packages/objectql/src/registry.ts + tests + changeset.

Suggested shape

Move (or re-export) the per-type discriminator table into a package both sides
depend on, and give metaItemKey the discriminator when the type declares one —
(package, name, locale) for email_template, unchanged for every other type.
The sys_metadata overlay merge at :4207 needs no change: overlay rows are
unique on type+name+org and carry no locale.

[os-zhuang]

Triage (route-A pass): appended domain:metadata — routing only; the finding grade is unchanged and no ownership is taken.

Landing anchor (read, not guessed). The merge key under discussion is live on origin/main @ 098b629: metaItemKey(packageId, name) at packages/metadata-protocol/src/protocol.ts:988 (NUL-separated (package, name), no locale discriminator), consumed by both itemMap.set(metaItemKey(...)) loops in the unscoped list merge. The fix — a per-type discriminator-aware key, with the table homed in a shared package — lands in packages/metadata-protocol (+ possibly packages/metadata-core, already a dependency of metadata-protocol, confirmed in its package.json), both domain:metadata.

One premise note for the grading/dispatch reader. ITEM_KEY_DISCRIMINATORS does not exist on origin/main yet (grep zero-hit, counter-probed against discriminator/locale in packages/objectql/src/registry.ts) — it rides in #7730's in-flight branch (claude/issue-7730-registry-locale-key, confirmed via ls-remote). The card is internally consistent about this ("found while fixing #7730"; the collapse only becomes reachable once the registry keeps the bundle), but any dispatch of this card is effectively sequenced behind #7730's merge, and the table's home decision (metadata-core re-export vs move) should be made against the merged shape.

Dedup. #7730 (dispatched — registry side, distinct layer), #7731/#7733 (email-template render/materialize defects, different paths). No open card covers the list-merge collapse. Not a duplicate.

本评论来自分诊座位 Routine（#5474 试点），不构成认领。

---

Generated by Claude Code

[claude]

Findings triage: promoted finding → pm:queue (domain:metadata stays).

Premise re-check at origin/main @ 31fb03d (the merge that changed this card's reachability): the masking condition this card was filed behind is now gone — #7730's fix (PR #7775) merged at 31fb03d, so SchemaRegistry now keeps i18n bundle members under (name, locale) keys and listItems('email_template') returns all locales. Meanwhile metaItemKey at packages/metadata-protocol/src/protocol.ts:988 is confirmed unchanged (NUL-separated (package, name), no locale discriminator; consumers at :4363 / :4377 unchanged). The collapse this card describes is therefore reachable today on GET /meta/email_template whenever a metadata service returns a non-empty list — no longer a dormant observation.

Why queue and not a decision card: the fix location is named, and the one open question (where the ITEM_KEY_DISCRIMINATORS table lives so metadata-protocol can share it) has an obvious in-card answer — @objectstack/metadata-core, already a dependency of both — which is an implementation-placement choice, not a public-contract call. If the dev finds metadata-core wrong at implementation time, that's a one-line escalation then.

Dedup: no other open card covers the protocol-layer merge key (checked open issues for email_template/i18n bundle overlap; #7730 closed by the merged PR).

本评论来自分诊座位 Routine（#5474 试点），不构成认领。

---

Generated by Claude Code