Object-extension fold leaks the extension's `label` onto `?layers=true` only — the two reads #7556 reconciled on FIELDS now disagree on LABEL

[baozhoutao]

Found while re-testing #7556 on a baseline that contains its fix. #7556 / PR #8015 is genuinely fixed — do not revert it. GET /meta/object/:name now serves all three account.extension.ts overlay fields, ?layers=true carries them on both code and effective, the edit form renders real controls for them, and a PATCH round-trip persists. Every acceptance clause of platform-core.metadata-registry-serving passes. This is a smaller, adjacent inconsistency the same fold introduces.

Symptom

One object, three metadata reads, two different labels:

read	label
GET /api/v1/meta/object (list)	Account
GET /api/v1/meta/object/showcase_account	Account
GET /api/v1/meta/object/showcase_account?layers=true → code.label / effective.label	Account (Success Overlay)

Reproduced 3/3 on baseline 279ee48a (git merge-base --is-ancestor e3c8ed0f8675 HEAD → in build).

Mechanism

examples/app-showcase/src/data/extensions/account.extension.ts:15 declares a label alongside its additive fields:

export const AccountExtension = defineObjectExtension({
 label: 'Account (Success Overlay)',
 ...
 priority: 210,
});

mergeObjectDefinitions (packages/objectql/src/registry.ts:137-140) merges fields/validations/indexes additively but overrides the scalars last-writer-wins:

// 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;

Before #8015 the code layer served the raw MetadataService body straight from the artifact (objects.showcase_account.label = 'Account', 12 fields) and never went through the fold, so the overlay label had nowhere to surface. Now the fold runs on that layer — which is exactly what fixed the fields — and it carries the scalar override with it, while the list and by-name reads still report the base label.

Why the existing pins can't see it

Both agreement pins added with the fix compare field names only — packages/rest/src/meta-object-extension-agreement.test.ts and packages/qa/dogfood/test/showcase-object-extension-meta-read.dogfood.test.ts reconcile via fieldNamesOf. Both are green (6/6 and 5/5 on this baseline). A scalar divergence is structurally outside what they assert.

Reproduction

1. Boot the showcase: node packages/cli/bin/run.js dev -a dist/objectstack.json --seed-admin -d file:/tmp/x.db -p <port>
2. Sign in as admin@objectos.ai (Origin: http://localhost:<port>), take the bearer from set-auth-token.
3. GET /api/v1/meta/object/showcase_account → item.label is Account.
4. GET /api/v1/meta/object/showcase_account?layers=true → code.label and effective.label are Account (Success Overlay).

Expected one object, one label, on every read. Actual the layered read disagrees with the other two.

Which side is right is a decision, not a given

Both readings are defensible and the fix should pick one deliberately:

• The overlay label should win everywhere — defineObjectExtension accepts label, mergeObjectDefinitions documents last-writer-wins, and priority 210 says the extension outranks the base. Then the list and by-name reads are the ones under-reporting.
• The base label should win everywhere — an additive overlay arguably has no business renaming the object it extends, and the showcase's (Success Overlay) suffix is a fixture affordance, not a product intent. Then the fold should not carry scalars, or defineObjectExtension should refuse a label.

Whichever way it goes, the gate that keeps it from drifting again is extending the two agreement pins past fieldNamesOf to the scalar triple (label, pluralLabel, description) across all three reads.

Scope

Extension-independent objects are unaffected: across all 96 registered objects, no object other than showcase_account gains an extension field, and showcase_task (unextended) serves 24 fields with none of the overlay fields. The fold is also not double-applying — validations stayed at 5 with zero duplicates across three consecutive reads, so the non-idempotency PR #8015 warns about is not firing here.

Source

Extracted from the checklist retest of platform-core.metadata-registry-serving (framework 279ee48a, console 6314e87f2d49).

[hotlong]

Triage: → domain:metadata, queued. The divergence surfaces across the meta reads served by packages/metadata-protocol; the fold itself is mergeObjectDefinitions in packages/objectql/src/registry.ts:137-140. Re-laned from domain:metadata-protocol (not a lane-table label). Type intent: Bug (type field not set — list_issue_types 403 for this credential).

PM ruling premise (mechanism-assumption grade — verify before coding, falsify loudly): the existing code standard decides the "which side is right" question, so this is queued rather than escalated. defineObjectExtension accepts label, mergeObjectDefinitions documents scalar override as last-writer-wins, and the extension carries priority: 210 — declared semantics say the overlay label wins everywhere, and the list/by-name reads are the under-reporting side. Re-check command: git grep -n "last writer wins" packages/objectql/src/registry.ts against origin/main. If you find an ADR or ruling that additive overlays must not rename their base object, stop and report the fork — do not silently implement the other side.

Deliverable includes the drift gate the filer names: extend both agreement pins past fieldNamesOf to the scalar triple (label, pluralLabel, description) across all three reads.

Serial constraints: same serving family as in-flight #8027, queued #8031 and #8038 (this round) — same-package serial, no two in one batch without confirmed file-surface disjointness.

Size/model suggestion: S–M, opus.

---

Generated by Claude Code

[huangyiirene]

Claim — domain:metadata PM seat (#6367). PM session session_01AmES43BMDg4bPrxTdi5q7t, branch claude/issue-8037-extension-label-leak. pm:queue → pm:dispatched.

⚠️ This is the THIRD defect in the same family, and the pattern is now the point

#7556 (PR #8015) made the by-name /meta read fold objectExtensions contributors onto the MetadataService body — reconciling the two reads on fields. Since then:

#	what the fold got wrong	found by
#8027 → PR #8045 (landed fa6dd59)	validations and indexes duplicated — the fold is not idempotent, and two shipped call sites violated its documented precondition	the next card
#8037 (this card)	the extension's label leaks onto ?layers=true only — the two reads now disagree on label	the next card

⇒ #8015's pin compared FIELD NAMES. It was structurally blind to every other property of a merged object. I accepted that PR and called the pin excellent — it was, for the dimension it tested — and I did not ask what it did not cover. That gap has now produced two follow-on defects.

Standing review criterion, recorded on #8045 and repeated here: when a merge reconciles a structure, a pin over one of its keys proves nothing about the others. mergeObjectDefinitions treats fields (key-keyed spread, idempotent), validations/indexes (concatenated), and scalars like label (last-writer-wins) three different ways — so a fold has three distinct failure modes and a field-name pin sees none of them but its own.

⭐ What I want from this card beyond the label fix

⚠️ Do not fix label and stop. mergeObjectDefinitions has a small, enumerable set of merge behaviours. Enumerate every property it touches, classify each by merge kind, and say for each whether the two reads agree. If a fourth divergence exists, I would rather find it here than in a fourth card.

That enumeration is the deliverable I care most about; the label fix is the easy half.

Region and concurrency

⚠️ The maintainer has raised concurrency to 8, so packages/metadata-protocol/src/protocol.ts and packages/objectql/src/registry.ts will have several concurrent editors. Every brief carries the same discipline: declare your region, anchor on function names (never line numbers), merge origin/main before opening the PR, and merge again after each sibling lands. A conflict is my cost, not yours — resolve it and say so.

⚠️ protocol.ts line numbers have gone stale three times in one day; this file has taken many merges today.

Brief carried inline in the dev's prompt — cloud containers still get 403 on every GitHub API call (measured three times since the App was connected), so a brief that lives only here is unreadable to them.

---

Generated by Claude Code