finding(lint): a runtime-gate test fixture spells reference: { object: ... }, a carrier ObjectSchema refuses and the rule's own reader ignores #13053

Surfaced by the relationship-target CARRIER census run for objectui#6648 (objectui PR #6718), which walked every reference key in this tree through the TypeScript compiler API. Recording it here because this is the tree the fix lands in.

The fixture

packages/lint/src/runtime-gate.object-writes.test.ts:358, inside "a permission write name-keys findings attributed to CONTEXT objects too":

{
  name: 'shop_invoice_line',
  sharingModel: 'private',
  fields: {
    invoice: { type: 'master_detail', reference: { object: 'shop_invoice' } },
  },
},

Why it is wrong

FieldSchema.reference is a plain string — json-schema/data/Field.json declares {"type": "string"}, "Target object name (snake_case) for lookup/master_detail fields". ObjectSchema.safeParse on spec 17.2.0 REFUSES this carrier: invalid_type: Invalid input: expected string, received object at fields.invoice.reference.

More to the point, the rule this fixture exercises does not read the carrier either. packages/lint/src/validate-security-posture.ts:

function refOf(def: AnyRec): string | undefined {
  const r = def.reference as unknown;
  return typeof r === 'string' && r ? r : undefined;
}

So { object: 'shop_invoice' } resolves to undefined — the master-detail parent is simply unknown to the rule for this fixture. The test still passes because its assertion is about the finding's PATH being name-keyed (objects.shop_invoice_line...), not about the parent. The fixture is carrying a shape the gate cannot see, and would carry it just as silently if the assertion ever grew to depend on the parent.

Across both trees this was the ONLY occurrence of a non-string carrier at a field-def key position that was not itself a test asserting the (now removed) tolerance in objectui's two resolvers — 587 bare-string carriers at that position, and this.

Suggested fix

Spell it reference: 'shop_invoice'. One-line change, and it makes the fixture describe a document the spec would actually accept.

Severity is low: no rule reads it, no assertion depends on it, and nothing ships it. Filed so it is triaged rather than lost — an invalid fixture is how a later assertion gets written against a shape that cannot occur.

Generated by Claude Code