Repository navigation
docs(core): drop the rendering claim EXPANDABLE_FIELD_TYPES docblock could not check, and correct its consumer list by four - #8717
Merged
Conversation
… could not check, and correct its consumer list by four
The docblock over `EXPANDABLE_FIELD_TYPES` said an unexpanded `user` id
"renders as `—`". Measured on `da5e4f69e` by resolving each family through
`getCellRenderer` and rendering three unexpanded primitives:
| unexpanded value | lookup / master_detail / tree | user |
|----------------------|-------------------------------|------------------|
| 'u_1' | u_1, plain truncated span | u_1, same span |
| '01HQZX9K2M4N6P8R' | muted em-dash | the raw ULID |
| 'Ada Lovelace' | Ada Lovelace, plain span | the raw string |
Wrong twice over. `user` never drew the em-dash at all — `UserCellRenderer`
has no resolver, no `useLookupName`, no `isLikelyOpaqueId`. And the three
families that do draw it draw it only for values `isLikelyOpaqueId` accepts,
a qualifier the sentence never carried and the whole content of the
behaviour. The opening paragraph carried the same claim ("a bare id
placeholder") and is corrected with it.
The claim is DROPPED rather than rewritten. `@object-ui/core` does not depend
on `@object-ui/fields` in dependencies, peerDependencies or devDependencies,
so no test that can reach this file can render the cell a rewrite would
describe, and nothing here compares a docblock to rendered output: a
replacement would be checked by whatever checked the last one. Its shelf life
was measured too — PR #8698 sits in the merge queue rewriting the `user`
column of that table (on its head `3692f7218` all three primitives render an
unresolved-reference affordance that keeps the raw value; the other three
families are byte-identical on both trees), so a corrected sentence would
have been stale before it landed. The storage claim, which is the half this
set actually depends on and the half its tests can check, is kept.
The consumer list in the same docblock is a hand-kept claim of the same
class, and it was stale by four: objectui#5874 / #6064 converged four more
private copies — resolveActionParams, HeaderHighlight, RecordDetailDrawer,
ObjectKanban — while correcting the previous "fourth and last" claim, and
never added them here. Added, plus a re-derivation recipe: one `git grep`
over the whole tree with no pathspec, its measured counts, and the note that
the sweep was controlled by planting a reader under apps/console/src/ and
confirming the same command found it.
Comment-only; no behaviour. The changeset declares an empty frontmatter —
`check-changeset-presence` requires a declaration for published source even
when nothing releases.
Part of objectui#8693
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YBWFb5YgMU5dw8p2VKj16S
os-justin
marked this pull request as ready for review
September 9, 2026 00:43
os-justin
enabled auto-merge
September 9, 2026 00:43
Contributor
✅ Console Performance Budget
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
Size Limits
|
os-justin
deleted the
claude/issue-8693-expand-fields-rendering-claim
branch
September 9, 2026 01:28
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #8693
Comment-only. One file of published source in
@object-ui/core, plus an empty-frontmatter changeset. No behaviour.The measurement (arm B was chosen because of it, not before it)
Four families x three unexpanded primitives, resolved through
getCellRendererand rendered, onda5e4f69e:lookup/master_detail/treeuser'u_1'u_1—span class="block max-w-full truncate"u_1'01HQZX9K2M4N6P8R'text-muted-foreground'Ada Lovelace'Ada Lovelace, plain spanisLikelyOpaqueIdmeasured alongside:false/true/falsefor the three values.lookup,master_detailandtreeall resolve toLookupCellRenderer;userresolves toUserCellRenderer.So the sentence was wrong twice over, and the second way is the one that matters:
usernever drew the em-dash at all.UserCellRendererhas no resolver — nouseLookupName, noisLikelyOpaqueId.isLikelyOpaqueIdaccepts. That qualifier is the entire content of the behaviour, and the sentence never carried it. A reader was told a human-readable id would degrade visibly; it printed as if it were a name.The opening paragraph carried the same claim in different words ("instead of a bare id placeholder") and is corrected with it — same defect, same docblock, one edit.
The instrument was observed to move. The same harness, same command shape, run against PR #8698's head
3692f7218: theuserrow changes to adata-slot="unresolved-reference"affordance that keeps the raw value (all three primitives), and the other three families come back byte-identical to the table above. A table that changes in exactly one column when exactly one renderer changes is measuring the tree, not printing a constant.Premise check: PR #8698 has NOT landed
The dispatch said objectui#8434 / PR #8698 "has gone through the merge queue". Measured:
state: open,merged: false,merged_at: null; timeline showsadded_to_merge_queueat 2026-09-08T23:28:00Z with no removal and no merge. Content check agrees —origin/mainatda5e4f69econtains no8434reference under the packages' sources, andpackages/fields' newest commit isda5e4f69eitself.It is in the queue, not through it. That does not change the ruling; it sharpens it. The table above is
maintoday, and it is about to stop beingmain.Why B (drop the rendering claim), not A (correct it)
The brief asked, if arm A were taken, what would make the new sentence checkable. The answer is nothing, and it is mechanical rather than a matter of taste:
@object-ui/core'spackage.jsonlists@object-ui/types,@objectstack/formula,@objectstack/specindependencies;peerDependenciesanddevDependenciescontain no@object-ui/fields. The arrow runs the other way:@object-ui/fieldsdepends on@object-ui/core. No test that can reach this file can render the cell a corrected sentence would describe.userreference that resolved to nothing says so (objectui#8434) #8698 is sitting in the queue rewriting theusercolumn of that very table. A sentence written from the table above would have been stale before it landed.So the rendering claim is dropped and the storage claim kept — the half the set actually depends on, and the half
__tests__/expand-fields.test.tsand the identity pins can check. Where an unexpanded reference prints belongs next to the renderers in@object-ui/fields, where a test can fail. The docblock now says that in place of the claim, with the measurement, so the next reader inherits the evidence rather than the conclusion.The consumer list was stale by four — verified with a lit control
The docblock's enumeration of consumers is the argument for
user's membership, and it already carries two recorded falsifications of its own counts. It has a third.Re-derived over the whole tree with no pathspec:
96 files on
da5e4f69e. Dropping tests, changesets and changelogs, the production readers fall into three radii: this file plus 8 naming the set directly, plus 4 callingisExpandableFieldType, plus 13 callingbuildExpandFields.Four live readers were missing from the list, and they share one cause: commit
7c96c9420— "converge four private copies of the reference-bearing field family, and correct the 'fourth and last' claim" (objectui#5874 / #6064) — converged four more copies while correcting the previous count, and never added its own conversions here.packages/app-shell/src/utils/resolveActionParams.ts— reads the set directlypackages/plugin-detail/src/HeaderHighlight.tsx— reads the set directlypackages/plugin-detail/src/RecordDetailDrawer.tsx— throughisExpandableFieldTypepackages/plugin-kanban/src/ObjectKanban.tsx— throughbuildExpandFieldsAll four are in the same commit, all four carry identity pins (
expandableFamily.identity-5874.test.*in three packages). Added to the list in the same commit as the rendering fix — same defect class, same docblock, comment-only, no new verification surface.Lit control (a zero-hit region is otherwise indistinguishable from a blind spot):
apps/has 265 tracked files and zero hits for these names. The same no-pathspec command shape, run for a token known to live there (createRoot), fires onapps/console/src/main.tsxand four more.apps/is inside the swept population.EXPANDABLE_FIELD_TYPESwas written toapps/console/src/, the identical command re-run, and the delta was exactly one file — the plant. It was then removed and the sweep re-run: byte-identical to the pre-plant listing, no residue underapps/.git grepfailed, and the before/after comparison "passed" on0 == 0. The recorded reading is from the run after that was fixed.Other claims in the same docblock that nothing can check
Listed, not fixed — the list is the deliverable. Filed as objectui#8716 for triage.
lookup/master_detail" — a claim about objectql, a different repository.expand-fields.test.tsasserts what goes into$expand, never what a server does with it. Load-bearing in a way the removed sentence was not: it is the stated reasonuseris a member. Wants an anchor, probably not deletion.treenote's "requesting it is harmless and forward-compatible" — same cross-repo class, plus a prediction about servers that do not exist yet. It carries a membership decision.object-ref/filter-condition/recipient-pickerexclusion — nearly fine, and the contrast is instructive: it is anchored (widgetHintOnly: trueinapp-shell/src/utils/paramValueShape.ts, measured present). What is missing is only the reverse link.Verification
All at
1750d7710unless stated. Verdict lines quoted from the tools, not from exit codes.pnpm exec vitest run packages/core/—Test Files 132 passed (132),Tests 2788 passed (2788).Test Files 6 passed (6),Tests 78 passed (78).pnpm --filter @object-ui/core^... buildthenpnpm --filter @object-ui/core run type-check— exit 0. The dependency closure was built first; an unbuilt tree would have reportedTS2307for every workspace import.node scripts/check-changeset-presence.mjs— before the changeset:1 source file(s) of 1 released package(s) changed, and this change adds no changeset. After:1 source file(s) ... declares 1 changeset(s) ... Every one of them has an EMPTY frontmatter — declared as releasing nothing, which is the explicit exemption and a complete answer to this gate.Its own verdict line, per the brief; theskip-changesetlabel is not used and reads nothing here.node scripts/check-changeset-no-major.mjs—No changeset declares a major bump.pnpm check:control-bytes—OK (scanned 6882 tracked text file(s); skipped 85 binary). Additional sweep of the diff for control bytes outside the NUL class: zero hits.pnpm check:comment-mask-corpus—1 file(s) disagree, within the residue objectui#7882 is holding open (ceiling: 1 file(s), 1517 over-masked bytes, 0 fabricated). Unchanged, and the one disagreeing file is not this one.node scripts/check-governed-queue-guard.mjs --test packages/core/src/utils/expand-fields.ts—NOT GOVERNED.@object-ui/corevia its ownlintscript with--format json— 231 files, 0 errors, 532 pre-existing warnings; the single warning in the edited file is@typescript-eslint/no-explicit-anyat thebuildExpandFieldssignature, untouched by this change. The narrowing to one package is safe to state rather than assume:eslint.config.jsconfigures noproject,projectServiceorparserOptions, so no type-aware rule exists and this diff cannot move the verdict on any file outside it.Reverse verification
tscwas proved to actually read this file, so the green type-check is a measurement:type-checkwent to exit 2 with 132error TSlines, the first atexpand-fields.ts(115,65)— the injection site.git checkout HEAD -- packages/core/src/utils/expand-fields.ts, pointed explicitly atHEADrather than a bare checkout from the index. Restoration proved by content: the worktree blob hash is byte-identical to the HEAD blob,git diff HEADis empty, andtype-checkis back to exit 0. The script carries atrap ... EXIT INT TERMwith an absolute path, and it ran only after the work was committed — a restore against uncommitted edits would have deleted the change itself and left every check green.No pin was added, deliberately
This is a comment-only change; there is nothing to pin that would not be the same defect one level up. A test asserting "this docblock does not contain the string
renders as" would be a pin over a claim nobody reads, and a test asserting whatUserCellRendererprints belongs in@object-ui/fieldsnext to the renderer — where PR #8698 is already changing it, and where such a test can fail. The assertion that was observed to fail is the reverse verification above.In-flight neighbours checked
PR #8684 (
normalize-list-view.ts) and PR #8656 (record-title tests) are both open onpackages/core. Neither touchesexpand-fields.tsor.changeset/8693-*; no overlap.🤖 Generated with Claude Code
https://claude.ai/code/session_01YBWFb5YgMU5dw8p2VKj16S
Generated by Claude Code