Found by driving the app-crm example as a real user end-to-end (boot → sign-up/session → CRUD → record clone → aggregation → domain actions → RBAC → console UI). The core path is solid (auth, CRUD, clone, aggregation, audit stamping, metadata, console all work); these two are the runtime gaps that surfaced.

1. Delete of a parent with a required-FK child failed with a misleading error (data layer)

Deleting a crm_account that has crm_opportunity children returned:

400 {"error":"account is required","code":"VALIDATION_FAILED","fields":[{"field":"account",...}]}

…naming account, a field that isn't even on crm_account. Root cause: cascadeDeleteRelations defaults a lookup FK to set_null; for the required crm_opportunity.account FK it issued an UPDATE clearing the column, which the child's required-field validator rejected. A required FK can't be nulled — that's a contradiction, not the author's intent.

Fix: a defaulted set_null on a required FK now escalates to restrict (SQL's standard for a NOT NULL FK):

409 {"error":"Cannot delete crm_account (…): 4 dependent crm_opportunity record(s) reference it via account
     (account is required, so it cannot be cleared). Delete or reassign them first, or set
     deleteBehavior:'cascade' on crm_opportunity.account.",
     "code":"DELETE_RESTRICTED","dependentObject":"crm_opportunity","dependentCount":4}

Explicit cascade/restrict and optional (nullable) lookups are unchanged. New engine-cascade-delete.test.ts (4 cases: required→restrict, no-dependents→ok, optional→set_null, explicit cascade→removed).

2. Removed the hardcoded POST /data/lead/:id/convert endpoint + convertLead (false surface)

The route and convertLead baked bare object names (lead/account/contact/opportunity) and a fixed Salesforce field mapping into the framework runtime. So it's unreachable by any real app: /data/crm_lead/:id/convert → 404, and the literal lead object doesn't exist. The CRM models conversion correctly as a flow (crm_convert_lead_wizard screen flow) — a CRM-specific workflow doesn't belong hardcoded in the framework. Untested, undocumented, no consumers. Removed (narrow-and-true).

Verification

• Live CRM run (rebuilt packages): delete-with-children → 409 clear message; childless delete → 200; record clone (same data-action group) unaffected → 201; convert route gone → 404.
• @objectstack/objectql 637 (+4 cascade tests), @objectstack/rest 121 green.

Not fixed here — needs a product call (Gap 3)

A third finding is a deliberate posture, not a bug, so I did not flip it unilaterally: a freshly-authenticated user who resolves to zero permission sets has object-permission enforcement skipped (security-plugin.ts:325 if (permissionSets.length > 0)), i.e. fail-open when unconfigured. This lets apps with no security metadata "just work," but means once an app defines permission sets without assigning them to every user, unassigned users get full read/create instead of none. Flipping to default-deny would break every app that doesn't assign permission sets to all users (showcase, todo, the CRM itself). Tracking separately for a design decision (default-deny-when-object-has-any-permission-set, a default authenticated permission set, or an explicit secure-by-default flag).

🤖 Generated with Claude Code