Filed unassigned by the domain:ui execution seat (PM session session_013hfmP9hoMd3dJwTh85J4yB) — recording, not claiming.
Provenance: surfaced by the reader sweep on #6874 (landed as PR #7020). The dev reported these rather than acting on them, per its dispatch order; ⛔ nothing below was touched by that PR.
Dedupe: searched before filing, and the nil result is a reading rather than a blind instrument — a control query in the same session returned #6874 / #6875 / #6711 (10 hits, all on-topic) while the spelling-fork query returned 0. No open card covers this.
⛔ What this is NOT
Not a dead-key finding. Every spelling below has live readers. #6874 retired titleFormat from RELATIONAL_META_KEYS because it had no field-meta reader; that is a different question and it is settled. This card is about one concept carried under several names, which is the field || schema shape AGENTS.md #0.1 and #3233 forbid — and which is what lets a correctly-authored value parse clean and reach nothing.
Fork 1 — the record-title key, in THREE spellings
| spelling |
site |
receiver |
titleFormat |
core/utils/record-title.ts:432, components/.../containers.tsx:1687, plugin-detail/DetailView.tsx:93, ObjectKanban.tsx:338, ObjectCalendar.tsx:428, react/hooks/useRecordSearch.ts:57, fields/widgets/LookupField.tsx:377 |
OBJECT schema (incl. the referenced object's, via getSchema(referenceTo)) |
titleFormat |
app-shell/utils/paramToField.ts:181 |
a resolved ActionParamDef |
title_format |
app-shell/utils/resolveActionParams.ts:536 |
an object-schema field def |
The third is the interesting one: snake_case, read off a field def, sitting one module away from a camelCase read of what is evidently the same concept. Until PR #7020, ObjectGrid was separately copying titleFormat (camelCase) onto field metas where nothing read it — so the tree has recently carried a camelCase field-def write that reached nothing and a snake_case field-def read that does, for the same idea.
Fork 2 — lookup_filters / lookupFilters, both in the same list
Both are members of RELATIONAL_META_KEYS (plugin-grid/src/ObjectGrid.tsx) and both are read, at the same two sites, as the two arms of a single ??:
fields/src/widgets/LookupField.tsx:270fields/src/widgets/UserField.tsx:53
⇒ the camelCase arm is reachable only when a def carries it and not the snake_case one. So the fork is not decorative: which arm answers depends on how the def happened to be authored, and nothing tells an author the two are the same key.
Why it is finding and p3 rather than a bug
No measured user-visible defect: each fork's readers do resolve today, because each read site tolerates both arms or reads the one its own producer writes. The cost is drift risk and author confusion, not a live failure — the same grading #6887 got for a declaration copy. ⛔ Not raised to p2 without a measured case of a legally-authored value reaching nothing.
What a round would need to decide (⛔ no disposition proposed)
- Is the record-title concept actually one concept across all three sites, or does
ActionParamDef.titleFormat legitimately mean something narrower than an object schema's? ⚠️ This must be answered before any convergence — collapsing two genuinely different concepts is worse than the fork.
- Which spelling is canonical, and does the spec declare it? The convergence direction in this repo is fix the contract, never widen the consumer (AGENTS.md #0.1), so the answer has to come from
@objectstack/spec, not from a majority vote among consumers.
- Whether the
?? fork in RELATIONAL_META_KEYS should be retired to one arm, and if so which — noting that removing either arm from the copy set is an accept-set narrowing for anyone authoring that spelling today, so it needs the announced-retirement treatment (ADR-0087 registries / retirementTombstone()), not a silent deletion.
Related
#6874 / PR #7020 (the retirement that surfaced this), #6875 (the converse: keys the grid's picker reads but never receives), #3233 (field || schema, the same shape converged at its producers), #7014 (a parallel one-contract-many-declarations population).
Filed unassigned by the
domain:uiexecution seat (PM sessionsession_013hfmP9hoMd3dJwTh85J4yB) — recording, not claiming.Provenance: surfaced by the reader sweep on #6874 (landed as PR #7020). The dev reported these rather than acting on them, per its dispatch order; ⛔ nothing below was touched by that PR.
Dedupe: searched before filing, and the nil result is a reading rather than a blind instrument — a control query in the same session returned #6874 / #6875 / #6711 (10 hits, all on-topic) while the spelling-fork query returned 0. No open card covers this.
⛔ What this is NOT
Not a dead-key finding. Every spelling below has live readers. #6874 retired
titleFormatfromRELATIONAL_META_KEYSbecause it had no field-meta reader; that is a different question and it is settled. This card is about one concept carried under several names, which is thefield || schemashape AGENTS.md #0.1 and #3233 forbid — and which is what lets a correctly-authored value parse clean and reach nothing.Fork 1 — the record-title key, in THREE spellings
titleFormatcore/utils/record-title.ts:432,components/.../containers.tsx:1687,plugin-detail/DetailView.tsx:93,ObjectKanban.tsx:338,ObjectCalendar.tsx:428,react/hooks/useRecordSearch.ts:57,fields/widgets/LookupField.tsx:377getSchema(referenceTo))titleFormatapp-shell/utils/paramToField.ts:181ActionParamDeftitle_formatapp-shell/utils/resolveActionParams.ts:536The third is the interesting one: snake_case, read off a field def, sitting one module away from a camelCase read of what is evidently the same concept. Until PR #7020,
ObjectGridwas separately copyingtitleFormat(camelCase) onto field metas where nothing read it — so the tree has recently carried a camelCase field-def write that reached nothing and a snake_case field-def read that does, for the same idea.Fork 2 —
lookup_filters/lookupFilters, both in the same listBoth are members of
RELATIONAL_META_KEYS(plugin-grid/src/ObjectGrid.tsx) and both are read, at the same two sites, as the two arms of a single??:fields/src/widgets/LookupField.tsx:270fields/src/widgets/UserField.tsx:53⇒ the camelCase arm is reachable only when a def carries it and not the snake_case one. So the fork is not decorative: which arm answers depends on how the def happened to be authored, and nothing tells an author the two are the same key.
Why it is
findingand p3 rather than a bugNo measured user-visible defect: each fork's readers do resolve today, because each read site tolerates both arms or reads the one its own producer writes. The cost is drift risk and author confusion, not a live failure — the same grading #6887 got for a declaration copy. ⛔ Not raised to p2 without a measured case of a legally-authored value reaching nothing.
What a round would need to decide (⛔ no disposition proposed)
ActionParamDef.titleFormatlegitimately mean something narrower than an object schema's?@objectstack/spec, not from a majority vote among consumers.??fork inRELATIONAL_META_KEYSshould be retired to one arm, and if so which — noting that removing either arm from the copy set is an accept-set narrowing for anyone authoring that spelling today, so it needs the announced-retirement treatment (ADR-0087 registries /retirementTombstone()), not a silent deletion.Related
#6874 / PR #7020 (the retirement that surfaced this), #6875 (the converse: keys the grid's picker reads but never receives), #3233 (
field || schema, the same shape converged at its producers), #7014 (a parallel one-contract-many-declarations population).