Surfaced while implementing objectui#6837 half 2 (the reference_to arm deletion), and deliberately left out of that PR: it is a contract-shape question, not part of the arm deletion.
What was measured
packages/plugin-list/src/ListView.tsx builds its filter/sort field candidates in two branches. The objectDef.fields branch reads an OBJECT SCHEMA field def, where reference is the declared spelling; objectui#6837 half 2 narrowed it. The sibling branch — the !objectDef?.fields fallback that reads the view's own declared schema.columns — still reads f.reference_to || f.reference, and was deliberately NOT narrowed, because a list-view COLUMN is a different contract.
Measured against @objectstack/spec 17.2.0's ListColumnSchema, on the installed package:
{ field: 'acct' } parses clean (positive control).{ field: 'acct', reference: 'account' } is REFUSED with unrecognized_keys.{ field: 'acct', reference_to: 'account' } is REFUSED with unrecognized_keys.{ field: 'acct', zzz_nonsense: 1 } is REFUSED identically (negative control).
⭐ The tell is what is ABSENT. On FieldSchema both legacy spellings come back with their own rename hint ("Did you mean reference_to to reference?") because they sit in that schema's aliases map. On ListColumnSchema NEITHER key gets a rename hint — they are not aliases of anything there, they are simply undeclared, exactly like the nonsense key.
Why this is observation-class, not a live defect
Nothing renders wrong today: the branch is a fallback that only runs before objectDef has loaded, and a column that carries neither key just yields referenceTo: undefined, which the filter builder already tolerates. The point is that the read exists at all — it consults two keys that a spec-compliant producer cannot put on a list column, which is the consumer-side tolerance AGENTS.md commandment 0.1 forbids, and the same shape objectui#6711, objectui#6625 and objectui#6597 each retired elsewhere.
What a fix would be
A measurement first, not a sweep. Establish whether any producer in or outside these repos puts a relational target on a list-view COLUMN (as opposed to on the field def the column names). If none does, the read is dead weight and goes; if some does, the question is whether ListColumnSchema should declare the key rather than whether the renderer should keep absorbing it.
Filed unassigned, for triage, by the seat that implemented objectui#6837 half 2. Related: objectui#6837.
Generated by Claude Code
Surfaced while implementing objectui#6837 half 2 (the
reference_toarm deletion), and deliberately left out of that PR: it is a contract-shape question, not part of the arm deletion.What was measured
packages/plugin-list/src/ListView.tsxbuilds its filter/sort field candidates in two branches. TheobjectDef.fieldsbranch reads an OBJECT SCHEMA field def, wherereferenceis the declared spelling; objectui#6837 half 2 narrowed it. The sibling branch — the!objectDef?.fieldsfallback that reads the view's own declaredschema.columns— still readsf.reference_to || f.reference, and was deliberately NOT narrowed, because a list-view COLUMN is a different contract.Measured against
@objectstack/spec17.2.0'sListColumnSchema, on the installed package:{ field: 'acct' }parses clean (positive control).{ field: 'acct', reference: 'account' }is REFUSED withunrecognized_keys.{ field: 'acct', reference_to: 'account' }is REFUSED withunrecognized_keys.{ field: 'acct', zzz_nonsense: 1 }is REFUSED identically (negative control).⭐ The tell is what is ABSENT. On
FieldSchemaboth legacy spellings come back with their own rename hint ("Did you meanreference_totoreference?") because they sit in that schema'saliasesmap. OnListColumnSchemaNEITHER key gets a rename hint — they are not aliases of anything there, they are simply undeclared, exactly like the nonsense key.Why this is observation-class, not a live defect
Nothing renders wrong today: the branch is a fallback that only runs before
objectDefhas loaded, and a column that carries neither key just yieldsreferenceTo: undefined, which the filter builder already tolerates. The point is that the read exists at all — it consults two keys that a spec-compliant producer cannot put on a list column, which is the consumer-side tolerance AGENTS.md commandment 0.1 forbids, and the same shape objectui#6711, objectui#6625 and objectui#6597 each retired elsewhere.What a fix would be
A measurement first, not a sweep. Establish whether any producer in or outside these repos puts a relational target on a list-view COLUMN (as opposed to on the field def the column names). If none does, the read is dead weight and goes; if some does, the question is whether
ListColumnSchemashould declare the key rather than whether the renderer should keep absorbing it.Filed unassigned, for triage, by the seat that implemented objectui#6837 half 2. Related: objectui#6837.
Generated by Claude Code