Found while censusing relationship-target spellings for objectui#6528. Filed rather than folded in — different file, different defect.
apps/console/src/preview-samples.ts, the object sample:
{name: 'account',label: 'Account',type: 'lookup',reference_to: 'account'},reference_to is refused by name. Measured against the installed @objectstack/spec 17.2.0, on an otherwise-green field:
ObjectSchema.safeParse({ name:'census_obj', label:'Census',
fields: { acct: { type:'lookup', label:'Account', reference_to:'crm_account' } } })
=> success:false, code = unrecognized_keys, path = fields.acct
"Unrecognized key(s) on this field: `reference_to`.
Did you mean `reference_to` -> `reference`?"
Positive control, same query shape: the same document spelling the key reference parses green and the value survives the parse.
Why this is worth a card rather than a shrug
The sample is already quarantined in apps/console/src/__tests__/preview-samples-spec-valid.test.ts, but for a DIFFERENT recorded reason:
object: '`fields` is an array; ObjectSchema wants a record keyed by field name',
That ledger is explicitly a "first thing a reader of that sample would copy and get rejected for" list, and its reverse assertion exists so entries can only shrink. Here the recorded reason is incomplete: fixing only the array shape would NOT make this sample parse, because reference_to is independently refused. So whoever picks up the array-shape half will find the sample still red and no note explaining why.
The stakes are the ones that file already argues: these samples are the worked example an author — increasingly a model generating metadata — copies. A lookup target spelled reference_to is wrong semantics propagating from the file that exists to demonstrate right ones.
Not fixed here on purpose
objectui#6528 is scoped to the two consumer-side canonicalizations (resolveReferenceTo, resolveRelationshipTarget). This sample is unreachable from both — the gallery renders SAMPLES as an unparsed draft, and neither consumer is fed by the gallery — so it neither blocks nor is blocked by that cut. Touching it there would also mean re-adjudicating the KNOWN_STALE reason, which is new verification surface for an unrelated file.
Suggested shape
Either re-spell the key to reference and extend the KNOWN_STALE reason to name only the remaining array-shape defect, or record both defects in the reason now so the ledger stays honest. Note the array fields shape is deliberate per its recorded note (it is what covers readFields' array branch in the gallery), so the two halves want separate decisions.
Related: objectui#6041 (retired referenceTo at the designer writers), objectui#6519 (read door strips retired keys).
Found while censusing relationship-target spellings for objectui#6528. Filed rather than folded in — different file, different defect.
apps/console/src/preview-samples.ts, theobjectsample:reference_tois refused by name. Measured against the installed@objectstack/spec17.2.0, on an otherwise-green field:Positive control, same query shape: the same document spelling the key
referenceparses green and the value survives the parse.Why this is worth a card rather than a shrug
The sample is already quarantined in
apps/console/src/__tests__/preview-samples-spec-valid.test.ts, but for a DIFFERENT recorded reason:That ledger is explicitly a "first thing a reader of that sample would copy and get rejected for" list, and its reverse assertion exists so entries can only shrink. Here the recorded reason is incomplete: fixing only the array shape would NOT make this sample parse, because
reference_tois independently refused. So whoever picks up the array-shape half will find the sample still red and no note explaining why.The stakes are the ones that file already argues: these samples are the worked example an author — increasingly a model generating metadata — copies. A lookup target spelled
reference_tois wrong semantics propagating from the file that exists to demonstrate right ones.Not fixed here on purpose
objectui#6528 is scoped to the two consumer-side canonicalizations (
resolveReferenceTo,resolveRelationshipTarget). This sample is unreachable from both — the gallery rendersSAMPLESas an unparsed draft, and neither consumer is fed by the gallery — so it neither blocks nor is blocked by that cut. Touching it there would also mean re-adjudicating theKNOWN_STALEreason, which is new verification surface for an unrelated file.Suggested shape
Either re-spell the key to
referenceand extend theKNOWN_STALEreason to name only the remaining array-shape defect, or record both defects in the reason now so the ledger stays honest. Note the arrayfieldsshape is deliberate per its recorded note (it is what coversreadFields' array branch in the gallery), so the two halves want separate decisions.Related: objectui#6041 (retired
referenceToat the designer writers), objectui#6519 (read door strips retired keys).