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

Summary

@objectstack/spec@17.0.0 widened userActions.create from a plain boolean to z.union([z.boolean(), RowCrudActionOverrideSchema]) (spec src/data/object.zod.ts:1529, the #7692 family). The docblock defines the semantics: the create toolbar affordance is evaluated once against the record of the scope it sits in — on a record page's related list, that is the host parent record. The spec CHANGELOG entry for that change states explicitly:

"The renderer half — the related-list toolbar honouring create.visibleWhen — is objectui's downstream card and is not part of this change."

This is that downstream card: as of @objectstack/console@17.0.0 (stable), the renderer half does not exist.

Evidence (17.0.0 stable, dist-level survey)

• Across the entire console dist, createPredicates appears exactly 2 times, both on the producer side — the data-adapter's resolveCrudAffordances output. There is zero consumption.
• By contrast, editPredicates and deletePredicates each have ~15 consumption sites and behave correctly (row kebab, related-list rows, and — since 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 / PR fix(plugin-detail): the record detail header honors userActions predicates (#4419) #4515 — the record detail header).
• RecordDetailView's related-list toolbar affordance is still the old two-axis check: create: o.create && can(childObject, 'create') — per-object × per-user only. The component has the parentId (host record) in hand, but evaluates no predicate against it.

So for create, someone produces the predicates and nobody consumes them — the exact inverse-symmetry gap the spec CHANGELOG called out.

Motivating scenario (observed in a downstream EHR project)

A parent record enters a frozen state (published / deprecated):

• Row-level Edit/Delete on the related list correctly grey out / hide via their predicates. ✅
• The related-list toolbar “+ New” stays fully enabled. ❌ The user fills in the entire child form, submits, and only then gets a server-side 409 rejection.

This is precisely the motivation scenario described in the spec CHANGELOG entry for the userActions.create widening. (No security surface — the server gate holds — but the UI walks the user into a form that is guaranteed to fail, while sibling affordances on the same rows are correctly gated.)

Expected

The related-list toolbar consumes userActions.create.visibleWhen / disabledWhen, evaluated once against the host parent record (per the spec docblock), on top of the existing o.create && can(childObject, 'create') check — mirroring how editPredicates / deletePredicates are already consumed on the same surface.

Related

• 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 (a userActions predicate reaching some surfaces but not others), for edit/delete on the detail header; both fixed. This issue is the create + related-list-toolbar member of the family.
• Row CRUD actions (Edit/Delete) should support per-record visible/disabled CEL predicates #2614 — the original row CRUD predicate feature (edit/delete only).
• Downstream tracking: steedos-labs/os-project-titanwind-ehr#1070 (private repo).