importPredicates is produced by the spec resolver and consumed nowhere — the same inverse-symmetry gap as #4646, one key over #5142

Summary

Found while implementing #4646 (related-list "+ New" consuming createPredicates).

@objectstack/spec@17.0.0 widened both toolbar-scope keys, not just create. UserActionsSchema (spec src/data/object.zod.ts:1528-1531) types them identically:

create: z.union([z.boolean(), RowCrudActionOverrideSchema]).optional()
import: z.union([z.boolean(), RowCrudActionOverrideSchema]).optional()

…and resolveCrudAffordances emits a predicate envelope for each (spec object.zod.ts:2472 and its neighbour). The CrudAffordances docblock states the binding for both in one breath:

> createPredicates — "CEL predicates for the generic New button … these evaluate once per toolbar, against the record in scope where the toolbar renders"
> importPredicates — "Toolbar-scope CEL predicates for the CSV import entry; same binding as createPredicates."

#4646 closed the create half. The import half is still declared-and-inert: importPredicates has zero consumers in objectui src.

Verification (src level, on 958d7573a)

$ grep -rn "importPredicates" --include=*.ts --include=*.tsx packages/ apps/
(no matches)

Producer confirmed live against the installed spec:

$ node -e "…resolveCrudAffordances({managedBy:'platform', userActions:{ import: { enabled:true, visibleWhen:'record.frozen != true' } }})"
{ create: true, import: true, …, importPredicates: { visibleWhen: 'record.frozen != true' } }

Impact

An author can write the object form on userActions.import today — the spec accepts it and the resolver parses it — and objectui silently drops the predicate, offering the CSV import entry unconditionally. Identical shape to the defect #4646 recorded from a downstream EHR project, just on the adjacent key.

Not reported from the field, unlike #4646; whether that makes it lower priority or merely less-noticed is the triage call, not mine. Noting honestly that severity judged at filing time is unreliable in both directions.

Deliberately NOT done in PR for #4646/#4647

That PR widened objectui's local UserActionsOverride.create from boolean to the union so the shape it now honours also type-checks. It left import?: boolean narrow on purpose, with the reason in-code:

> widening the type ahead of a consumer would re-declare the inert-metadata defect this change removes, one key over.

So the type is currently the honest statement of what objectui supports. Fixing this issue means widening that key and adding the consumer together.

Where the consumer would go

Wherever the import entry is offered — the object-list toolbar's Import button. Mirror template is now in-tree: RelatedRecordActionsBridge's evalCreatePredicate + the visibleWhen fails-CLOSED / disabledWhen fails-SOFT split (PR for #4646).

Related

• Related-list toolbar “+ New” does not consume userActions.create predicates — spec 17.0.0 shipped the declaration half, the renderer half is missing (createPredicates produced but never consumed) #4646 — the create half, fixed.
• Row CRUD actions (Edit/Delete) should support per-record visible/disabled CEL predicates #2614 — the original row CRUD predicate feature (edit/delete).
• Record detail header ignores userActions.delete.visibleWhen — the BOOLEAN form of the same key reaches all three delete surfaces, the predicate form only reaches the row kebab #4419 / [console] 记录详情页头不消费 userActions.<action>.visibleWhen:同一谓词列表行已生效、记录页头照旧渲染按钮 #4213 — same family on the detail header.