Skip to content

test(plugin-grid): render what the inline lookup picker actually receives - #7167

Merged
os-warren merged 1 commit into
mainfrom
claude/issue-7154-lookup-picker-remaining-keys
Sep 1, 2026
Merged

test(plugin-grid): render what the inline lookup picker actually receives#7167
os-warren merged 1 commit into
mainfrom
claude/issue-7154-lookup-picker-remaining-keys

Conversation

@os-warren

Copy link
Copy Markdown
Collaborator

Fixes #7154

Re-derived on origin/main head 51449a043. The card asked for four deferred verdict flips plus rendering proof. The rendering proof killed the premise, so this PR ships the measurement and the corrections it forces, and flips nothing.

The premise, and what falsified it

objectui#7154 says multiple, allowCreate, lookupPageSize and dependsOn are spec-declared, read off fieldMeta by LookupField, absent from RELATIONAL_META_KEYS, and therefore never reach ObjectGrid's inline lookup picker. The first three claims hold on this head. The fourth does not: all four already take effect in the picker, with the copy set unchanged, because the picker is not fed that bag at all.

  • applyRelationalMeta writes onto fieldMeta, and fieldMeta goes to CellRenderer and nowhere else in ObjectGrid.tsx — the read-only cell. For a relational column that is LookupCellRenderer, which reads reference_to, reference, display_field, displayField, reference_field: none of the four.
  • The inline EDITOR is a different seam. renderCellEditor looks the field up in the object schema and spreads the whole def into the widget — { name: ctx.column.accessorKey, ...fieldDef } — so every key a def carries reaches LookupField regardless of the copy set.
  • Both halves read objectSchema.fields[name], the same object, so there is no shape where copying could rescue an editor the schema read did not already serve: when that lookup misses, renderCellEditor returns null and applyRelationalMeta copies nothing, together.

Flipping the four verdicts would therefore write four members onto a bag whose consumer does not read them — the shape objectui#6711 (reference_to_field) and objectui#6874 (titleFormat) each retired.

Per-key rendering evidence

New packages/plugin-grid/src/__tests__/lookupPickerKeys-7154.test.tsx. Each case renders one data source, one referenced object, and two lookup columns whose defs differ ONLY in the key under test — the shape lookupDisplayFieldSpelling-6875.test.tsx established. The control column is load-bearing in both directions.

key declared column control column (same source, key absent)
multiple: true two picks accumulate, trigger reads "2 selected" second pick REPLACES the first, trigger reads "Person 02"
allowCreate: false no quick-create entry in the popover "Create new" present (default ON for a user-facing reference)
lookupPageSize: 3 picker dialog queries $top: 3 and renders 3 rows same dialog over the same 12 records renders 10 (RecordPickerDialog's default)
dependsOn: ['region'] trigger is lookup-trigger-gated, disabled, "Select region first"; browse-all disabled too lookup-trigger-owner, enabled

A fifth case pins the classification half: the copy set is non-empty, contains displayField (the control), and contains none of the four.

Ablations — direction predicted before running, both as predicted

Run from committed 21509d3c8; each mutation proved on disk by anchor/marker counts plus a blob-hash change, each restore proved by git diff HEAD, git diff --cached and git status --short all empty plus a hash equal to the HEAD blob. No build step is involved — this repo's vitest aliases @object-ui/* to sibling src/, so the mutated source is what runs.

  • A1 — strip the four keys from renderCellEditor's spread. Predicted: the four behavioural cases go red, the classification case stays green. Observed: Tests 4 failed | 1 passed (5). The editor seam is the delivery route.
  • A2 — flip all four verdicts deferred to spec. Predicted: only the classification case goes red (it asserts non-membership), every behavioural case unchanged. Observed, against this file plus the derivation gate: Tests 1 failed | 12 passed (13). Flipping is behaviourally inert — it changes the classification and nothing a user sees.

What this changes

  • The four verdicts stay deferred, with the measurement in their notes instead of a promise, so the derivation gate keeps watching them.
  • Corrected the two docblocks (relationalMetaKeys.ts, relationalMetaCopySet.derivation.test.ts) that claimed the inline editor "dispatches the same bag" into LookupField and UserField, and the three applyRelationalMeta call-site comments in ObjectGrid.tsx that said the copy exists so "the inline picker can query". Those sentences are what this card was filed against.
  • Changeset with EMPTY frontmatter — no behaviour change. Gate verdict, verbatim: ✅ 4 source file(s) of 1 released package(s) changed, and this change declares 1 changeset(s): .changeset/7154-lookup-picker-keys-editor-seam.md. / Every one of them has an EMPTY frontmatter — declared as releasing nothing, which is the explicit exemption and a complete answer to this gate.

Assumptions checked

  • A2.2 (all four read on this path) — holds, re-measured on this head: LookupField.tsx reads them at :259, :271, :277, :300. What moved is which bag feeds that file on the grid path.
  • A2.3 (spec still declares all four) — holds. @objectstack/spec 17.2.0 as installed, FieldSchema strict with 71 props; all four declared, none of allow_create / lookup_page_size / depends_on declared; positive control name / type / label present; a nonsense key parses to unrecognized_keys.
  • A2.4 (plugin-dashboard has the same gap) — falsified, and it is not a scope question after all. Its two widgets reach no field editor (renderFieldValue to getCellRenderer, a cell renderer), so the picker keys have no reader there; that verdict is already recorded on CELL_RELATIONAL_META_KEYS and pinned in lookupRelationalMeta-6694.test.tsx. Nothing to fix.
  • A2.5 (nothing pins the current absence) — holds. No test in plugin-grid or plugin-dashboard mentions any of the four.

Filed, not fixed here

  • objectui#7165 — a dependsOn lookup column is permanently uneditable in ObjectGrid. The key arrives (the gate is proof) and the gate never lifts, because the grid supplies no dependent values through any of LookupField's three channels. PR objectui#2216 gave the FORM that injection; the grid never got it. Whether the grid should feed the saved row or the row plus its staged edits is a seam decision, which is why it is filed rather than ridden in here.
  • objectui#7166 — 6 of the 10 keys currently copied onto fieldMeta have no reader on that bag, including two that objectui#6875 added as its fix. Same measurement, opposite direction; retiring them is its own adjudication.

Verification

Union re-run at the final commit 21509d3c8:

  • pnpm exec vitest run over lookupPickerKeys-7154, relationalMetaCopySet.derivation, relationalMetaCopySet-6711, relationalMetaCopySet-6874, lookupDisplayFieldSpelling-6875, inlineEditLookupRepro and plugin-dashboard's lookupRelationalMeta-6694Test Files 7 passed (7) / Tests 35 passed (35).
  • pnpm --filter @object-ui/plugin-grid run type-check — exit 0. First attempt was NOT MEASURED (TS2307 across @object-ui/*, an unbuilt dependency closure); re-run after pnpm --filter '@object-ui/plugin-grid^...' build. tsconfig.test.json includes the new file (1 hit under --listFiles), so the typecheck covers it.
  • pnpm --filter @object-ui/plugin-grid run lint — exit 0, 731 warnings, 0 errors (all pre-existing).
  • check:control-bytes, check:vi-mock-specifiers, check:vi-mock-inherit, check-changeset-presence, check-changeset-no-major, check-changeset-fixed — all exit 0.

Generated by Claude Code


Generated by Claude Code

…ives

objectui#7154 reported that `multiple`, `allowCreate`, `lookupPageSize` and
`dependsOn` never reach `ObjectGrid`'s inline lookup picker, because none of
them is on the relational copy set. Measured against the grid's own inline
editor, all four already take effect: the copy set is not the route.

`applyRelationalMeta` writes onto the `fieldMeta` handed to `<CellRenderer>` —
the read-only cell, whose relational reader `LookupCellRenderer` reads none of
the four. The inline editor is a different seam: `renderCellEditor` looks the
field up in the object schema and spreads the whole def into the widget, so
every key a def carries reaches `LookupField` regardless of this list. Both
halves read `objectSchema.fields[name]`, so there is no shape where copying
could rescue an editor the schema read did not already serve.

New `__tests__/lookupPickerKeys-7154.test.tsx` renders each key against a
control column differing only in that key. The four verdicts stay `deferred`,
now with the measurement in their notes, and the docblocks and call-site
comments that claimed the picker reads this bag are corrected.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012wwHa4aaFybxXrfmfHioDM
@github-actions

github-actions Bot commented Sep 1, 2026

Copy link
Copy Markdown
Contributor

✅ Console Performance Budget

Metric Value Budget
Eager closure (gzip, 48 chunks) 3153.7 KB 3191.4 KB
Main entry chunk (gzip) 142.6 KB 350 KB
Entry file index-RTxbUTE_.js
Status PASS

The eager closure is every chunk the entry reaches through static imports — what the browser fetches and parses before the app renders. The entry chunk on its own is a small fraction of it.


📦 Bundle Size Report

Package Size Gzipped
app-shell (consoleActionDispatch.js) 0.20KB 0.19KB
app-shell (index.js) 15.33KB 5.59KB
app-shell (runtime-config.js) 20.68KB 7.36KB
app-shell (types.js) 0.01KB 0.04KB
app-shell (urlParams.js) 10.06KB 3.86KB
auth (ActiveOrganizationStorage.js) 25.05KB 9.16KB
auth (AuthContext.js) 0.31KB 0.24KB
auth (AuthGuard.js) 2.07KB 1.00KB
auth (AuthProvider.js) 40.18KB 10.59KB
auth (AuthShell.js) 3.49KB 1.40KB
auth (ForgotPasswordForm.js) 12.21KB 3.45KB
auth (LoginForm.js) 18.15KB 5.39KB
auth (PreviewBanner.js) 0.90KB 0.50KB
auth (RegisterForm.js) 6.65KB 2.22KB
auth (SocialSignInButtons.js) 9.61KB 3.89KB
auth (UserMenu.js) 3.41KB 1.23KB
auth (auth-gate-events.js) 1.29KB 0.66KB
auth (authStyles.js) 5.04KB 1.72KB
auth (createAuthClient.js) 40.21KB 10.80KB
auth (createAuthenticatedFetch.js) 8.46KB 3.43KB
auth (index.js) 3.19KB 1.44KB
auth (invitation-status.js) 1.22KB 0.70KB
auth (org-roles.js) 6.66KB 2.78KB
auth (phone-identifier.js) 1.11KB 0.66KB
auth (types.js) 0.59KB 0.35KB
auth (useAuth.js) 5.30KB 1.02KB
auth (useWorkspaceAdminStatus.js) 5.13KB 2.35KB
collaboration (CommentThread.js) 26.08KB 7.56KB
collaboration (LiveCursors.js) 3.17KB 1.27KB
collaboration (PresenceAvatars.js) 6.49KB 2.64KB
collaboration (PresenceProvider.js) 2.79KB 1.13KB
collaboration (index.js) 1.68KB 0.73KB
collaboration (useCollaborationTranslation.js) 6.05KB 2.52KB
collaboration (useCommentSearch.js) 1.98KB 0.88KB
collaboration (useConflictResolution.js) 7.75KB 1.86KB
collaboration (useMentionNotifications.js) 1.81KB 0.68KB
collaboration (usePresence.js) 6.33KB 1.84KB
collaboration (useRealtimeSubscription.js) 7.91KB 2.01KB
components (index.js) 512.32KB 116.52KB
core (index.js) 5.30KB 2.13KB
create-plugin (index.js) 10.08KB 3.26KB
data-objectstack (index.js) 177.67KB 49.45KB
fields (index.js) 244.25KB 61.73KB
i18n (LocalizationContext.js) 1.76KB 0.96KB
i18n (currency.js) 1.22KB 0.64KB
i18n (fallbackInterpolation.js) 6.25KB 2.77KB
i18n (i18n.js) 4.28KB 1.75KB
i18n (index.js) 3.44KB 1.39KB
i18n (pickLocalized.js) 7.62KB 3.26KB
i18n (provider.js) 26.89KB 9.04KB
i18n (useDisplayLocale.js) 2.85KB 1.45KB
i18n (useObjectLabel.js) 33.40KB 8.71KB
i18n (useSafeTranslation.js) 5.60KB 2.33KB
layout (index.js) 38.98KB 10.98KB
mobile (MobileProvider.js) 0.92KB 0.49KB
mobile (ResponsiveContainer.js) 0.94KB 0.38KB
mobile (breakpoints.js) 1.51KB 0.70KB
mobile (createOfflineDataSource.js) 5.61KB 1.75KB
mobile (index.js) 1.55KB 0.62KB
mobile (offlineQueue.js) 3.91KB 1.35KB
mobile (pwa.js) 0.97KB 0.49KB
mobile (serviceWorker.js) 1.48KB 0.62KB
mobile (serviceWorkerSource.js) 3.41KB 1.48KB
mobile (useBreakpoint.js) 1.54KB 0.65KB
mobile (useGesture.js) 6.96KB 1.98KB
mobile (useOfflineSync.js) 1.99KB 0.72KB
mobile (usePullToRefresh.js) 2.53KB 0.85KB
mobile (useResponsive.js) 0.72KB 0.42KB
mobile (useResponsiveConfig.js) 1.37KB 0.63KB
mobile (useSpecGesture.js) 4.32KB 1.64KB
mobile (useTouchTarget.js) 1.01KB 0.54KB
permissions (MePermissionsProvider.js) 11.71KB 4.29KB
permissions (PermissionContext.js) 0.31KB 0.25KB
permissions (PermissionGuard.js) 0.89KB 0.45KB
permissions (PermissionProvider.js) 6.24KB 2.16KB
permissions (discardProofCache.js) 1.04KB 0.55KB
permissions (evaluator.js) 5.12KB 1.74KB
permissions (index.js) 0.93KB 0.41KB
permissions (store.js) 0.91KB 0.42KB
permissions (useFieldPermissions.js) 1.28KB 0.53KB
permissions (usePermissions.js) 4.83KB 2.27KB
plugin-ai (index.js) 15.75KB 3.80KB
plugin-calendar (index.js) 46.92KB 12.93KB
plugin-charts (index.js) 66.84KB 18.86KB
plugin-chatbot (index.js) 190.53KB 45.18KB
plugin-dashboard (index.js) 132.63KB 34.56KB
plugin-designer (index.js) 212.87KB 43.19KB
plugin-detail (index.js) 248.95KB 63.55KB
plugin-editor (index.js) 2.46KB 1.10KB
plugin-form (index.js) 133.11KB 32.61KB
plugin-gantt (index.js) 165.21KB 40.37KB
plugin-grid (index.js) 206.11KB 55.76KB
plugin-kanban (index.js) 53.21KB 14.66KB
plugin-list (index.js) 113.21KB 27.60KB
plugin-map (index.js) 20.20KB 6.66KB
plugin-markdown (index.js) 13.72KB 4.69KB
plugin-report (index.js) 43.51KB 11.94KB
plugin-timeline (index.js) 29.34KB 8.47KB
plugin-tree (index.js) 8.98KB 3.08KB
plugin-view (index.js) 85.90KB 21.12KB
providers (DataSourceProvider.js) 0.75KB 0.39KB
providers (MetadataProvider.js) 1.37KB 0.59KB
providers (ThemeProvider.js) 1.90KB 0.85KB
providers (UploadProvider.js) 11.66KB 3.50KB
providers (index.js) 0.45KB 0.23KB
providers (types.js) 0.01KB 0.04KB
react-runtime (index.js) 5.62KB 2.34KB
react (LazyPluginLoader.js) 4.47KB 1.63KB
react (SchemaRenderer.js) 81.07KB 26.86KB
react (data-invalidation.js) 5.05KB 2.08KB
react (index.js) 3.11KB 1.48KB
react (schema-input.js) 2.32KB 1.24KB
react (spec-input.js) 0.20KB 0.18KB
sdui-parser (codegen.js) 5.41KB 2.34KB
sdui-parser (dashboard-widget-options.js) 3.08KB 1.30KB
sdui-parser (index.js) 4.93KB 2.24KB
sdui-parser (input-type.js) 2.84KB 1.40KB
sdui-parser (parse.js) 20.57KB 5.88KB
sdui-parser (provenance.js) 3.66KB 1.82KB
sdui-parser (types.js) 0.28KB 0.23KB
sdui-parser (validate.js) 10.35KB 3.60KB
types (ai.js) 0.20KB 0.17KB
types (api-types.js) 0.20KB 0.18KB
types (app.js) 2.87KB 0.99KB
types (base.js) 0.20KB 0.18KB
types (blocks.js) 0.20KB 0.18KB
types (complex.js) 2.74KB 1.41KB
types (crud.js) 0.20KB 0.18KB
types (dashboard-filter-alias.js) 6.23KB 2.74KB
types (data-display.js) 3.75KB 1.85KB
types (data-protocol.js) 0.20KB 0.19KB
types (data.js) 0.20KB 0.18KB
types (designer.js) 1.85KB 0.85KB
types (disclosure.js) 0.20KB 0.18KB
types (error-code.js) 1.54KB 0.88KB
types (feedback.js) 0.20KB 0.18KB
types (field-types.js) 0.20KB 0.18KB
types (form.js) 0.20KB 0.18KB
types (http-inflight.js) 8.87KB 3.73KB
types (http-retry.js) 4.32KB 2.02KB
types (icon-key-migration.js) 4.26KB 1.63KB
types (index.js) 4.72KB 2.24KB
types (layout.js) 0.20KB 0.18KB
types (managed-by.js) 0.19KB 0.18KB
types (mobile.js) 2.59KB 1.31KB
types (navigation.js) 0.20KB 0.18KB
types (objectql.js) 0.20KB 0.18KB
types (overlay.js) 0.20KB 0.18KB
types (permissions.js) 0.20KB 0.18KB
types (plugin-scope.js) 0.20KB 0.18KB
types (record-components.js) 0.20KB 0.19KB
types (record-semantics.js) 1.28KB 0.67KB
types (registry.js) 0.20KB 0.18KB
types (reports.js) 0.20KB 0.18KB
types (spec-report.js) 5.05KB 1.93KB
types (spec-ui-namespace.js) 0.20KB 0.19KB
types (system-fields.js) 3.33KB 1.54KB
types (theme.js) 6.28KB 2.87KB
types (ui-action.js) 3.40KB 1.71KB
types (views.js) 0.20KB 0.18KB
types (widget.js) 0.20KB 0.18KB

Size Limits

  • ✅ Core packages should be < 50KB gzipped
  • ✅ Component packages should be < 100KB gzipped
  • ⚠️ Plugin packages should be < 150KB gzipped

Copy link
Copy Markdown
Collaborator Author

⚖️ Ruling on your open question: A — keep Fixes #7154. Reviewed; will arm on green.

Your reasoning is right and I am adopting it. The card's stated acceptance criterion was rendering evidence per key; that evidence now exists and is pinned. Leaving objectui#7154 open would leave a card whose stated defect has been measured absent, while the two real defects it uncovered already have their own cards. Option B costs a triage round and buys nothing the PR body does not state.

⚠️ One condition: the PR body must make the falsification unmistakable, so nobody reading the merge later believes four keys were wired. It reads that way now — keep it that way.

What you falsified, and why it matters more than the card did

The card said four spec-declared keys never reach the inline picker. All four already reach it, with the copy set unchanged:

  • applyRelationalMeta writes onto the fieldMeta handed to CellRenderer — the read-only cell, whose LookupCellRenderer reads none of the four.
  • renderCellEditor is a different seam: it looks the field up in objectSchema and spreads the whole def into the widget, so every key a def carries arrives regardless.
  • Both halves read objectSchema.fields[name] — so copying could never rescue an editor the schema read already served.

That last sentence is the load-bearing one. It is not "the keys happen to arrive anyway"; it is that the proposed mechanism cannot be the delivery path for this consumer, in either direction. A verdict flip would have been inert by construction.

Ablation A2 proves exactly that: flipping all four verdicts deferredspec gives 1 failed | 12 passed (13) — only the classification case moves, every behavioural case unchanged. Ablating the change you declined to make and showing it is behaviourally inert is the strongest possible form of "this was not the fix." Predicted before running, both ablations, with mutation proven by anchor count and blob hash and restore proven by three-way state.

The correction reaches back into objectui#6875, and I have recorded it

objectui#7166's finding means the card I landed an hour ago delivered 1 of the 3 keys it shippeddisplayField genuinely (it is read off the bag by LookupCellRenderer, and its rendering test proves it), while descriptionField and lookupColumns are inert on that bag because LookupField gets them from the schema spread.

I have posted that correction on objectui#6875. The lesson is mine: I required rendering evidence for the defect and got it for one key, then accepted derivation alone for the other two. Derivation establishes that a consumer reads the key — it cannot establish that this bag is how the consumer gets it. Those are different claims and I treated them as one.

dependsOn — not deferred, and correctly so

I fenced dependsOn behind reading objectui#2215 first. You read it: closed COMPLETED by PR objectui#2216, which gave the form live dependentValues injection. The grid never got it. So the key arrives and the picker gates permanently, because the grid supplies none of LookupField's three dependent-value channels.

That is a live defect, not a deferral — filed as objectui#7165, with the saved-row vs staged-row seam decision spelled out rather than pre-made. Exactly the right disposal: the fence asked you to establish what objectui#2215 settled before acting, and establishing it turned a deferral into a finding.

Also right

The docblock and three call-site comments claiming the picker reads this bag are corrected — those sentences are what the card was filed against, so fixing them is fixing the actual defect. The four verdicts stay deferred with the measurement in their notes, so the derivation gate keeps them visible and nobody re-derives this from scratch.

type-check returned NOT MEASURED first (TS2307, unbuilt closure), was named as such rather than reported red, and re-run to a real exit 0 after the closure build. Changeset verdict quoted verbatim — empty frontmatter.


Generated by Claude Code

@os-warren
os-warren marked this pull request as ready for review September 1, 2026 09:06
@os-warren
os-warren added this pull request to the merge queue Sep 1, 2026
Merged via the queue into main with commit c6717be Sep 1, 2026
32 checks passed
@os-warren
os-warren deleted the claude/issue-7154-lookup-picker-remaining-keys branch September 1, 2026 09:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

1 participant