finding(plugin-dashboard): lookup cells in ObjectDataTable / RecordDetailDrawer never get reference_to/reference — refSchema-driven resolution and drill-through links never engage

[os-sales]

Provenance: found while implementing #6597 (the FieldMeta.referenceTo enforce-or-remove
card). Filed unassigned, no pm:queue label — this is an observation of a real gap in
existing behaviour, not a scoped fix; severity is for triage to set.

What's measured

plugin-dashboard's FieldMeta (packages/plugin-dashboard/src/recordFields.tsx) is the
object buildFieldMeta returns and ObjectDataTable / RecordDetailDrawer pass to
renderFieldValue → getCellRenderer → <Renderer value={value} field={fieldMeta} />
(@object-ui/fields). For a lookup/master_detail field, that renderer is
LookupCellRenderer (packages/fields/src/index.tsx), which resolves its reference
target from (field as { reference_to?: string }).reference_to || (field as { reference?: string }).reference — never any other spelling.

FieldMeta never carries either key. Grep confirms zero reference_to / .reference
writes anywhere in recordFields.tsx or ObjectDataTable.tsx — buildFieldMeta used to
resolve a referenceTo (camelCase) member (retired by #6597, itself measured dead end to
end), but neither before nor after that retirement did anything write the snake_case
spelling LookupCellRenderer actually reads.

Two consequences, both currently silent:

1. useRefObjectSchema(referenceTo) inside LookupCellRenderer always resolves
   undefined for cells rendered through this path, so the referenced object's schema
   (nameField / titleFormat) never loads. Display-name resolution for these cells always
   falls back to pickRecordDisplayName's generic .name/.title heuristic instead of
   the schema-aware resolution issue [fields] Lookup chip 显示值走 autonumber 启发式,与 picker(nameField/titleFormat)解析不一致 #2357 built. This is silent because the generic
   fallback usually still produces a readable name — it only diverges when the referenced
   object's display field isn't literally name/title.
2. ReferencedRecordLink's objectName prop is always undefined for these cells, so
   navigable is always false and the cell never renders a real <a> — no drill-through
   click, no middle-click-new-tab, no copy-link, for ANY lookup cell in ObjectDataTable
   or the RecordDetailDrawer. This is silent because the cell still renders fine (as
   plain text via the embedded { id, name } object's display name), so nothing looks
   broken — it just never links.

Positive control confirming the read path itself is fine elsewhere: ObjectGrid
(packages/plugin-grid/src/ObjectGrid.tsx) DOES feed reference_to / reference onto its
own built fieldMeta via applyRelationalMeta, copied straight off the object schema
field def at all three of its call sites — so grid cells in that package get both the
schema-aware name resolution and working drill-through links. plugin-dashboard's two
widgets never adopted the equivalent copy.

Suggested fix shape (not prescriptive — untried)

ObjectDataTable.enrich() and RecordDetailDrawer's per-field loop both already have the
object schema field def in scope (fieldsByName[col.accessorKey] / def). Copying
reference_to (and, for parity with ObjectGrid, display_field / id_field /
description_field) from the schema field def onto the built fieldMeta — the same move
applyRelationalMeta makes — would close both gaps. This is a NEW read (behaviour change,
not a retirement), so it needs its own measurement/authoring pass, which is why it isn't
folded into #6597 (that card's own stop-and-report line: enforcing must not widen
behaviour beyond the documented column-override promise, and this isn't that promise —
it's a different, unrelated gap the investigation surfaced).

Scope note

Not filed against #6597 as a sub-issue: it doesn't depend on that card's ruling either way
(the gap predates and survives both the enforce and withdraw branches — it was present
when referenceTo was still a FieldMeta member, since that member was never the
snake_case spelling either). Filed as an independent card in this repo, since the fix
lands in plugin-dashboard.

[os-sales]

Claim: domain:ui execution seat, session session_01CRJge11jso9TpXRWFt1Z49, branch claude/issue-6694-plugin-dashboard-reference-to.

Dispatch order

type: Bug, priority:p1. Triage promoted this card to pm:queue without adding a ruling comment, so the labels are the disposition and the card body is the brief.

Disclosure: this card was filed by this seat, off a dev report on #6597. A card body written by this seat is evidence about when it was written, exactly like anyone else's — re-derive the read set from the code, do not take the body's file/line claims as measured-now.

Step 1 — re-derive, then confirm the asymmetry

The card's core claim is a contrast, and the contrast is what makes it a defect rather than a design choice:

• plugin-grid's ObjectGrid does feed reference_to / reference onto its built fieldMeta via applyRelationalMeta, at all three of its call sites — so its lookup cells get schema-aware display-name resolution and working drill-through links.
• plugin-dashboard's ObjectDataTable / RecordDetailDrawer never write either key, so LookupCellRenderer resolves undefined, useRefObjectSchema never loads, and ReferencedRecordLink's objectName is always undefined ⇒ navigable always false.

Confirm both sides on your merge-base. If ObjectGrid no longer does what the card says, the asymmetry argument collapses and you should stop and report rather than proceed on the fix shape below.

Step 2 — ⚠️ the published-surface question, answered before you write the fix

The card calls its own suggested fix "a NEW read (behaviour change, not a retirement)". That framing raises a question this order will not pre-judge, because this seat has misjudged exactly this clause before and said so on #6527:

Determine whether FieldMeta (packages/plugin-dashboard/src/recordFields.tsx) is published — re-exported through the package barrel AND reachable through the exports map. An export in a module file is not by itself a published surface; it is published only if it is measured through the barrel and the exports map.

• Not published ⇒ adding keys is internal. Proceed.
• Published ⇒ adding keys widens a published type, which is on the human floor. Stop and report with the measurement; do not push the widening.

Report which of the two you measured, and how. Do not infer it from the file's export keyword alone.

Step 3 — the fix, if step 2 clears it

Both ObjectDataTable.enrich() and RecordDetailDrawer's per-field loop already have the object schema field def in scope. Copy from it the same way applyRelationalMeta does. Two boundaries:

1. Match ObjectGrid's copy set deliberately, don't guess it. The card suggests reference_to plus display_field / id_field / description_field "for parity". Read what applyRelationalMeta actually copies and either match it exactly or state per-key why you diverged. Parity claimed but not measured is how the next card gets filed.
2. Copy, do not re-derive. The point is that these two widgets never adopted an existing move. Adopting it is the fix; inventing a second resolution path in plugin-dashboard is not.

Step 4 — two silent consequences, two separate pins

The card names two independently silent failures. They need separate tests, because either can be fixed while the other stays broken:

1. Display-name resolution falls back to pickRecordDisplayName's generic .name/.title heuristic instead of the schema-aware resolution. This is silent because the generic fallback usually still produces a readable name — so a test using a referenced object whose display field IS name will pass both before and after your fix and pin nothing. Use a referenced object whose display field is not literally name/title.
2. Drill-through: navigable always false, no real link, no middle-click-new-tab, no copy-link — for ANY lookup cell in either widget. Assert the link renders, not just that the cell renders.

Both tests must be RED on your merge-base and GREEN after. Report both readings. Given how quiet this defect is, a test that was never red is the main risk on this card.

Reporting

Report the step-2 published-surface measurement first — it gates everything else. Then the ObjectGrid copy-set comparison, the two red-before/green-after pins, and your changeset score with reasoning (a fix that only restores intended behaviour scores differently from one that adds surface; state which you think this is).

Refs: #6597 (where this surfaced; this card depends on neither branch of its ruling) · #2357 (the schema-aware display-name resolution that never engages here).

---

Generated by Claude Code