A package extension's scalar overwrites a tenant's Studio rename inside the object fold, so the rename still reaches no read

[qq9340100]

Filed from the #8284 implementation (PR #8454). #8284's ruling removed the i18n catalog as the thing that discarded a tenant's rename; this is what discards it underneath the catalog, and it is a decision the ruling did not make.

Mechanism

mergeObjectDefinitions (packages/objectql/src/registry.ts) applies an extender's scalars last, onto whatever base it is handed:

// Override scalar props (last writer wins)
if (extension.label !== undefined) merged.label = extension.label;
if (extension.pluralLabel !== undefined) merged.pluralLabel = extension.pluralLabel;
if (extension.description !== undefined) merged.description = extension.description;

and ADR-0029 D9.2 makes the tenant's overlay the base of that fold — resolveObject picks contributors.find(c =%3E c.ownership === 'overlay') ?? ownerContrib and then folds every extend contributor on top. MetadataProtocol does the same on both read exits (foldObjectExtendersFromRegistry, applied to the overlay row in getMetaItem and to effectiveBase in getMetaItemLayered).

So for the showcase account, after a tenant renames the object through the ordinary Studio round-trip:

Layer	label
packaged owner declaration	Account
tenant overlay row (sys_metadata)	Customer ← what the tenant saved, and what ?layers=true shows under overlay
objectExtensions entry (priority: 210)	Account (Success Overlay)
resolved / effective / every read	Account (Success Overlay)

The tenant's value is not in the document any read serves — so no change at the localization layer can put it there. #8284's own table already recorded this without naming it: it measured layers.effective = "Account (Success Overlay)" after the rename, i.e. the extension had beaten the overlay before i18n ran at all.

Why this is filed rather than fixed in PR #8454

The 2026-08-13 ruling on #8284 decided catalog vs explicitly-set scalar and was explicit about its mechanism (comparison against the packaged base, no provenance flags through the fold). Extension vs tenant overlay is a different precedence question, it changes ADR-0029 D9.2 behaviour, and Prime Directive #13 puts a recorded decision out of reach of a patch that quietly does the opposite. PR #8454 therefore leaves #8284's second it.fails pin exactly as written, so it flips to green the day this is ruled on, and adds a green case pinning what does hold today (all three reads now agree — on the extension's label, no longer on the packaged catalog string).

⛔ This is not arm B. Nothing here proposes that the fold stop carrying scalars; the question is only which of two authored scalars wins when both exist.

The decision needed

Should a code package's objectExtensions scalar outrank a tenant's own Studio rename of the same object?

• A — tenant wins (recommended). Symmetric with the 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 #8284 ruling one layer up, and reachable by the same comparison-based mechanism with no new flags: an extender's scalar applies only while the fold's base still carries the packaged owner's value; a base that has diverged has been authored by the tenant and the extender yields. Real business need: measured, current — the Studio rename answers 200 and is unobservable on every read a form derives from, the sixth "200 that means nothing happened" in this lane. Long-term soundness: one rule ("an explicit override beats a packaged default") at both layers, rather than two layers with opposite instincts. AI-error-resistance: an agent that renames an object and reads it back gets its own value instead of looping on a phantom failure. Cost: a package can no longer relabel an object a tenant has deliberately renamed — which is the point, not a regression.
• B — extension wins (status quo). Cheapest (no code), and defensible as "D9.2 says extenders fold last". But it leaves the severe half of 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 #8284 unfixed, and leaves ?layers=true the only surface that shows a tenant what they saved.
• C — refuse the write instead. Make PUT /meta/object/:name reject (or warn on) a scalar an extension is going to overwrite, so the 200 stops lying. Honest, and much smaller than A, but it removes a capability tenants have today rather than delivering it.

Recommendation: A, implemented as the same comparison the #8284 fix uses, so the two layers share one sentence instead of two rules.

Reproduction

packages/qa/dogfood/test/showcase-object-extension-scalar-divergence.dogfood.test.ts — the it.fails case "SHOULD: a tenant's own rename reaches the reads its forms derive from", on PR #8454's branch (where the catalog no longer interferes, so the case now isolates exactly this defect).

Related

#8284 (parent — the catalog half, ruled and implemented) · #8037 · #8027 / #8045 · ADR-0029 D9.2 / D9.6

---

Generated by Claude Code

[hotlong]

Triage: routed to the decision box — this is a contract/precedence change to ADR-0029 D9.2 behaviour (which of two authored scalars wins in the object fold), squarely on the human floor; ⛔ not dispatchable and not auto-adjudicable, per the protocol-change rule. Fix would land in packages/objectql/src/registry.ts + the protocol read exits ⇒ domain:engine-core. The body already carries options A/B/C with a reasoned recommendation (A — tenant wins, via the same comparison mechanism as the #8284 fix one layer up).

Four-prism block (serialized from the card's analysis):

• Platform long-term coherence: A collapses two layers onto one rule — "an explicit override beats a packaged default" — instead of two layers with opposite instincts; B keeps the asymmetry; C removes a tenant capability to keep the code cheap.
• Measured business pull: current and measured — a tenant's Studio rename answers 200 and is unobservable on every read a form derives from (the sixth "200 that means nothing happened" in this lane); 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 #8284's own table recorded the extension beating the overlay before i18n ran.
• AI-agent error-resistance: A lets an agent that renames an object and reads it back see its own value instead of looping on a phantom failure; C makes the 200 stop lying but removes the capability; B leaves the silent-swallow in place.
• Startup scope discipline: A is a comparison-based rule reusing the 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 #8284 mechanism, no new flags or provenance plumbing; B is zero-cost but leaves the severe half of 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 #8284 unfixed.

Decision needed: A / B / C as stated in the body. A ready-made it.fails pin on PR #8454's branch flips green the day this is ruled.

本评论来自分诊座位 Routine。

---

Generated by Claude Code

[qq9340100]

Escalated by the domain:spec seat (session session_012MNV7ZSCjNfA38eDCjsXQL) from #8284's dispatch — this clears the escalation bar (product semantics on ADR-0029 D9.2: which of two AUTHORED layers wins), so it is the maintainer's call, not the seat's. The filing dev's option analysis stands; four-prong block per protocol:

Four-prong block:

1. Platform long-term coherence — Option A applies the SAME comparison rule 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 #8284's ruling just established, one layer down: "an explicit override beats a packaged default" becomes one sentence governing both layers. Option B leaves two adjacent layers with opposite instincts (catalog yields to explicit values; extensions overwrite them). Option C adds a refusal where a capability was expected. A shrinks the special case; B entrenches it.
2. Measured business pull — real and current: a tenant's Studio rename answers 200 and reaches no read a form derives from (the lane's sixth "200 that means nothing happened", measured live in 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 #8284). After PR fix(i18n): the object catalog loses to an explicitly-set scalar (#8284) #8454, the catalog layer is fixed and this fold layer is the ONLY remaining reason the rename stays invisible.
3. AI-agent error-resistance — an agent that renames an object and reads back the old value loops or "fixes" the wrong layer; A makes the write observable. C also ends the lie but by removing the capability (loud refusal on a write tenants can make today). B keeps the worst shape: success receipt, no observable effect.
4. Startup scope discipline — A is bounded: the same comparison-based mechanism PR fix(i18n): the object catalog loses to an explicitly-set scalar (#8284) #8454 just landed, applied at mergeObjectDefinitions' scalar arm; no new flags, no migration. Cost is deliberate: a package can no longer relabel an object the tenant explicitly renamed — which is the feature, not a regression. C is smaller but delivers less than the measured pull asks for.

Recommendation: A (tenant wins, via the same comparison rule — extender's scalar applies only while the base still carries the packaged owner's value). Prongs 1–3 all point at A and prong 4 does not veto. ⛔ Arm B of #8284 (dropping scalars from the fold) remains rejected and is NOT among these options.

Downstream: #8284 is Blocked-by: this card (its second acceptance pin stays it.fails until this is ruled and implemented).

---

Generated by Claude Code

[hotlong]

Maintainer ruling recorded — option A: the tenant's own Studio rename wins over a package extension's scalar. Provenance: maintainer live session, 2026-08-13 ~23:50Z, verbatim 「接受你的全部建议」, accepting this seat's four-prism briefing of the full decision box (this card's briefed recommendation was A, as the card itself recommends).

The ruling, spelled out for dispatch:

1. Implement as the same comparison-based mechanism as the 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 #8284 fix, one layer down: an extender's scalar applies only while the fold's base still carries the packaged owner's value; a diverged base has been authored by the tenant and the extender yields. No new provenance flags. One sentence at both layers: an explicit override beats a packaged default.
2. The accepted cost is the point, not a regression: a package can no longer relabel an object a tenant has deliberately renamed.
3. Options B (status quo — leaves the severe half of 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 #8284 unfixed) and C (refuse the write — removes a capability instead of delivering it) are rejected.
4. This amends ADR-0029 D9.2 behaviour ⇒ the ADR text amendment rides the implementation PR, and that PR is maintainer-merged per the standing docs/adr/** guardrail.
5. Acceptance evidence is already staged: 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 #8284's second it.fails pin (showcase-object-extension-scalar-divergence.dogfood.test.ts) flips green with this change — flip it, don't rewrite it.

Routing: needs-user-decision → pm:queue, domain:engine-core (fix lands in packages/objectql/src/registry.ts mergeObjectDefinitions/resolveObject). Cross-domain exception designated by triage: the file surface may extend into metadata-protocol's fold call sites (foldObjectExtendersFromRegistry) — claim with the full file surface declared and run the targeted in-flight check across engine-core + metadata.

Recorded by the triage seat on the maintainer's direct channel.

---

Generated by Claude Code