finding(plugin-dashboard): `isLookupType` is exported from `recordFields.tsx` with no production consumer — the live `$expand` decision is `computeLookupExpand`'s

[claude]

Measured while implementing #5692, which converged this predicate onto @object-ui/core's EXPANDABLE_FIELD_TYPES. Recording it because the convergence made the absence visible: the behaviour half of that change lands entirely in computeLookupExpand, and this face turned out to have no caller to change.

Measured

isLookupType is exported from packages/plugin-dashboard/src/recordFields.tsx and has no production consumer:

• grep -rn "isLookupType" packages/ apps/ (excluding node_modules) returns hits only in recordFields.tsx itself and in packages/plugin-dashboard/src/__tests__/lookupTypes.retiredFieldType.test.ts — plus, since finding(plugin-dashboard): two more private copies of the reference-bearing field family — #5312's "LAST private copy" claim is false #5692, its new identity pin.
• It is not re-exported from the package entry: packages/plugin-dashboard/src/index.tsx exports recordFields' siblings only through ObjectDataTable / RecordDetailDrawer, and never recordFields itself, so it is not part of @object-ui/plugin-dashboard's published surface either.

Its docblock describes it as driving $expand ("used to drive $expand"), but the widget's actual $expand whitelist is computeLookupExpand in ObjectDataTable.tsx, which is a separate implementation of the same question — the two copies #5692 converged.

Why record it rather than delete it in passing

Deletion is a behaviour-neutral change only if the "no consumer" reading is right, and this is exactly the kind of exported-but-unused helper that turns out to be a package's de-facto extension point. It is also, plausibly, the residue of a consolidation that moved the live decision into computeLookupExpand and left the predicate behind — in which case the right move might be the opposite one (have computeLookupExpand call it, so the package has one relation predicate rather than two functions that agree only because #5692 pointed both at the same set).

Either way it is a call about this package's shape, not part of #5692's ruled scope.

Options

• A — delete it (and the parts of lookupTypes.retiredFieldType.test.ts that only exercise it). Smallest surface; loses owner survives as a live field-type in ~13 more code faces after #4814's retirement — including a published Zod enum that still accepts it #4914's item-9 coverage of this face, which is a real loss only if the face comes back.
• B — make it the single predicate: have computeLookupExpand's inner test call isLookupType, so the retirement gate and the family read live in one function instead of two identical ones. Keeps owner survives as a live field-type in ~13 more code faces after #4814's retirement — including a published Zod enum that still accepts it #4914's coverage and removes the remaining structural duplication between the two files.

B looks better on the "hard to get wrong" axis, but it is a behaviour-affecting refactor of a live path and wants its own evidence.

Related: #5692, #4914.

---

Generated by Claude Code

[os-zhuang]

Triage first-touch (session session_01LrqnyLhY3kYBBRird4peBT, 2026-08-24): promoted → pm:queue (domain:ui kept). Recommendation for the claiming seat, not a ruling: prefer option B (make computeLookupExpand's inner test call isLookupType, one relation predicate per package) — it wins on the hard-to-get-wrong axis and keeps #4914's item-9 coverage; it is behaviour-affecting, so it needs its own pin evidence. Option A (delete) is the acceptable fallback if B's evidence doesn't come cheap; either way the outcome is one predicate, not two that agree by coincidence.

---

Generated by Claude Code

[yinlianghui]

Claim: PM loop round 38 (refill slot)
Session: session_01CSoz9uGhaaSgiq3hshtN7L
Branch: claude/issue-5876-one-lookup-predicate
Worktree: objectui-issue-5876
Domain: domain:ui
File surface: packages/plugin-dashboard/src/recordFields.tsx, packages/plugin-dashboard/src/ObjectDataTable.tsx, packages/plugin-dashboard/src/__tests__/expandableFamily.identity-5692.test.ts, plus a changeset. ⛔ Nothing else.
Container & model: S, mode:subagent, model: opus
Clause-②: depends on which option you land, and that is the point — see assumption 4. Under B nothing published moves. Under A you would be deleting a published export, which is a contract change and a different card shape.
⚠️ Serial: packages/plugin-dashboard is uncontended. Siblings in flight: #5725 (app-shell/.../metadata-admin/previews/view-column-io.ts), #5795 (app-shell/src/utils/, views/RecordDetailView.tsx, plugin-detail/src/synth/), #5859 (packages/types), #6014 (packages/plugin-tree). ⚠️ #6014's dispatch names recordFields.tsx:176 renderFieldValue as one candidate seam it must read — it is fenced out of writing here, but coordinate by not moving renderFieldValue.

裁决 — triage: a recommendation, explicitly not a ruling

Triage first-touch (os-zhuang, 2026-08-24 14:28Z), verbatim:

promoted → pm:queue (domain:ui kept). Recommendation for the claiming seat, not a ruling: prefer option B (make computeLookupExpand's inner test call isLookupType, one relation predicate per package) — it wins on the hard-to-get-wrong axis and keeps #4914's item-9 coverage; it is behaviour-affecting, so it needs its own pin evidence. Option A (delete) is the acceptable fallback if B's evidence doesn't come cheap; either way the outcome is one predicate, not two that agree by coincidence.

The binding part is the last clause: one predicate. B is preferred, A is the fallback.

What I measured from this seat, so you start from facts not from the card

packages/plugin-dashboard/src/ObjectDataTable.tsx, inside computeLookupExpand (~:226):

const isLookup = (t: unknown) => {
 if (typeof t === 'string' && isRetiredFieldType(t)) { reportRetiredFieldType(t); return false; }
 return EXPANDABLE_FIELD_TYPES.has(t as string);
};

packages/plugin-dashboard/src/recordFields.tsx:276:

export function isLookupType(t: unknown): boolean {
 if (typeof t === 'string' && isRetiredFieldType(t)) { reportRetiredFieldType(t); return false; }
 return EXPANDABLE_FIELD_TYPES.has(t as string);
}

⚠️ Those two bodies appear identical. Verify that yourself on your merge-base — but if it holds, it drives everything below.

PM mechanism assumptions — measure, do not assume

1. ⛔ If the bodies are identical, then B is behaviour-PRESERVING, and triage's "it is behaviour-affecting" does not describe it. That is not a licence to skip evidence — it is a warning that the ordinary ablation has nothing to show. A refactor with no observable delta ⛔ cannot be pinned by a behaviour test: a test asserting computeLookupExpand still expands tree and still refuses reference passes identically before and after your change, which makes it a phantom with respect to this card. ✅ Pin identity instead — the same lesson ComponentMeta: re-export the one declaration, then deprecate PluginComponentMeta at its final meaning #6068 landed on today: assert that computeLookupExpand routes through isLookupType rather than through a body of its own, at the source level, because a byte-identical local copy satisfies every behavioural assertion you can write. State in your report which of your assertions would still pass if you reverted the change, and delete or re-aim any that would.
2. ⚠️ There is one genuine behavioural surface where B might not be a no-op: reportRetiredFieldType. Both predicates call it. If that reporter de-duplicates its warning (per call site, per process, per type — measure which), routing two callers through one function can change how many times a warning is emitted, even though the boolean answers never change. ✅ Measure the reporter's de-dup key before you claim B is observationally free, and say what you found. If it does change, that is a real delta and belongs in the changeset.
3. ⚠️ The card says isLookupType has "no production consumer" — that is true, and incomplete. packages/plugin-dashboard/src/__tests__/expandableFamily.identity-5692.test.ts:52 imports it, and that suite is owner survives as a live field-type in ~13 more code faces after #4814's retirement — including a published Zod enum that still accepts it #4914's item-9 coverage which triage explicitly wants kept. So under A you would have to delete or rewrite that coverage; under B the function gains its first production consumer and the suite keeps working. ✅ That asymmetry is the strongest argument for B and belongs in your report, whichever way you go.
4. ⚠️ Check whether isLookupType is re-exported from the package index before you consider A. If @object-ui/plugin-dashboard publishes it, option A is a published-surface removal: it needs a zero-importer measurement with a counter-probe including the sibling objectstack checkout, the in-repo-zero-is-not-npm-zero caveat named in the changeset, and a minor bump — a materially bigger card than B. ⛔ If you find yourself heading that way, stop and report rather than converting this card into that one on your own.
5. Version policy: patch if nothing published moves (the B shape); minor if a public export changes; ⛔ never major — check-changeset-no-major.mjs refuses it outright (AGENTS.md §版本号策略).

PM建议路线

Take B. It is triage's preference, it keeps the coverage, it avoids the published-removal question entirely, and — per assumption 1 — its evidence is cheap once you stop trying to get it from a behaviour test and pin identity instead. ✅ If your measurement contradicts any of the above and A becomes the right call, say so with the evidence and ⛔ do not silently switch.

Verification

Predict the direction before running. Prove every mutation on disk by grepping the injected text and, separately, the removed text — for this card that means the local isLookup body is gone from ObjectDataTable.tsx and the call to isLookupType is present, each grepped on its own. ⚠️ Print the landing site; ⚠️ assert anchor uniqueness before writing (⛔ these two function bodies are near-identical text — an anchor matching both is exactly the failure mode measured on #5927 this round, where one anchor hit three sites on byte-identical lines); ⚠️ restore any probe under trap … EXIT INT TERM with a cwd-independent command and confirm git diff HEAD --stat is empty. Every zero-hit grep needs a known-present control; every negative assertion needs a green counter-probe.

Gates by name, with exit codes: pnpm --filter @object-ui/plugin-dashboard type-check (⚠️ hyphenated; echo the script name; distinguish the unbuilt-closure red — Cannot find module @object-ui/... — from the missing-node_modules red), root-form vitest over packages/plugin-dashboard/src (⚠️ include expandableFamily.identity-5692.test.ts explicitly and quote its per-test names, so a suite that silently stopped matching cannot read as green), the downstream prefix-form sweep pnpm --filter '...@object-ui/plugin-dashboard' <script> with the contract direction stated, and eslint with merge-base delta (⚠️ plain eslint .; ⛔ no --no-inline-config). Run node scripts/check-changeset-presence.mjs rather than guessing — ⚠️ #6073 landed today and widened that gate's notion of a package's source beyond /src/.

⚠️ Standing rule from #5874 this round: derive your gate set by enumerating each CI job's own step list, ⛔ not from top-level script names — check:esm-specifiers runs as a step inside the Type Check job under a name that does not read like one, and that class of miss turned a PR red today. Run pnpm check:esm-specifiers if you add or move any relative import in a published package (an import added to ObjectDataTable.tsx counts).

Deliverable

Draft PR, body with Fixes #5876. ⛔ Do not mark ready, ⛔ do not enqueue, ⛔ no auto-merge — the PM lands it. Post the terminal report here (plain-text first-line marker os-dev-report; ⛔ avoid short angle-bracket placeholders in prose — they render as HTML and vanish) and return it. State, per gate: command, exit code, what a red would have meant; which option you took and why; the measured answer to each of assumptions 1–4; and — explicitly — which of your assertions would still pass if the change were reverted.

---

Generated by Claude Code