The i18n catalog is resolved ahead of the document, so a tenant's own Studio rename never reaches either `/meta/object` read — and neither do extension scalar overrides

[huangyiirene]

Filed by the PM on behalf of the #8037 dev agent, which measured this but could not file it — GitHub API 403 for its whole session. It invented no issue number anywhere in its commit; this is the first number attached to this defect.

⚠️ This supersedes #8037's framing. #8037 asked for a label leak "in the object-extension fold". The fold is correct on all six properties. The defect is one layer down, in i18n resolution — and its more severe half has nothing to do with extensions at all.

The mechanism

translateObject (packages/spec/src/system/i18n-resolver.ts) resolves label / pluralLabel / description as catalog ?? document. The catalog is keyed by object name and consulted first, so it overwrites whatever the resolution produced.

GET /meta/object (list) and GET /meta/object/:name are translated. ?layers=true is deliberately untranslated — its own comment says so: "Not translated and not cached, both deliberately: this is a diagnostic." That is the entire reason #8037 presented as "onto ?layers=true only".

Traced live, showing the fold is uniform and the loss is downstream:

[BYNAME] fold(showcase_account) baseLabel="Account" -> outLabel="Account (Success Overlay)"
[BYNAME] served label = "Account" ← discarded downstream
[LAYERS] fold(showcase_account) baseLabel="Account" -> outLabel="Account (Success Overlay)"
[LAYERS] served code="Account (Success Overlay)" effective="Account (Success Overlay)"

⛔ The severe half — a tenant's rename is silently discarded

The extension-override case (#8037) is the milder one. Because the catalog is keyed by object name and wins unconditionally, it also defeats the tenant's own customisation. Measured on a deployment-shaped boot, renaming via the ordinary Studio round-trip (PUT /meta/object/showcase_account → 200 OK):

Surface	Label
GET /meta/object (list)	Account
GET /meta/object/:name	Account
layers.overlay	Customer ← what the tenant actually saved
layers.effective	Account (Success Overlay)

The tenant's rename reaches neither read that a writable form derives from. One object serves three different labels, and the only surface showing the saved value is the one explicitly documented as a diagnostic.

⭐ This is another instance of this lane's recurring shape — a 200 that means nothing happened (now the sixth: #7893, #8018, reassignOrphanedMetadata, #7823, #7736, this).

Scope: three scalars, one mechanism

From the enumeration landed in 3a27c46edb (PR #8258) — mergeObjectDefinitions touches six keys in three merge kinds, and the fold has zero divergences across all of them:

Property	Merge kind	Reads agree?
fields	key-keyed spread (idempotent)	✅
validations	concatenated (not idempotent, #8027)	✅
indexes	concatenated (not idempotent, #8027)	✅
label	scalar, last-writer-wins	❌ diverges
pluralLabel	scalar, last-writer-wins	⚠️ same exposure, not triggered on main
description	scalar, last-writer-wins	⚠️ same exposure, not triggered

All three scalars share one mechanism; label is simply the only one the shipped showcase catalog currently triggers (showcase_account has a catalog label, no catalog description).

⛔ Why the obvious fix is a regression in disguise

The dev reverse-verified the card's proposed "easy half" (make the fold drop scalars) as arm B, and it is the load-bearing row:

Case	Arm A (revert #8045)	Arm B (card's "fold drops scalars")	Arm C (revert #7556 fold)
New sweep (19 cases)	🔴 3	🔴 1 (anti-vacuity only)	🔴 7
#8015 agreement pin	🟢	🟢	🔴 2
#8045 fold pin	🔴 2	🟢	🔴 4

Arm B is invisible to both existing pins — caught only by the new anti-vacuity case. It makes the symptom disappear by deleting a documented ObjectExtensionSchema feature, and leaves the tenant-rename defect completely untouched. ⛔ That is why no behavioural change was shipped.

The ruling needed

Should the catalog lose to an explicit override — which requires carrying scalar provenance through the fold, so "this value was explicitly set" is distinguishable from "this value is the packaged default" — or should the untranslated diagnostic be reconciled with the translated reads?

Both candidate directions change behaviour well outside #8037's declared region, which is why this is a decision card rather than a dispatch.

Reproduction

Pinned in packages/qa/dogfood/test/showcase-object-extension-scalar-divergence.dogfood.test.ts (landed in 3a27c46edb): two it.fails cases that turn red when this is fixed. ⛔ Do not "repair" them to green — inverting them is the signal the fix worked.

Related

#8037 (the card this came from; premise corrected) · PR #8258 = 3a27c46edb (the enumeration + repro pins) · #7556/#8015 · #8027/#8045 · #8268 (nameField, a scalar in the same last-writer-wins class — ⚠️ read together) · ADR-0029 D9.2

[hotlong]

Triage: card shape completed — a needs-user-decision card must carry the four-prong block at filing time; adding it now so the maintainer can rule without reconstruction. Type set to Bug (the severe half violates declared behavior: a 200-acknowledged Studio rename that no derived read serves). domain:metadata confirmed (mechanism is packages/spec/src/system/i18n-resolver.ts + the metadata read seam, but the ruling is about read-surface semantics, decided here and implemented where the fold lives). Human floor applies — protocol/read-contract behavior change in both candidate directions — so no auto-adjudication; this is analysis, not a ruling.

Four-prong block:

1. Platform long-term coherence: "catalog loses to an explicit override" converges three read surfaces on one truth and gives scalars a provenance axis the fold already needs (this card is the sixth 200-means-nothing instance in the lane); "reconcile the diagnostic" leaves two truths standing and documents the divergence instead of removing it. First option shrinks the special case; second entrenches it.
2. Measured business pull: real and current — a tenant's ordinary Studio rename (PUT /meta/object/:name → 200) is silently discarded on every read a form derives from. Measured live on a deployment-shaped boot, not speculative. The extension-scalar half is milder but rides the same mechanism.
3. AI-agent error-resistance: a 200 whose effect is unobservable is the single worst shape for agent authors — an agent verifying its own write reads back the old value and loops or "fixes" the wrong layer. Explicit-override-wins makes the write observable; the repro pins in showcase-object-extension-scalar-divergence.dogfood.test.ts are already inverted (it.fails) to flip on the fix.
4. Startup scope discipline: provenance-through-the-fold is bounded work — three scalars, one mechanism, enumeration already landed (PR test(rest,dogfood): enumerate the object-extension fold's property classes, and locate #8037 in i18n (#8037) #8258); arm B ("fold drops scalars") is measured as a regression in disguise and is off the table by the dev's own reverse-verification. The cheap-looking alternative fixes the diagnostic, not the tenant.

Recommendation: catalog loses to an explicit override (carry scalar provenance through the fold); reconcile the ?layers=true diagnostic only as a consequence, not as the fix. Prongs 2 and 3 point the same way and prong 4 does not veto. ⚠️ Read together with #8268 (nameField, same last-writer-wins scalar class) before ruling — one ruling can cover both shapes.

---

Generated by Claude Code

[hotlong]

Maintainer ruling — catalog loses to an explicit override (comparison-based provenance)

Ruled by the maintainer in a live PM session, 2026-08-13 (session session_015XyMgCSMGGn9oSwbQEeWYg), verbatim: 「其他全部接受你的建议。」 — accepting the recommendation as presented.

Ruling: the i18n catalog is the packaged translation of packaged defaults; a tenant's explicit scalar (their Studio rename that answered 200, or an extension overlay scalar) is authored data and must win. Implement via comparison-based provenance — the catalog value applies only when the document's scalar still equals the packaged base value; a scalar that differs from base has been explicitly set, and the catalog yields. No provenance flags carried through the fold. The edge (tenant renames to exactly the base value) degrades to a no-op, which is harmless. ?layers=true stays untranslated and diagnostic, unchanged.

Implementation notes for dispatch:

• Mechanism lives in packages/spec/src/system/i18n-resolver.ts (catalog ?? document precedence) with the base value reachable from the fold enumeration landed in PR test(rest,dogfood): enumerate the object-extension fold's property classes, and locate #8037 in i18n (#8037) #8258 — hence the domain relabel to domain:spec (anchoring rule: the fix lands in packages/spec; this supersedes the earlier domain:metadata routing).
• Covers all three scalars (label, pluralLabel, description) — one mechanism, per the card's enumeration.
• ⛔ Arm B (fold drops scalars) stays rejected — it deletes a documented ObjectExtensionSchema feature and leaves the tenant-rename defect untouched.
• The repro pins are already on main (showcase-object-extension-scalar-divergence.dogfood.test.ts, two it.fails cases): inverting them to plain green is the acceptance signal — ⛔ do not "repair" them any other way.
• Read together with GET /meta/object/:name drops nameField for artifact-ingested objects — the third materialization stamp to diverge on this seam #8268 (nameField, same last-writer-wins scalar class, in flight) — serial-check against it at claim time.

Label swap: needs-user-decision → pm:queue; domain:metadata → domain:spec.

---

Generated by Claude Code