`GET /meta/object/:name` drops `nameField` for artifact-ingested objects — the third materialization stamp to diverge on this seam

[huangyiirene]

Filed by the PM on behalf of the #8038 dev agent, which measured this but could not file it: its container was 403 on every GitHub API call. Recovered over the git transport as .os-handover/8038-handover.md on branch claude/issue-8038-handover. The text below is the dev's, verbatim in substance.

Unassigned. ⚠️ Read "Why this may not be a separate card" before assigning.

Symptom

For an object whose by-name read is answered from the metadata service (an artifact-booted deployment), GET /meta/object/:name serves nameField: undefined, while GET /meta/object and the SchemaRegistry's own resolved schema serve nameField: 'name' — same object, same moment, same host. Nothing in the response tells a caller which answer they got.

nameField is the ADR-0079 display/title designation. A consumer reading the by-name answer concludes the object has no designated title field, and every title-rendering decision derived from it (forms, record headers, lookup labels, resolveDisplayField consumers) is made against a document the platform itself does not agree with.

The measurement

Found incidentally while measuring #8038, on that card's reproduction host: a real SchemaRegistry, a real ObjectStackProtocolImplementation, a real RestServer, with the metadata service holding the artifact's raw declaration (serviceMode: 'artifact').

⭐ The dev diffed the two served bodies key by key rather than comparing only the fields map — "precisely so a second divergence could not hide behind the one I was sent for." That is why this exists:

### artifact host
 byName vs listed diverge on keys: fields,nameField
 byName vs registry diverge on keys: _diagnostics,fields,nameField
 byName.nameField = undefined registry.nameField = 'name'

fields was #8038 (__search). nameField is this issue. (_diagnostics is a read decoration, benign.)

Control, same run, same probe: on the bridged host (seeded from registry.getAllObjects()) and the absent host (no metadata service, read falls through to the registry), the same comparison printed diverge on keys: (none) and byName.nameField = name. ⇒ The probe can see agreement when agreement exists, and the divergence tracks the service copy specifically.

Root cause — identical to #8038

The by-name read resolves sys_metadata overlay → MetadataService → SchemaRegistry, and only the last link has been through the registry's object-materialization seam. nameField is written by provisionPrimary(schema, { synthesize: false }) — the line immediately above provisionSearchCompanion inside SchemaRegistry.registerObject, under the same base-layer gate. The artifact copy is the author's declaration captured before that seam runs, so it carries neither stamp.

Where (anchored on function names, ⛔ not line numbers)

• packages/objectql/src/registry.ts — SchemaRegistry.registerObject, the ADR-0079 materialization block calling provisionPrimary then provisionSearchCompanion. Producer of the correct answer.
• packages/spec/src/data/display-name.ts — provisionPrimary (pure, synthesize: false, idempotent).
• packages/metadata-protocol/src/protocol.ts — getMetaItem (the readItemFromMetadataService branch) is where the unmaterialized copy enters; governServedObject is the read exit where /meta/object/:name answers the __search question two different ways — drops it for all 22 package objects, keeps it for all 71 platform objects (and the list route keeps it for both) #8038's convergence now happens and where this would go; getMetaItemLayered needs the same treatment on effective only.
• Seam /meta/object/:name answers the __search question two different ways — drops it for all 22 package objects, keeps it for all 71 platform objects (and the list route keeps it for both) #8038 already installed and this would reuse: SchemaRegistry.provisionSearchCompanionOnto and its caller ObjectStackProtocolImplementation.provisionSearchCompanionFromRegistry. A provisionPrimaryOnto sibling drops into the same shape.

Reproduction

1. Build a SchemaRegistry, register an object with a title-eligible field as ownership: 'own'.
2. Put the raw declaration (⛔ not registry.getObject(name)) into the metadata service under get('object', name) — the artifact-ingest shape.
3. Read both routes through a real RestServer.
4. byName.item.nameField is undefined; GET /meta/object and registry.getObject(name).nameField are both 'name'.

The harness in packages/rest/src/meta-object-search-companion-agreement.test.ts (landed with #8038 as a6cd2c152f) already builds exactly this host — its measure({ serviceMode: 'artifact' }) is a one-line extension from asserting nameField agreement too.

⚠️ Why this may not be a separate card — reconcile with #8037 before assigning

The dev's own caveat, and it is a good one: nameField is a scalar property that mergeObjectDefinitions resolves last-writer-wins, so it may already fall inside #8037's enumeration of every property class the fold touches (landed as 3a27c46edb, PR #8258). provisionSearchCompanion is deployment-gated (OS_SEARCH_PINYIN_ENABLED) while provisionPrimary runs unconditionally, and they land in different parts of the document — but the overlap with #8037 is real.

⭐ It deliberately did not fix this inside #8038's PR: "fixing it in two places concurrently is worse than fixing it in one." Correct call.

⭐ Suggested framing — rule on the CLASS, not the third instance

Three materialization stamps have now been found diverging on this one path, one at a time:

#	Stamp	Status
#6562	injected system columns (created_at, owner_id, organization_id, …)	ruled 2026-08-08, Option B — converge at read exits
#8038	__search companion column	landed a6cd2c152f
this	nameField (provisionPrimary)	unfiled until now

A single "materialize this base the way the registry materializes its own" seam — provisionPrimary + provisionSearchCompanion behind one registry method, applied at the read exits — closes the class and stops a fourth stamp arriving as a fourth card. #8038 built half of that seam already.

This is the same lesson the #7556 → #8027 → #8037 family taught in the other direction: pinning one property class proves nothing about the others.

Dedup

• Dev side (repo only, GitHub search was 403 for it): nameField in metadata-protocol/rest → 7 hits, none about route agreement; provisionPrimary → exactly one production call site (SchemaRegistry.registerObject), no read-exit convergence anywhere; changesets reviewed. Nearest neighbour .changeset/adr0029-d9-object-overlay-contributor-layer.md examined and ruled not a twin — it concerns the registration-side gate (which layers get stamped at registerObject time), not a read serving a copy that never went through registerObject.
• PM side (GitHub search): nameField → 0 open issues; provisionPrimary / provisionSearchCompanion / materialization → 5 hits, all unrelated (permission-model parking lot, CEL binding fullness, Studio coverage, two seat posts).

No twin found.

Related

#8038 (a6cd2c152f) · #8037 (3a27c46edb) · #7556 · #8027 · #6562 · ADR-0079 · ADR-0029 D9

[os-zhuang]

Findings-triage round — PROMOTED to pm:queue, but scoped as a CLASS fix, ⛔ not as a fourth instance.

Why it is promoted

Concrete, located, and it restores an invariant rather than proposing a capability. Premise re-checked on origin/main at grading time: nameField is still referenced at the read exits in protocol.ts, and provisionSearchCompanion* — the half #8038 already built — is live in both protocol.ts and objectql/src/core.ts. So the seam and the precedent both still exist.

⛔ The scope ruling, which is the point of this promotion

Three materialization stamps have now diverged on ONE seam, one at a time: #6562 (system columns, ruled Option B) → #8038 (__search, built provisionSearchCompanionOnto) → this card (nameField). Fixing nameField alone makes it four next time.

⇒ The deliverable is "materialize this base the way the registry materializes its own" at the read exits, reusing the mechanism #8038 built rather than adding a third stamp-specific patch. Whoever takes this must enumerate the stamps that cross that seam and say which are covered and which are not — an inventory in the PR body, in the shape #8334 used for its producer sweep. A partial fix with a stated inventory is acceptable; an unstated one is not.

⚠️ What this is NOT entangled with — settled here so it is not re-litigated

The seat post warned to read this together with #8284 and #8037 because nameField, label, pluralLabel and description are all scalars resolved last-writer-wins. Read them, but note the mechanisms are different and this card is not blocked on that decision:

• 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 / Object-extension fold leaks the extension's label onto ?layers=true only — the two reads #7556 reconciled on FIELDS now disagree on LABEL #8037 are i18n precedence — translateObject resolves catalog ?? document and the catalog wins unconditionally. That fork is in the maintainer's inbox.
• This card is a materialization stamp at the read exit, the same seam as meta: an overlay-backed object read OMITS the injected system columns a registry-backed read includes — the same endpoint answers two different field sets #6562 and /meta/object/:name answers the __search question two different ways — drops it for all 22 package objects, keeps it for all 71 platform objects (and the list route keeps it for both) #8038.

⇒ Dispatchable now. ⛔ Do not wait on #8284, and ⛔ do not let a fix here quietly change i18n precedence — if the work reaches translateObject, stop and report the collision.

Grading happens here rather than at filing time, per the lane's rule: the dev that filed it had local visibility only and correctly did not level it.

---

Generated by Claude Code