Summary
A message code ("cart.greeting") is a bare, unnamespaced dotted String — the M5 question from the message-bundles spine (#857), left open at retirement. Two commons in different contexts can declare the same code with different templates/params, and nothing distinguishes them: the code is just a lookup key, matched by string equality. This issue records the gap; it is blocked on the packaging identity model and should not be built before it.
What exists today (grounded)
MessageEntry.code is a String (bynk-syntax/src/ast.rs), matched verbatim by render's lookup and by the cross-locale completeness/placeholder checks. No namespacing, no cross-context uniqueness.- The message-bundles retirement summary (
design/archive/retired-tracks.md) records this explicitly: "code identity ships as a bare, unnamespaced dotted String pending the still-unfiled packaging identity model (§4.5/§7 M5)."
Why it's blocked
The natural namespace for a code is the packaging organisation / workspace / package / unit identity model — which is being designed in the packaging feature track (design/tracks/packaging.md, an untracked draft; its spine is not yet filed). That track's own front-loaded ADRs include "flat names + the organisation/workspace/package/unit identity model" and restate ADR 0012's reservation at the org level. Namespacing message codes should adopt that model rather than invent a parallel one, so this must land after the packaging identity-model ADR — otherwise codes get a bespoke namespace that then has to be reconciled.
The collision is also only observable across contexts consuming each other's bundles, which the compiler doesn't support cleanly yet (the cross-context bundle-consumption rough edge the retirement summary names) — so the practical pressure is low until both that and packaging move.
Done when (when unblocked)
- Filed as a proper proposal once the packaging identity-model ADR exists, citing it and this issue.
- A code's identity is namespaced under the packaging identity model (not a new bespoke scheme); cross-context collision becomes a diagnosable or structurally-impossible condition rather than silent string equality.
No work until the packaging identity model lands — tracked so it isn't lost.
Summary
A message
code("cart.greeting") is a bare, unnamespaced dottedString— the M5 question from the message-bundles spine (#857), left open at retirement. Two commons in different contexts can declare the same code with different templates/params, and nothing distinguishes them: the code is just a lookup key, matched by string equality. This issue records the gap; it is blocked on the packaging identity model and should not be built before it.What exists today (grounded)
MessageEntry.codeis aString(bynk-syntax/src/ast.rs), matched verbatim byrender's lookup and by the cross-locale completeness/placeholder checks. No namespacing, no cross-context uniqueness.design/archive/retired-tracks.md) records this explicitly: "code identity ships as a bare, unnamespaced dottedStringpending the still-unfiled packaging identity model (§4.5/§7 M5)."Why it's blocked
The natural namespace for a code is the packaging
organisation/workspace/package/unitidentity model — which is being designed in the packaging feature track (design/tracks/packaging.md, an untracked draft; its spine is not yet filed). That track's own front-loaded ADRs include "flat names + theorganisation/workspace/package/unitidentity model" and restate ADR 0012's reservation at the org level. Namespacing message codes should adopt that model rather than invent a parallel one, so this must land after the packaging identity-model ADR — otherwise codes get a bespoke namespace that then has to be reconciled.The collision is also only observable across contexts consuming each other's bundles, which the compiler doesn't support cleanly yet (the cross-context bundle-consumption rough edge the retirement summary names) — so the practical pressure is low until both that and packaging move.
Done when (when unblocked)
No work until the packaging identity model lands — tracked so it isn't lost.