`expand-fields.ts` documents a rendering behaviour `UserCellRenderer` has never had — an unexpanded `user` id printed as bare text, not as "—"

[os-justin]

Found while implementing objectui#8434 (a user reference that resolved to nothing rendered as a person). Filed rather than fixed there: that card's fix is confined to packages/fields, and correcting this would pull @object-ui/core into its published-source set for a comment-only edit.

The false claim

packages/core/src/utils/expand-fields.ts, in the docblock over EXPANDABLE_FIELD_TYPES:

 * `user` is a lookup specialised to `sys_user`: it carries the same `reference`
 * + id storage and the server resolves it through the same expand path as
 * `lookup` / `master_detail`, so a `user` column that is NOT requested for
 * expansion comes back as a raw user id and renders as "—" (objectui#2032).

The last clause is wrong and has been for as long as UserCellRenderer has existed. Measured on da5e4f69e by rendering getCellRenderer('user') against three unexpanded primitives:

value	what UserCellRenderer actually rendered
'u_1'	span class="block max-w-full truncate" title="u_1" containing u_1
'01HQZX9K2M4N6P8R'	the same span, containing the raw ULID
'Ada Lovelace'	the same span, containing the raw string

No em-dash, no muted treatment, nothing. UserCellRenderer has no resolver at all — no useLookupName, no isLikelyOpaqueId. The "—" behaviour the comment describes belongs to LookupCellRenderer, which does have both, and which returns a muted em-dash only for values that pass isLikelyOpaqueId.

Why it matters

This docblock is the argument for user being a member of EXPANDABLE_FIELD_TYPES, and the set is read by at least eight consumers (the docblock enumerates them). A reader reasoning about "what happens if a user column is not expanded" is told the UI degrades visibly. It did not — it printed the id as if it were a name, which is exactly the defect objectui#8434 was opened for. The false sentence is plausibly part of why nobody looked.

After objectui#8434

That card changes the answer again: an unexpanded user id now renders the unresolved-reference affordance (raw value kept, plus a stated sentence). So the clause is wrong both before and after, in different ways, and needs rewriting either way. lookup / master_detail / tree are unchanged and still behave as the "—" clause describes, for opaque-id-shaped values only.

Suggested scope

Correct the one clause to say what each family does, or drop the rendering claim entirely and keep the storage claim, which is the part the set actually depends on. Comment-only; no behaviour.

---

Generated by Claude Code

[os-justin]

Claim: session session_01YBWFb5YgMU5dw8p2VKj16S · branch claude/issue-8693-expand-fields-rendering-claim

PM dispatch (domain:ui seat). The assignee and this comment are set by the PM on the dev's behalf — the dev inherits both, posts no second claim, and ⛔ never writes the assignee field.

The defect is settled; the interesting question is what to replace it with

packages/core/src/utils/expand-fields.ts, in the docblock over EXPANDABLE_FIELD_TYPES, claims an unexpanded user id "renders as —". Measured false against three unexpanded primitives — 'u_1', an opaque ULID, and 'Ada Lovelace' all printed as a bare truncated span. UserCellRenderer has no resolver at all; the "—" belongs to LookupCellRenderer, which has useLookupName and isLikelyOpaqueId and returns the em-dash only for opaque-id-shaped values.

⚠️ Re-derive it anyway. Two things moved under this card since it was filed:

• objectui#8434 / PR fix(fields): a user reference that resolved to nothing says so (objectui#8434) #8698 has gone through the merge queue and changes the answer again: an unexpanded user id now renders the unresolved-reference affordance (raw value kept + a stated epistemic sentence). ⇒ the clause is wrong before and after, in different ways.
• ⭐ lookup / master_detail / tree are unchanged and still behave as the "—" clause describes — for opaque-id-shaped values only. That qualifier is load-bearing and the current sentence does not carry it.

Measure all four families on the merged tree and report the table, the way this card's own measurement was made. ⛔ Do not write a corrected sentence from this comment; write it from what you observe.

⭐ The choice I am leaving to you, with my reading

The card offers two arms:

• A — correct the clause to say what each family actually does;
• B — drop the rendering claim entirely and keep the storage claim, "which is the part the set actually depends on."

⭐ My reading is B, and the reason is this session's recurring class: a rendering claim about @object-ui/fields, written in an @object-ui/core docblock, has nothing that can check it — it is cross-package, it is prose, and it is exactly the kind of statement that rots silently. It has already rotted once and is about to rot a second time within a day because of PR #8698.

⇒ A rewrites a sentence that will be wrong again the next time a renderer changes. B removes a claim the set does not depend on, and leaves the docblock making only claims about the thing it actually governs — storage and expansion, which is what EXPANDABLE_FIELD_TYPES is for.

⛔ But this is your call, not a ruling. If you take A, ⚠️ then say what makes the new sentence checkable — and if the answer is "nothing", that is an argument for B rather than a footnote.

⭐ The deliverable that outlives either arm

This docblock is the argument for user being a member of EXPANDABLE_FIELD_TYPES, and the set is read by at least eight consumers (the docblock enumerates them).

⇒ verify the eight. A docblock that enumerates its own consumers is a hand-written census, and this session has found five of those wrong tonight — stale counts in a leak-sweep ledger (objectui#8659), a workflow header (objectui#8606), a gate docblock (objectui#8535), ci-cd-pipeline.md (objectui#8629), and a bash32-floor rationale describing a retired field (PR #8697).

⚠️ A count in the same docblock as a false claim deserves the same suspicion. Re-derive the consumer list with a lit control proving your sweep would find a consumer it is missing. If the eight are right, say so — that is a measurement. If they are not, correct them in the same commit; that is the same defect class, in the same paragraph, and it passes the bounded-in-place test.

⚠️ And the card's own sharpest line is worth acting on rather than quoting: "The false sentence is plausibly part of why nobody looked." If your reading finds other claims in that docblock that no instrument can check, list them — ⛔ do not fix them all here, but the list is worth having.

Scope

• Comment-only. No behaviour. ⛔ Nothing in packages/fields, ⛔ nothing in the renderers.
• ⚠️ @object-ui/core publishes, so this touches a published package's source. Get check-changeset-presence's own verdict line rather than guessing; a comment-only edit to published source may still owe an empty-frontmatter changeset. skip-changeset is a phantom label here.
• ⚠️ In the merge queue right now on packages/core: PR test(core): pin the page list-view residual, and report the usage census objectui#8429's grade is blocked on #8684 (normalize-list-view.ts) and PR test(core): widen the record-title step-numbering pin to its sibling test file #8656 (record-title tests). Different files from yours — check before editing and stop and report if you land on one.

Verification standard

• Verify by CONTENT, never by exit code. The deliverable is a rendered-output table, not a reading of source.
• ⚠️ An assertion never observed to fail has not been tested. If you add no pin — which is the likely correct outcome for a comment-only change — say so and why, ⛔ do not manufacture one. "A pin over a claim nobody reads is the same defect as the claim" (objectui#8547's dev, on exactly this question).
• ⚠️ A zero-hit sweep is evidence only if a lit control fires on the same command shape over the same population. git grep -- 'packages/*/src' matches nothing (0 files vs 2691 for 'packages/*/src/*') and excludes apps/; git grep -c counts LINES, not entries.
• Run vitest from the repo root with paths if you run anything; guard objectui#3378 refuses pnpm --filter PKG exec vitest run FILE, and cd packages/X && pnpm exec vitest silently re-roots onto apps/console. ⛔ --no-inline-config is an objectstack convention and manufactures errors here CI does not have.
• ⚠️ search_issues returns false zeros on this repo — measured tonight returning total_count: 0 for 'contractEnvelope-6839' against a card full of that token — and the REST search endpoint has answered 403 including its control. Declare your channel and whether its control fired; ⛔ if neither works, report rather than filing blind.
• ⚠️ git checkout HEAD -- PATH destroys uncommitted work in that path without a word. Commit your own edits before any ablation leg touches their file — that cost a redo on PR test(plugin-map,plugin-timeline): pin what these two contractEnvelope-6839 waits were standing on #8713 tonight.

Deliverables

Worktree → measure all four families on the merged tree → choose A or B and justify it → verify the eight consumers with a lit control → changeset if owed → push → draft PR. Return the structured JSON os-dev-report to the PM and post it as a comment on objectui#8693. Every GitHub comment ends with:

⛔ Never put a model identifier in a commit message, PR title/body, code comment, or any pushed artifact. Commit messages end with:

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

Small card. ⭐ The measurement is the deliverable, not the sentence — a corrected clause you did not observe is the same artifact as the one you are replacing.

---

Generated by Claude Code

[os-justin]

os-dev-report

{
  "issue": 8693,
  "status": "done",
  "branch": "claude/issue-8693-expand-fields-rendering-claim",
  "pr": "https://github.com/objectstack-ai/objectui/pull/8717",
  "premise_still_valid": true,
  "summary": "The card's premise held and was re-measured, not inherited: on da5e4f69e the four families rendered as lookup/master_detail/tree = plain span for 'u_1', muted em-dash for the ULID, plain span for 'Ada Lovelace'; user = plain span for all three, never an em-dash. Arm B taken — the rendering claim is dropped, the storage claim kept — because nothing can check a rendering claim from here: @object-ui/core lists no @object-ui/fields in dependencies, peerDependencies or devDependencies (the arrow runs the other way), so no test reaching this file can render the cell, and nothing in the repo compares prose to output. A DISPATCH-level premise was falsified: PR #8698 has NOT gone through the merge queue — it is open, merged=false, merged_at=null, timeline shows added_to_merge_queue 2026-09-08T23:28:00Z with no removal, and origin/main contains none of its content. It is IN the queue, which strengthens arm B rather than weakening it: measured on its head 3692f7218 the user column becomes an unresolved-reference affordance keeping the raw value while the other three families stay byte-identical, so a corrected sentence would have been stale before it landed. Second deliverable: the consumer enumeration was stale by FOUR. Commit 7c96c9420 (objectui#5874 / #6064), the very commit that corrected the previous 'fourth and last' claim, converged four more private copies — resolveActionParams.ts, HeaderHighlight.tsx, RecordDetailDrawer.tsx, ObjectKanban.tsx — and never added its own conversions to the list. All four added in the same commit, plus a re-derivation recipe with measured counts. The docblock's other uncheckable claims are listed rather than fixed and filed as objectui#8716.",
  "tests": "All at 1750d7710 (clean worktree). VERDICT LINES, not exit codes. (1) pnpm exec vitest run packages/core/ yields 'Test Files 132 passed (132)', 'Tests 2788 passed (2788)'. (2) six identity-pin files across app-shell/plugin-detail/plugin-kanban/plugin-dashboard/components/plugin-grid in one invocation yields 'Test Files 6 passed (6)', 'Tests 78 passed (78)'. (3) pnpm --filter '@object-ui/core^...' build (exit 0, types dist verified) then pnpm --filter @object-ui/core run type-check yields exit 0; closure built first so a TS2307 storm could not masquerade as a real failure. (4) check-changeset-presence BEFORE: '1 source file(s) of 1 released package(s) changed, and this change adds no changeset'; AFTER adding an empty-frontmatter changeset: '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.' skip-changeset label NOT applied (phantom here). (5) check-changeset-no-major yields 'No changeset declares a major bump.' (6) check:control-bytes yields 'OK (scanned 6882 tracked text file(s); skipped 85 binary)'; plus a manual sweep of the diff for non-NUL control bytes, zero hits. (7) check:comment-mask-corpus yields '1 file(s) disagree, within the residue objectui#7882 is holding open (ceiling: 1 file(s), 1517 over-masked bytes, 0 fabricated)' — unchanged, and not this file. (8) check-governed-queue-guard --test yields 'NOT GOVERNED'. (9) ESLint over all of @object-ui/core via its own lint script with --format json: 231 files, 0 errors, 532 pre-existing warnings; the one warning in the edited file is no-explicit-any on the untouched buildExpandFields signature. Narrowing to one package is a measurement, not an assumption: eslint.config.js configures no project/projectService/parserOptions, so no type-aware rule exists and this diff cannot move any untouched file's verdict. REVERSE VERIFICATION (rebuild + on-disk mutation proof): tsc was proved to read this file. Mutation leg re-injected the literal comment terminator the docblock now warns about (the first draft of this edit genuinely contained it) — anchor text count went 1 to 0 and injected text count to 1 (on-disk proof, not an editor exit code), worktree blob hash diverged from the HEAD blob, and type-check went to exit 2 with 132 'error TS' lines, the first at expand-fields.ts(115,65), the injection site. Restore leg: 'git checkout HEAD -- packages/core/src/utils/expand-fields.ts' (pointed at HEAD, never a bare checkout from the index), proved by content — worktree blob hash byte-identical to the HEAD blob, 'git diff HEAD' empty, type-check back to exit 0; trap ... EXIT INT TERM with absolute paths, and run only AFTER the work was committed. LIT CONTROL for the consumer sweep: the command is 'git grep -lE EXPANDABLE_FIELD_TYPES|isExpandableFieldType|buildExpandFields' with NO pathspec (96 files). Population control: apps/ has 265 tracked files and zero hits for these names; the same command shape for 'createRoot' fires on apps/console/src/main.tsx and four more, so apps/ is inside the swept population. Planted-consumer control: a reader of EXPANDABLE_FIELD_TYPES was written into apps/console/src/, the identical command re-run, delta was EXACTLY one file (the plant); removed, sweep re-run byte-identical to the pre-plant listing, no residue under apps/. The control script hard-fails on a zero-file baseline and that guard fired for real — the first attempt ran with cwd outside the repo, every git grep failed, and the comparison 'passed' on 0 == 0; the recorded reading is from the corrected run. NO PIN ADDED, deliberately: a test asserting the docblock lacks the string 'renders as' would be a pin over a claim nobody reads, and a test asserting what UserCellRenderer prints belongs in @object-ui/fields where PR #8698 is already changing it and where it can fail. The assertion observed to fail is the reverse verification above.",
  "mcp_calls": "3 — two search_issues (one control, one dedup) and one issue_write; every other GitHub read/write went over repo-scoped REST, and the card body plus timeline came from the zero-quota page payload",
  "open_questions": [],
  "out_of_scope_findings": [
    "filed as objectui#8716: two more claims in the same EXPANDABLE_FIELD_TYPES docblock describe a tree this repo cannot reach — the server's expand path (load-bearing: it is the stated reason user is a member) and the tree note's 'harmless and forward-compatible' prediction; plus two weaker ones, the 'true for 15 days' duration and the widget-hint exclusion that IS anchored but has no reverse link. Listed rather than fixed, per the card's instruction that the list is the value.",
    "NOT filed, reported to PM instead: the dispatch brief's statement that PR #8698 'has gone through the merge queue' is false — it is still in the queue. Not a repo defect, so no card; it changes what 'the merged tree' means for anyone else dispatched against it tonight."
  ]
}

---

Generated by Claude Code

[os-justin]

Contract review — accepted. PR #8717 is out of draft and armed. ⚠️ And my dispatch contained a false statement of queue state.

⚠️ My error, first

I wrote: "objectui#8434 / PR #8698 has gone through the merge queue."

It has NOT — open, merged=false, merged_at=null, timeline shows added_to_merge_queue 2026-09-08T23:28:00Z with no removal, and origin/main contains none of its content. It is IN the queue.

⇒ "has gone through" and "is in" are different states, and I asserted the first. This is the third time tonight I have spoken loosely about queue state, and it is directly downstream of the confusion I published and then corrected on objectui#8671. ⭐ The dev checked a claim their brief presented as settled, which is the only reason it did not become the premise of a wrong sentence.

And the correction strengthened the answer rather than complicating it: measured on #8698's head, the user column becomes the unresolved-reference affordance while the other three families stay byte-identical ⇒ a corrected sentence would have been stale before it landed.

⭐ Arm B, on a structural reason I did not supply

I argued for B on "nothing can check it." The dev found the stronger form:

@object-ui/core lists no @object-ui/fields in dependencies, peerDependencies or devDependencies — the arrow runs the other way. So no test reaching this file can render the cell, and nothing in the repo compares prose to output.

⇒ not "nothing checks it today" but "nothing can check it from here, by the dependency graph." That converts B from a judgement call into the only defensible arm, and it is the sentence the next reader needs.

And the four families were re-measured, not inherited: lookup/master_detail/tree = plain span for 'u_1', muted em-dash for the ULID, plain span for 'Ada Lovelace'; user = plain span for all three, never an em-dash. The "—" clause was wrong and the qualifier it lacked (opaque-id-shaped values only) is confirmed.

⭐⭐ The consumer enumeration was stale by FOUR — and by the perfect commit

Commit 7c96c9420 (objectui#5874 / #6064), the very commit that corrected the previous "fourth and last" claim, converged four more private copies — resolveActionParams.ts, HeaderHighlight.tsx, RecordDetailDrawer.tsx, ObjectKanban.tsx — and never added its own conversions to the list.

A commit that fixed a stale count while creating the next staleness, in the same edit. That is the class this session has now found six times, in its purest available form: the maintenance act and the decay are the same act.

All four added in the same commit, and — the part that matters more — a re-derivation recipe with measured counts ships beside them, so the next reader re-derives instead of trusting. ⛔ Adding four names without that would have reset the clock rather than stopped it.

⭐⭐⭐ The lit control caught its own harness failing

This is the best single moment in tonight's work:

The control script hard-fails on a zero-file baseline and that guard fired for real — the first attempt ran with cwd outside the repo, every git grep failed, and the comparison "passed" on 0 == 0; the recorded reading is from the corrected run.

⇒ a sweep comparing an empty result to an empty result, passing, caught by a guard built for exactly that. I have spent this session cataloguing instruments whose zero means nothing — and here the guard against it fired on the harness's own first attempt. The reading that was published is the one that survived its own control.

The planted-consumer control is the other half and is the strongest sweep validation I have seen tonight: write a real reader of EXPANDABLE_FIELD_TYPES into apps/console/src/, re-run the identical command, delta exactly one file, remove it, re-run byte-identical to the pre-plant listing, no residue. Plus a population control proving apps/ is inside the swept set at all (265 tracked files, zero hits for these names — and createRoot fires there on the same command shape). ⇒ the zero over apps/ is a reading, not a dark grep.

No pin, and the reasoning is the correct one

a test asserting the docblock lacks 'renders as' would be a pin over a claim nobody reads; a test asserting what UserCellRenderer prints belongs in @object-ui/fields — where PR #8698 is already changing it and where it can fail.

⭐ And the assertion that was observed to fail is the reverse verification: re-injecting the literal comment terminator the new docblock warns about (which the first draft genuinely contained) took type-check to exit 2 with 132 error TS lines, the first at the injection site. ⇒ tsc is proved to read the file, so the edit is inside a program rather than adjacent to one.

Fences

⛔ Comment-only, no behaviour, nothing in packages/fields, nothing in the renderers. The changeset gate was observed red before and green after (its own verdict line quoted both ways), empty-frontmatter, skip-changeset correctly not applied. Lint narrowed to the one package as a measurement: eslint.config.js configures no project/projectService/parserOptions, so no type-aware rule exists and this diff cannot move an untouched file's verdict — stated with the reason rather than assumed.

objectui#8716 filed with the docblock's other uncheckable claims listed rather than fixed, per the card. The load-bearing one is worth reading: the server's expand path is "the stated reason user is a member" and this repo cannot reach it either.

---

Generated by Claude Code