Object-extension overlay fields are missing from `GET /meta/object/:name` (present in the list route) — the overlay's fields can never be set through the UI

[huangyiirene]

Symptom

The showcase account extension contributes 3 fields. Where they show up:

Surface	Extension fields present?
GET /meta/object (list)	yes
GET /meta/object/showcase_account (by name)	no
GET /meta/object/showcase_account?layers=true	no — absent from both layers
GET /api/v1/data/... round-trip	yes — they are real columns, values persist
Read-only record detail page	yes — they render

Expected: the by-name response composes the same contributors the list response does, so an object's resolved schema is identical whichever way it is fetched.

Consequence, and why this is not cosmetic: the edit and new forms derive from the by-name response, so the three overlay fields are absent from every writable form. They can be read, and they can be written through the data API, but they can never be set through the UI.

Root cause

Not located by the report. What the evidence constrains:

• The contribution is registered and is materialised — the columns exist and round-trip through /api/v1/data, and the list route composes them.
• So the fault is on the by-name read path, not in registration: the by-name handler resolves the object from a source that omits extension contributors, and the ?layers=true projection omits them too (they are in neither layer, not merely folded into the wrong one).

Whether the omission sits in the REST /meta/object/:name handler or in the metadata read path it calls needs to be measured; the ?layers=true behaviour points at the layer-resolution side rather than at REST plumbing, which is why this card is filed domain:metadata — re-route if the fix turns out to land in packages/rest.

Timing note for whoever picks this up: #7306 (ADR-0029 D9, "register a tenant object overlay as its own contributor layer") merged 2026-08-10T09:34Z, around when this run's framework commit was cut, and it changes layer classification and the getArtifactItem read. It targets tenant (_provenance:'org') overlays rather than a code-declared extension, so it is not expected to fix this — but re-measure on current main before starting.

Reproduction

1. Boot the showcase (it declares the account extension with its 3 extra fields).
2. GET /meta/object — the extension fields are in the listed showcase_account entry.
3. GET /meta/object/showcase_account — they are gone.
4. GET /meta/object/showcase_account?layers=true — still gone, in both layers.
5. Open the record's edit/new form in the console — no inputs for those 3 fields; open the read-only detail page — they render, with values written through /api/v1/data.

Source

Extracted from the QA run #7514 (framework a86db17, console 09987b68).

[os-zhuang]

Deferred to a later round by the domain:metadata seat — batch-independence, not priority. Recording the reason and what is now known, because a deferred card looks dispatchable to every later sweep including another PM's, and whatever was learned about it is worthless until it is written here.

Why deferred: #7559 (commit-revert's version-lookup key) is dispatched this round in the same package, packages/metadata-protocol. Same-package cards serialize across rounds; this one rides in the next.

Two things worth knowing before anyone picks this up:

1. Branch from current main, not from anything cached. Three cards landed on packages/metadata-protocol/src/protocol.ts today — #7532 (dotted projection refused at the ingress gate), #7534 (unknown fields gated on the explicit filter axes), #7541 (the capabilities.search predicate). The file has moved substantially since this card was filed.

2. The pin this card needs is an AGREEMENT pin, and that is not the obvious one. The defect here is that two routes answer the same question differently — overlay fields present on the list route, absent from GET /meta/object/:name. The tempting assertion is "the single-object route returns the overlay fields", and it is the wrong one: it passes again the day someone hardcodes or special-cases that route, which is the same defect class one layer over. #7541 hit exactly this and the shape that worked was to measure both producers in one test and assert they agree, across hosts that genuinely differ, plus an anti-vacuity case proving the hosts are discriminated. That pattern transfers directly — see packages/rest/src/discovery-search-capability-agreement.test.ts for a worked example in this repo.

Also worth deciding rather than assuming when it is dispatched: which route is right. The card reads as "the single route is missing fields", but the honest question is whether object-extension overlays belong in that payload at all — if the list route is the one that is wrong, the fix points the other way, and that should be settled by measurement before implementation.

---

Generated by Claude Code

[os-zhuang]

Deferred a second time — different reason, recorded so this does not read as neglect.

The first deferral was #7559 holding packages/metadata-protocol. That landed (52d1a7d81), which freed the slot — but this round it went to #7674 instead: the ADR-0090 D11 OWD authoring gate turns out never to run on any host-config deployment, i.e. a declared gate that executes nowhere self-hosted, and that outranks a missing-fields read defect on severity.

Five cards are now queued on packages/metadata-protocol behind #7674 — this one, #7654, #7682, #7643, #7656. That is a genuine queue, not a backlog of forgotten cards, and it is worth saying plainly that the strict same-package serialization rule is what is producing it. If that becomes the throughput bottleneck rather than a safety measure, the maintainer's mutually-exclusive-region exemption (declare regions at claim time, merge main before opening the PR, merge again after each sibling lands, let the queue arbitrate) is the sanctioned way to run several of them concurrently — but that is the maintainer's call to make explicitly, not something a seat adopts on its own.

The trap recorded in my earlier comment still stands and is still the important part: the pin this card needs is an AGREEMENT pin, not "the single-object route returns the overlay fields" — that assertion passes again the day someone special-cases that route. The worked example in this repo is now packages/rest/src/discovery-search-capability-agreement.test.ts (landed with #7541). And the open question stands too: decide by measurement which route is right, since "the list route is correct and the single route is missing fields" is the card's assumption rather than an established fact.

One thing that has changed since the first note and is worth re-checking before dispatch: protocol.ts has taken four merges today (#7532, #7534, #7541, #7559). Branch from current main, and expect the surrounding code to have moved.

---

Generated by Claude Code

[os-zhuang]

Deferred a third time — and this round I measured the queue instead of just recording the collision, because three deferrals is the point where "not yet" needs evidence.

Why deferred again: packages/metadata-protocol/src/protocol.ts is held by #7779 (dispatched 14:54Z — listCommits missing env-wide sys_metadata_commit rows, the sibling of the #7705 fix that landed as ecd83fd50). Same-package serialization; this card rides the next free slot in that lane.

The measurement, because it changes the picture. A slot freed when PR #7764 merged (bdd0120bc). I went looking for any dispatchable domain:metadata card that would not collide with the two in-flight lanes, and read six candidates. All six collided:

card	lands in	held by
#7556 (this one)	metadata-protocol/src/protocol.ts	#7779
#7743 — field overlay lock unenforced	protocol.ts:8678 (isArtifactBacked)	#7779
#7736 — view container never expanded on the write door	protocol.ts (+ metadata/src/plugin.ts)	#7779
#7774 — list merge dedups without a locale discriminator	protocol.ts:988/4363/4377	#7779
#7309 — 16 actions declaring confirmText + params	packages/platform-objects	#7728
#7544 — dead JWKS nav entry	platform-objects/src/apps + /identity	#7728

So the rolling window is running at 2 of 3, and the binding constraint is not supply — the queue holds 30 cards — it is that this seat's queue is concentrated in two places, one of which is the single hottest file in the repo (protocol.ts has taken seven merges today).

That is the same bottleneck I recorded on this card at 11:14Z, now with numbers behind it. The sanctioned remedy is the maintainer's mutually-exclusive-region exemption, and it stays the maintainer's explicit call — ⛔ this seat does not adopt it unilaterally, which is why the deferral stands rather than being reasoned around. I've put the question to them with this measurement attached.

Nothing about the card's own content has changed, and the trap still stands — repeating it because it is the part most likely to be lost across three deferrals: the pin this card needs is an AGREEMENT pin. "The single-object route returns the overlay fields" is the wrong assertion; it passes again the day someone special-cases that route, which is the same defect class one layer over. Measure both producers in one test and assert they agree, with an anti-vacuity case proving the hosts are genuinely discriminated. Worked example: packages/rest/src/discovery-search-capability-agreement.test.ts.

And the open question still needs settling by measurement, not assumption: which route is right? The card reads as "the single route is missing fields", but whether object-extension overlays belong in that payload at all is not established. If the list route is the wrong one, the fix points the other way.

Branch from current main when this is finally dispatched — protocol.ts has moved substantially since the last note.

---

Generated by Claude Code