@object-ui/plugin-form 16.0.0 → 17.1.0

package/CHANGELOG.md

@@ -1,5 +1,716 @@
 # @object-ui/plugin-form
 
+## 17.1.0
+
+### Minor Changes
+
+- 38ca8be: refactor(fields): `requiredWhen` is the only required-predicate slot — drop the retired `conditionalRequired` alias
+
+  `@objectstack/spec` 17 (objectstack#3855) **retired** `Field.conditionalRequired`,
+  the long-deprecated alias of `requiredWhen`. ObjectUI carried a back-compat read
+  for it in seven places; all of them are removed.
+
+  The removal is safe because the spec did not merely _stop emitting_ the key — it
+  made authoring it **fail loudly**. `retiredKey()` declares the key as
+  `z.never()`, so:
+
+  - `z.input` types it as `never` — writing it is a `tsc` error at the authoring site;
+  - the parse **rejects** it (verified against `17.0.0-rc.0`), at both `FieldSchema`
+    and `ObjectSchema`, with the prescription as the message:
+
+    > `conditionalRequired` was removed in @objectstack/spec 17 (#3855) — use
+    > `requiredWhen`. Rename the key; the value (a CEL predicate) is unchanged.
+    > Run `os migrate meta --from 16` to rewrite it automatically.
+
+  So spec-parsed metadata cannot carry the key — an object declaring it fails to
+  load rather than loading with the rule silently dropped. Keeping a renderer-side
+  `requiredWhen ?? conditionalRequired` would have re-created exactly the second
+  de-facto contract the tombstone exists to prevent: the key would have kept
+  working in the UI while being rejected everywhere else, hiding the producer's bug
+  (AGENTS.md #0.1). "Backend-agnostic" (#1) does not argue for keeping it either —
+  `conditionalRequired` is an ObjectStack-spec-ism, so the only producers that ever
+  emit it are ObjectStack producers on ≤16, and the spec ships them a converter.
+
+  Removed from:
+
+  | package                  | site                                                                                                      |
+  | :----------------------- | :-------------------------------------------------------------------------------------------------------- |
+  | `@object-ui/types`       | the `conditionalRequired?:` member on `FormField`                                                         |
+  | `@object-ui/core`        | the `??` fallback + rules-param member in `resolveFieldRuleState`                                         |
+  | `@object-ui/components`  | three pass-throughs in the form renderer                                                                  |
+  | `@object-ui/plugin-form` | `ObjectForm`, `ModalForm`, `sectionFields`, `deriveMasterDetail` (×2)                                     |
+  | `@object-ui/app-shell`   | the field inspector's legacy read/auto-migrate, and the key's entry in `clientValidation`'s CEL lint list |
+
+  **Studio authors lose nothing.** The object designer's draft validation parses
+  against the spec's own `ObjectSchema`, so a draft carrying the key now surfaces
+  the tombstone's rename prescription under the same `fields.<name>.conditionalRequired`
+  path the CEL lint used to report — a better message than the inspector's silent
+  auto-migration, and one the server agrees with. That behavior is pinned by a test.
+
+  **Migrating:** rename the key to `requiredWhen` (the CEL value is unchanged), or
+  run `os migrate meta --from 16`.
+
+- 03bd53b: feat(form): `SplitForm` honours the spec's new `FormSection.pane`
+
+  A split form's panel assignment was a hardcoded positional rule — first section
+  left, everything else right. The rule was invisible in the metadata, so
+  reordering sections silently moved them across the divider, and an author could
+  not place two sections in the left pane at all.
+
+  Sections now declare their panel: `pane: 'primary' | 'secondary'`
+  (@objectstack/spec `FormSection.pane`, objectstack#4160). Placement follows the
+  key, not the array position — reordering paned sections never changes the
+  layout. Omitted keys keep the exact legacy rule (first section `primary`, rest
+  `secondary`), so existing metadata renders unchanged.
+
+  `ObjectForm`'s split dispatch copies the key through its per-key section mapping
+  (the path that once silently dropped `visibleOn`), and `ObjectFormSection`
+  declares it. The spec side rejects `pane` on non-split form types at parse, so
+  the key can never be an accepted-but-ignored no-op.
+
+### Patch Changes
+
+- 7639a61: fix(form): the spec↔runtime form-field chokepoint stops dropping spec 17 vocabulary, and the validator stops contradicting the renderer — #3090
+
+  `normalizeSectionField` — the one translation point between the spec's authored
+  form-field shape (`field` = object-field reference) and the runtime shape
+  (`name` = data path) — silently dropped four spec keys, worst of all the
+  ADR-0089 **canonical** `visibleWhen` spelling while the deprecated `visibleOn`
+  worked. Now:
+
+  - view-level `visibleWhen` routes into the view-level slot (`visibleOn`) so it
+    ANDs with the object-level rule instead of clobbering it, and the wizard's
+    final-submit gate folds the same slot into its verdict (before, a required
+    field the view itself hides could block submission from off-screen);
+  - `dependsOn`, `keyField`, and `disclosure` carry through;
+  - a behavioral parity gate walks the spec `FormFieldSchema` key set — a key the
+    spec adds fails as unmapped, a key it retires fails as stale.
+
+  `SelectOptionSchema` is now derived from `@objectstack/spec/data` by reference
+  (it used to strip `color` — which `@object-ui/fields` renders — plus `default`
+  and the per-option `visibleWhen` gate), with pinned divergences (`value`
+  widened for UI forms, `visibleWhen` on the #2212 wire contract) and documented
+  UI-only extensions (`disabled`, `icon`). `SelectOption` (TS) gains `color` and
+  `default`.
+
+  `FormFieldSchema` (the runtime vocabulary `objectui validate` enforces) now
+  covers every key the `FormField` interface declares — `widget`, `dependsOn`,
+  `hidden`, `readonly`, `visibleOn`/`visibleWhen`/`readonlyWhen`/`requiredWhen`,
+  `span` — and `type` is optional, matching the interface. A typo'd predicate now
+  fails loudly instead of being stripped; spec-shape fields (`{ field: … }`) are
+  still rejected, pinning the two-layer boundary.
+
+- 94e63ef: fix(form): the runtime `field` metadata slot is declared instead of smuggled, and importing the spec's FormField is a lint error — #3090
+
+  `FormField.field` — the slot where object-bound form paths stash the resolved
+  field-metadata **object** for widgets — rode through the index signature,
+  undeclared, readable only via `as any`. Same key, different layer: in the spec
+  form-view vocabulary `field` is a _string_ (the referenced object-field name),
+  and the undeclared slot kept that pun latent. The slot is now declared
+  (`field?: Record<string, any>`) with the invariant in its JSDoc: on a runtime
+  FormField it is never a string — the authored string form ends at the
+  `normalizeSectionField` chokepoint, and a tripwire test pins that across all
+  three input shapes. Assigning a string is now a compile error; the `as any`
+  casts at the read sites are gone.
+
+  A `no-restricted-imports` tripwire bans importing `FormField`/
+  `FormFieldSchema` from `@objectstack/spec/ui` inside this repo: the spec's
+  FormField TYPE erases to `any` in its dist (objectstack#4171), so the
+  misimport silently deletes type safety — tsc says nothing. The lint message
+  names the two layers and the correct import. The drift-guard parity test is
+  the one legitimate importer, exempted inline with its reason.
+
+  Ledger: `FormField` and `FormFieldSchema` move from untriaged DEBT to ALLOW
+  with the two-layer rationale written down (122 → 120).
+
+- aeb0bd2: fix(form): a tabbed/split form honours the form view's own `columns`
+
+  `FormView.columns` is a spec key, but only `ObjectForm`'s simple path and
+  `ModalForm` read it. `TabbedForm` and `SplitForm` derived the grid width from the
+  per-section `columns` alone, so a view declaring `columns: 3` rendered 3 columns
+  in a modal and **single-column** as a tab or split — the same metadata laying out
+  differently depending on which host picked it up.
+
+  Both now resolve the grid the way the other hosts already did:
+
+      explicit form `columns`  ??  widest section's `columns`  ??  1
+
+  The two keys answer different questions and the precedence reflects that: the
+  view's `columns` is how wide the grid is, a section's `columns` is how densely
+  that section fills it (via per-field `colSpan`). `columns` is declared on
+  `TabbedFormSchema` / `SplitFormSchema` accordingly — `ObjectForm` already spread
+  it through, it was simply being dropped on arrival.
+
+- c735bf7: fix(form): a spec-vocabulary field no longer crashes the standalone form, and every surface now says which vocabulary you meant — #3090
+
+  Writing the regression test against the unfixed renderer proved the failure
+  was worse than the assumed silent drop: a `{ field: 'x' }` entry (spec
+  form-VIEW vocabulary) slipped past the `f?.name` guards into a
+  react-hook-form Controller with `name === undefined` and crashed the whole
+  standalone form on `name.split('.')`, with nothing naming the culprit entry.
+  The renderer now partitions such entries out — the rest of the form renders —
+  and surfaces them with an inline alert plus a console.error whose text is the
+  fix instruction (rename to `name`, or use an object-bound form whose sections
+  accept the spec shape).
+
+  `objectui validate` grows the same boundary awareness: on failure, a
+  `{ field: … }` entry in a standalone form gets a "likely cause" hint naming
+  the real fix instead of the bare `invalid_union` — the previous message read
+  as "bolt a `name` on", which converts spec metadata wrongly. On success,
+  mixed-vocabulary entries (`name` + string `field`) get a warning: they
+  validate, but the spec key is dead weight the renderer ignores.
+
+  `normalizeSectionField` warns (once per site) when an authored section field
+  mixes both identity keys — the spec branch derives the runtime name from
+  `field`, so an authored `name` was silently overwritten.
+
+- e339d60: fix(plugin-form): swapping `recordId` no longer leaves the previous record on screen
+
+  `loading` in `ModalForm` / `DrawerForm` / `TabbedForm` / `SplitForm` was only ever
+  set `true` once, by `useState(true)`, and thereafter only ever set `false`. A
+  `recordId` change therefore re-entered the fetch effect **without** going back
+  through the loading branch: the form stayed mounted showing — and accepting edits
+  to — record A's values, with nothing indicating a different record had been asked
+  for, until B's response landed and replaced them in place. Anything typed in that
+  window read as A's on screen and would have been submitted against B.
+
+  The same effect had no staleness guard either, so two overlapping reads landed in
+  **completion** order rather than request order: ask for B then C, and a slow B
+  arriving last left the form showing B while the caller had asked for C.
+
+  Both are the same defect from the user's side — the form displays a record nobody
+  asked for — so both are fixed:
+
+  - a change of record re-enters the loading state before the read, so the previous
+    record is off screen while the next one is in flight. Gated on the record
+    actually changing: the effect also re-runs on `initialData`/`initialValues`
+    identity churn (callers rebuild those objects every render), and flashing the
+    loading state for that would thrash;
+  - the effect's cleanup marks its read stale, so a response that is no longer the
+    one being awaited is dropped instead of overwriting a newer record.
+
+  `ObjectForm` already re-entered loading before its fetch, which is why this only
+  ever reproduced on the four sectioned variants.
+
+  **Also fixed, a consequence of the above:** hiding the form unmounts the inner
+  renderer, and that renderer is the only thing that reports dirtiness via
+  `onDirtyChange` — it gets no chance to report `false` on the way out. Without
+  clearing the flag, the overlay's unsaved-input guards would stay armed for input
+  belonging to a record no longer on screen: a plain refresh would prompt, and
+  closing would offer to discard nothing.
+
+- aa35561: fix(form): a split create/edit form no longer loses the panel you are not submitting from (#2153)
+
+  `SplitForm` rendered one `SchemaRenderer` — one react-hook-form instance and one
+  `<form>` element — **per section**, and its two groups of sections live in
+  separate resizable panels. So each panel owned isolated form state: submitting
+  from one panel's action bar sent only that section's fields and silently dropped
+  everything the user had typed on the other side of the divider. Filling both
+  panels and clicking Create persisted `{ subject }` alone.
+
+  The same isolation killed cross-panel field rules: a `visibleWhen` in the right
+  panel referencing a left-panel field never saw that field in its record, so the
+  predicate faulted and failed **open** — the field the author meant to hide was
+  always shown.
+
+  Both panels are now ONE form. The panel group became a layout the form renderer
+  owns, via a new `FormSchema.fieldPanes` (+ `fieldPanesOrientation`,
+  `fieldPanesResizable`) that mirrors `fieldTabs` (#2959): the `<form>` wraps the
+  whole `ResizablePanelGroup` and each pane holds only fields, which is what lets a
+  single react-hook-form instance span the divider. Sections inside a pane render
+  behind the inline `section-divider` header, each at its own declared column
+  density within the form's shared grid.
+
+  One more fix falls out of moving the panels into the renderer: `splitResizable:
+false` now actually pins the divider. It previously only hid the grip — the
+  separator stayed draggable, because nothing passed the panel library's
+  `disabled`.
+
+  Each pane is its own `@container`, so a multi-column section collapses to fewer
+  columns as its panel is dragged narrower instead of overflowing.
+
+- 3c1f321: fix(form): a tabbed/sectioned create-edit form no longer loses the tabs you are not looking at (#2959, #2153)
+
+  The explicit-`sections` path rendered one `SchemaRenderer` — one react-hook-form
+  instance and one `<form>` element — **per section**, all sharing the same
+  `formId`. Two failures compounded:
+
+  1. the footer submit button (`form={formId}`) can only be associated with the
+     **first** of those forms, so section 2+ never reached the payload; and
+  2. in the `tabbed` variant Radix unmounted the inactive panel, destroying that
+     tab's form state outright.
+
+  Reported flow (HotCRM, 3 tabs, required `description` on tab 3): fill tab 1 →
+  submit → server 400 `description is required` → switch to tab 3, fill it →
+  submit → the server now reports `subject; description; status; priority` **all**
+  missing, because the second submit's body had lost every earlier value.
+
+  `ModalForm` (stacked and `contentLayout: 'tabbed'`) and `TabbedForm` now render
+  ONE form for all sections, matching `ObjectForm` / `DrawerForm`. Stacked sections
+  use the existing inline `section-divider` header (which now also renders the
+  section's `description`); tabbed sections go through a new
+  `FormSchema.fieldTabs` (+ `defaultFieldTab`, `fieldTabsPosition`) that the form
+  renderer distributes into **force-mounted** Radix panels — CSS-hidden rather
+  than unmounted, since react-hook-form skips validation for unmounted fields,
+  which is how a required field on a tab nobody opened used to sail past the
+  client and come back as a server 400.
+
+  Validation feedback now points at the tab: a rejected field activates its tab and
+  every tab holding one is marked on its trigger, for client-side rules and server
+  `fields[]` rejections alike.
+
+- c0d0bc8: fix(form): a wizard with `allowSkip` no longer submits past the required fields you skipped
+
+  `allowSkip` let the user jump to any step from the indicator, and
+  `handleStepClick` did so without validating anything on the way. Since a wizard
+  mounts ONE step at a time and react-hook-form only validates the fields currently
+  **mounted**, a required field on a step nobody opened was never registered, never
+  validated, and simply absent from the payload.
+
+  Measured against the unfixed component — 3 steps, required `owner` on step 2,
+  `allowSkip: true`, click step 3's indicator, fill it, hit Create:
+
+      createCalls: 1
+      payload:     { subject: 'S1', notes: 'S3' }   // `owner` missing entirely
+      UI mentions "required": false                 // nothing said so
+
+  So an invalid create went out and the client said nothing about why — #2959's
+  validation half, wearing a wizard's clothes.
+
+  The final submit now checks the WHOLE declared field set, and when something is
+  outstanding it returns the user to the first step that has one, marks that step's
+  indicator (`data-error="true"`, destructive circle + icon), names the fields in a
+  toast, and sends nothing. Conditional rules are honoured: the check runs on the
+  canonical `resolveFieldRuleState`, the same engine the form renderer and the
+  server's rule-validator use, so a field hidden by `visibleWhen` or not yet
+  required by `requiredWhen` is not demanded. The sequential path is unaffected —
+  a forward jump is refused without `allowSkip`, so Next already validated each step.
+
+  Also in `WizardForm`:
+
+  - `FormView.columns` is now honoured (spec key, previously dropped): the grid
+    width is the view's `columns`, else the step's own. Unlike the tabbed/split
+    hosts there is no widest-section fallback — wizard steps never share a viewport,
+    so each keeps its authored width.
+  - the root gained `@container`. The step grid is sized with container queries, and
+    without a container ancestor every `@md:`/`@2xl:` variant was inert — a step
+    declaring 2 columns rendered single-column. Found by running it in a browser;
+    the class was present all along, which is why asserting the class alone had
+    missed it.
+
+- Updated dependencies [62311b6]
+- Updated dependencies [fc0272a]
+- Updated dependencies [9e7349e]
+- Updated dependencies [8864971]
+- Updated dependencies [1cf0de7]
+- Updated dependencies [752e18f]
+- Updated dependencies [c785740]
+- Updated dependencies [b41f401]
+- Updated dependencies [19e9fa0]
+- Updated dependencies [d61efd1]
+- Updated dependencies [95b7214]
+- Updated dependencies [7d9734d]
+- Updated dependencies [6ae818e]
+- Updated dependencies [9eb932b]
+- Updated dependencies [746dd00]
+- Updated dependencies [aebfa4f]
+- Updated dependencies [38ca8be]
+- Updated dependencies [3cb9646]
+- Updated dependencies [68ef584]
+- Updated dependencies [4952edf]
+- Updated dependencies [7f0252e]
+- Updated dependencies [c4d7b20]
+- Updated dependencies [c769d3d]
+- Updated dependencies [7639a61]
+- Updated dependencies [94e63ef]
+- Updated dependencies [c735bf7]
+- Updated dependencies [02aef0c]
+- Updated dependencies [6f29aa5]
+- Updated dependencies [d21794c]
+- Updated dependencies [c4db402]
+- Updated dependencies [5319bf1]
+- Updated dependencies [49e5671]
+- Updated dependencies [2307b52]
+- Updated dependencies [9a04d25]
+- Updated dependencies [b5b97e2]
+- Updated dependencies [f59f2c1]
+- Updated dependencies [07de839]
+- Updated dependencies [2a40b5e]
+- Updated dependencies [df613fa]
+- Updated dependencies [4874117]
+- Updated dependencies [ad0183a]
+- Updated dependencies [ce08d55]
+- Updated dependencies [eb4b740]
+- Updated dependencies [aecc934]
+- Updated dependencies [5b084eb]
+- Updated dependencies [aa1240a]
+- Updated dependencies [2374a49]
+- Updated dependencies [390c071]
+- Updated dependencies [d10f526]
+- Updated dependencies [2d5d594]
+- Updated dependencies [ea7f477]
+- Updated dependencies [379728f]
+- Updated dependencies [7f23cd0]
+- Updated dependencies [0ded602]
+- Updated dependencies [24e0e0a]
+- Updated dependencies [f8a95e5]
+- Updated dependencies [3a6cf24]
+- Updated dependencies [aa35561]
+- Updated dependencies [03bd53b]
+- Updated dependencies [3c1f321]
+- Updated dependencies [a045a32]
+- Updated dependencies [912496d]
+- Updated dependencies [80edbd4]
+- Updated dependencies [9867281]
+  - @object-ui/core@17.1.0
+  - @object-ui/components@17.1.0
+  - @object-ui/react@17.1.0
+  - @object-ui/types@17.1.0
+  - @object-ui/i18n@17.1.0
+  - @object-ui/permissions@17.1.0
+  - @object-ui/fields@17.1.0
+
+## 17.0.0
+
+### Minor Changes
+
+- f9bbddb: feat: gate detail/form edit & delete on the server's effective operation set (#3546)
+
+  PR-4 (#3391) wired the **list/toolbar** surface (ObjectView Import, ListView /
+  ObjectGrid Export) to the server-resolved effective API operation set
+  (`/me/permissions` `apiOperations`, intersected via
+  `resolveCrudAffordances(obj, effectiveApiOperations?)`). The **detail / form**
+  surfaces still gated edit/delete on the bucket + `userActions` alone. This
+  extends the same intersection to them, so the record page and its forms never
+  offer an operation the server would 405.
+
+  - **core** `isObjectInlineEditable(obj, effectiveApiOperations?)` gains the same
+    optional second argument as `resolveCrudAffordances` — inline-edit is now
+    additionally ANDed with the server allowing `update`.
+  - **app-shell** `RecordDetailView` threads the object's effective operations into
+    the synthesized Edit/Delete header actions and the record-body inline-edit
+    gate (`canEdit`); `RelatedRecordActionsBridge` intersects each **child**
+    object's Create/Edit/Delete handlers with that child's own effective set.
+  - **plugin-detail** `record:details` ANDs its inline-edit affordance with the
+    object's effective `update`.
+  - **plugin-form** `ObjectForm`'s blanket managed-object field lock also engages
+    when the server denies `update` (edit mode) / `create` (create mode).
+
+  Backward-compatible: a missing effective set (unrestricted object, older
+  backend, or no `PermissionProvider`) leaves the resolved affordance untouched —
+  the bucket/`userActions` decision wins, exactly as today. Layers on top of the
+  existing per-object `check('edit')` / `check('delete')` permission gates
+  (intersection, never union).
+
+### Patch Changes
+
+- 6dee2cb: feat(form): consume spec-aligned FormView buttons/defaults in ObjectForm
+
+  The authored `@objectstack/spec` FormViewSchema carries structured
+  `buttons.{submit,cancel,reset}.{show,label}` and `defaults`, but the form
+  renderer only read the flat renderer-invented `showSubmit`/`submitText`/
+  `showCancel`/`cancelText`/`showReset`/`initialValues`. That left the two spec
+  keys parsed-but-inert (ADR-0078) and stuck at `experimental` in the spec
+  liveness ledger.
+
+  `ObjectForm` now folds the structured shape down onto those flat props inside
+  its existing normalization pass, so every entry path (ObjectView
+  drawer/modal/page, RecordFormPage) honors it. An explicitly-set flat key still
+  wins, so metadata authored against the deprecated flat keys is unchanged.
+  `ObjectView` and `RecordFormPage` forward `buttons`/`defaults` from the spec
+  form view. `ObjectFormSchema` gains the optional `buttons`/`defaults` fields.
+
+  Refs objectstack-ai/objectstack#1894, objectstack-ai/objectstack#2998.
+
+- 2f947e4: fix(page,field): consume the spec's `type`/`label`/`maxLength` keys (framework#1878 §3 naming-drift recheck)
+
+  Three forward-drifts where objectui read a different key than the spec
+  declares, so authoring the documented key silently no-oped:
+
+  - **page `type` → `pageType`** (app-shell + components): `PageSchema` declares
+    the page KIND as `type`, but `PageRenderer` reads `schema.pageType` and fell
+    back to `'record'` — and nothing mapped between them. Every non-record page
+    (`home`/`app`/`list`/`utility`) rendered with the record max-width, a wrong
+    `data-page-type` attribute, and a suppressed header. `PageView` now passes
+    `pageType` alongside the SchemaNode discriminator `type`.
+  - **page `label` → `title`** (components): `PageSchema.label` is required but the
+    region renderer read only `title`. Now dual-reads `title ?? label`, mirroring
+    the fallback `DashboardRenderer` already uses. Coupled with the above — the
+    header is gated on `pageType !== 'record'`, so both were needed for a title to
+    appear.
+  - **field `maxLength`/`minLength`** (plugin-form + fields): validation already
+    dual-read these, but `ObjectForm`'s HTML-attribute pass and `TextAreaField`
+    read `max_length` only, so a spec-authored `maxLength` gave no browser cap and
+    no character counter. Both now dual-read, matching `buildValidationRules`.
+
+  Verified in the browser against the showcase: `capability_map` (`type: 'home'`)
+  now renders `data-page-type="home"`, the `home` max-width and its page title;
+  record pages are unchanged.
+
+- 662bdf9: fix(fls): wire the real per-caller FLS channel into import targets and grid
+  columns; remove the never-populated `field.permissions` shape (objectstack#3661)
+
+  The `permissions?: { read?, write?, edit? }` key on `@object-ui/types` field
+  definitions (Phase 3.2.6) was declared-but-never-enforced: no producer in the
+  stack ever populated it, so every guard reading it short-circuited to "allow".
+  Per ADR-0049 enforce-or-remove, the shape is deleted and the three consumers
+  now use the server-resolved `/auth/me/permissions` channel
+  (`usePermissions().checkField`) — the same channel ObjectForm/ModalForm/ListView
+  already enforce:
+
+  - **ImportWizard target fields (app-shell `ObjectView`)**: the importable
+    field set (and thus the downloadable CSV template's columns) now drops
+    fields the caller cannot edit, instead of offering columns the server's
+    FLS write gate would 403.
+  - **ObjectGrid auto-derived columns**: columns the caller cannot read are
+    dropped (same gate ListView applies), instead of a dead schema-shape check.
+  - **ObjectForm**: the redundant dead guard in field generation is removed;
+    the existing `applyFieldPerms` gate remains the real enforcement point.
+
+  BREAKING CHANGE: `@object-ui/types` field definitions no longer accept a
+  `permissions` key. It never carried data at runtime; consumers needing
+  per-caller field-level permissions must use `@object-ui/permissions`
+  (`MePermissionsProvider` + `useFieldPermissions`/`checkField`).
+
+- dc7a798: fix(plugin-grid,plugin-form,plugin-designer,cli,vscode-extension): type-check the last five unchecked packages, and fix the two runtime bugs that hid there (#2919)
+
+  Closes the remaining `DEBT` entries from the #2911 sweep. Each package gains
+  `"type-check": "tsc --noEmit"` and loses its entry in
+  `scripts/check-type-check-coverage.mjs`; coverage goes 36 -> 41 of 45 and
+  outstanding errors 25 -> 5 (only #2916 `plugin-view` and #2918 `layout` remain).
+
+  **Two of these were real bugs, not just type noise.**
+
+  `@object-ui/cli` — `objectui validate` could never report a validation failure.
+  `ZodError.errors` was removed in Zod 4 (the repo is on 4.4.3), so `.errors` read
+  `undefined` and `.forEach` threw a `TypeError` that the enclosing `catch`
+  reported as `✗ Error reading or parsing schema file: Cannot read properties of
+undefined` — swallowing the very errors the command exists to print. Now reads
+  `.issues`. Verified against the built CLI: an invalid schema now prints
+  `1. Invalid input / Code: invalid_union` and exits 1.
+
+  `@object-ui/plugin-grid` — grouping a grid by a boolean column showed the raw
+  i18n key. `t('grid.booleanTrue', 'Yes')` asked for a key present in neither
+  `GRID_DEFAULT_TRANSLATIONS` nor any locale bundle, and passed the English
+  fallback as a bare second argument — which `createSafeTranslation`'s no-provider
+  translator reads as an _options object_, so the fallback never applied and the
+  header rendered the literal `grid.booleanTrue`. Switched to the `grid.yes` /
+  `grid.no` keys the boolean cell renderer (`ObjectGrid.tsx`) and
+  `BulkActionDialog` already use, with the fallback passed as `defaultValue`.
+  Covered by a new regression test, confirmed to fail against the old code.
+
+  The rest are type-only corrections that preserve runtime behaviour exactly:
+
+  - **plugin-grid** `importParsers.ts` — `scorePair`'s `score`/`reason` moved into
+    one `best` record. They were captured `let`s mutated only inside the `bump`
+    closure, which TypeScript's control-flow analysis does not track, so it still
+    believed `reason` was `'none'` at the type gate and flagged the comparisons as
+    non-overlapping (TS2367). The gate — which stops a text column being mapped
+    onto a number field — is unchanged; its two dedicated tests still pass.
+  - **plugin-form** — `SectionFieldsContext.fieldLabel` now requires `fallback`,
+    matching the `useSafeFieldLabel` producer in `@object-ui/i18n` (an omitted
+    fallback could not satisfy the `=> string` return, and all four call sites
+    already pass one). This one signature cleared six errors.
+    `MasterDetailFormSchema.recordId` widens to `string | number`, matching
+    `ObjectFormSchema` and the five envelopes that forward straight into it;
+    it is narrowed with `String()` only at the batch-transaction boundary, whose
+    `BatchTransactionOperation.id` is a string by protocol (the `isEdit` guard
+    already proves it non-null there). `deriveMasterDetail`'s column sort gets an
+    explicit `fillPriority` helper — `GridColumn.type` is optional, and a column
+    without one keeps sorting at priority 5 exactly as the old
+    `TYPE_FILL_PRIORITY[undefined] ?? 5` lookup put it.
+  - **plugin-designer** — unused `index` parameter prefixed `_`, matching the
+    `_entry` beside it.
+  - **cli** — a stale `@ts-expect-error` removed; `viteConfig` is typed `any`, so
+    the line it guarded had stopped erroring.
+  - **vscode-extension** (`object-ui`) — migrated off `moduleResolution: "node"`,
+    which is deprecated and stops working in TypeScript 7, to `node16` paired with
+    `module: "node16"` (the package has no `"type": "module"`, so node16 resolves
+    it as the CommonJS that tsup emits, and it gains the `exports`-map awareness
+    node10 lacks). Its error count was under-reported as 1: that TS5107 config
+    error masked four more. The package uses `console`/`Buffer` but sets
+    `lib: ["ES2020"]` with no DOM and never declared `@types/node` — added, with an
+    explicit `types: ["node", "vscode"]`.
+
+  Also: `plugin-grid`, `plugin-form` and `plugin-designer` gain the `baseUrl` +
+  `paths` override their type-checked plugin peers already carry, and `cli` an
+  empty `paths`. Without it the inherited root `paths` point `@object-ui/*` at
+  sibling `src/`, which is outside each project's `rootDir` and produces the ~104
+  spurious TS6059 errors noted in #2915; workspace deps instead resolve through
+  node_modules to built `.d.ts`, which `type-check`'s `dependsOn: ["^build"]`
+  guarantees exist.
+
+  Verified the gate genuinely covers all five rather than trusting the green:
+  injecting a type error into each package makes `pnpm type-check --filter <pkg>`
+  fail, which was impossible before this change.
+
+- Updated dependencies [7b21891]
+- Updated dependencies [0b3be01]
+- Updated dependencies [3c4d935]
+- Updated dependencies [4b1ed7d]
+- Updated dependencies [4b60d2d]
+- Updated dependencies [952b978]
+- Updated dependencies [de5e40c]
+- Updated dependencies [1a03af6]
+- Updated dependencies [3e886eb]
+- Updated dependencies [cfc675e]
+- Updated dependencies [20df08c]
+- Updated dependencies [1767124]
+- Updated dependencies [8ecf5a6]
+- Updated dependencies [af705b9]
+- Updated dependencies [0502a7c]
+- Updated dependencies [7b35e4b]
+- Updated dependencies [8fb1295]
+- Updated dependencies [e16ed2d]
+- Updated dependencies [c6fd752]
+- Updated dependencies [f9bbddb]
+- Updated dependencies [dfd3705]
+- Updated dependencies [c77108c]
+- Updated dependencies [2735de6]
+- Updated dependencies [697cda4]
+- Updated dependencies [c19ac11]
+- Updated dependencies [6dee2cb]
+- Updated dependencies [e05f052]
+- Updated dependencies [0502a7c]
+- Updated dependencies [faad45e]
+- Updated dependencies [09c6a17]
+- Updated dependencies [c7cff19]
+- Updated dependencies [ba73a02]
+- Updated dependencies [cd09a7b]
+- Updated dependencies [f1abf0e]
+- Updated dependencies [f05b84e]
+- Updated dependencies [9b4b952]
+- Updated dependencies [341bfb5]
+- Updated dependencies [2f947e4]
+- Updated dependencies [7d46648]
+- Updated dependencies [9b53d72]
+- Updated dependencies [bb4aa25]
+- Updated dependencies [75f1cdf]
+- Updated dependencies [662bdf9]
+- Updated dependencies [059a052]
+- Updated dependencies [53642d4]
+- Updated dependencies [8aae006]
+- Updated dependencies [c6cfdf1]
+- Updated dependencies [d147a13]
+- Updated dependencies [c6aaed8]
+- Updated dependencies [263f885]
+- Updated dependencies [dc334da]
+  - @object-ui/components@17.0.0
+  - @object-ui/i18n@17.0.0
+  - @object-ui/fields@17.0.0
+  - @object-ui/react@17.0.0
+  - @object-ui/types@17.0.0
+  - @object-ui/core@17.0.0
+  - @object-ui/permissions@17.0.0
+
+## 16.1.0
+
+### Minor Changes
+
+- 62b9ab5: feat(data): unify master-detail saves behind `DataSource.batchTransaction`, isolate the non-atomic fallback in the adapter (#2679)
+
+  Master-detail saves (`MasterDetailForm`, `LineItemsPanel`) now always persist
+  through `dataSource.batchTransaction(operations)` — one ordered cross-object
+  operation list, with `{ $ref: <op index> }` linking a child to a parent created
+  in the same batch. The form no longer contains any client-side orchestration or
+  best-effort compensation-delete; that atomicity anti-pattern is gone from the UI
+  layer (framework #1604 / framework ADR-0034 item 4).
+
+  - **`@object-ui/types`** — `batchTransaction?` is now a first-class (optional)
+    method on the `DataSource` contract, typed via `BatchTransactionOperation` /
+    `BatchRef`. Replaces the previous `(dataSource as any).batchTransaction`
+    method-sniffing.
+  - **`@object-ui/core`** — new `emulateBatchTransaction(dataSource, operations)`
+    (sequential writes, `$ref` resolution, best-effort reverse-order compensation)
+    and `runBatchTransaction(dataSource, operations)` (prefers the adapter's method,
+    emulates otherwise). `ApiDataSource` / `ValueDataSource` implement
+    `batchTransaction` via the emulation.
+  - **`@object-ui/data-objectstack`** — `ObjectStackAdapter.batchTransaction` uses
+    the server's atomic `POST /api/v1/batch`, prefers the typed
+    `client.data.batchTransaction` SDK method when the installed client exposes it,
+    and degrades to the client-side emulation ONLY when the endpoint is missing
+    (404/405) or the runtime can't do transactions (501). Real errors (400/401/403/
+    409/500) still surface. This is the isolated, tested home of the non-atomic
+    fallback.
+  - **`@object-ui/plugin-form`** — removed `applyDetail` / `createMany` /
+    `ApplyDetailResult` from `masterDetailTx.ts`; `MasterDetailForm` and
+    `LineItemsPanel` build ops and call `runBatchTransaction`. `LineItemsPanel`
+    saves are now atomic on a capable backend, with the rollup folded into the same
+    batch.
+
+  No behavior change on a current ObjectStack backend (it has `/api/v1/batch`);
+  older/limited backends keep a working — now clearly non-atomic — save path.
+
+### Patch Changes
+
+- 7cf4051: chore(deps): align every `@objectstack/*` dependency to `^16.0.0-rc.0`
+
+  Bumps `@objectstack/spec` / `client` / `formula` / `lint` from `^15.1.1` to the
+  `16.0.0-rc.0` pre-release across the workspace (root + `apps/console` +
+  `apps/site` + all consuming packages). ObjectUI's own packages are already on
+  major 16, so this closes the 15↔16 skew between ObjectUI and the `@objectstack`
+  contract libraries (which publish in lockstep with `spec`).
+
+  This is a dependency alignment, not a behavioral migration: the full workspace
+  build (43/43) and the `@objectstack`-consuming package test suites
+  (`core` / `app-shell` / `data-objectstack` / `plugin-form` / `types`) are green
+  against `16.0.0-rc.0` with no source changes required.
+
+  Practical effect: `@objectstack/client@16.0.0-rc.0` now ships
+  `data.batchTransaction` (framework #3271), so `ObjectStackAdapter`'s feature
+  detect (`typeof client.data.batchTransaction === 'function'`) routes
+  master-detail cross-object saves through the typed SDK method instead of the
+  raw `fetch('/api/v1/batch')` fallback — realizing the "verify SDK path" half of
+  #2694. The raw-fetch branch stays as a defensive fallback (removal tracked in
+  #2694).
+
+- 0a3710b: **Finish the `managedBy` / `userActions` de-dup — one parser for the override shape (completes objectui#2712, framework#3343).** #2712 consolidated the bucket _union_ + affordance _set_ mirrors but left four surfaces still parsing the `userActions.{create,edit,delete}` override shape by hand. They now all route through the shared `@object-ui/core` policy, so no package re-implements the boolean / #2614-object-form parse locally.
+
+  - **`@object-ui/core`** promotes the internal `normalizeOverride` to the exported **`normalizeUserAction(v, base)`** (the one parser) and adds **`userActionPredicates(v)`** for per-record CEL predicate extraction.
+  - **`app-shell/utils/managedByEmptyState.ts`** — the writable-`system` create check and its local `EmptyStateUserActions` interface are replaced by `resolveCrudAffordances({ managedBy, userActions }).create`.
+  - **`plugin-grid/rowCrudAffordances.ts`** — the local `isOptedOut` / `predicatesOf` helpers (and duplicated `RowCrudUserAction` / `RowCrudPredicates` types) fold into `normalizeUserAction`; the historical type names stay re-exported for compat.
+  - **`plugin-detail/RelatedList.tsx`** — its inline `predicatesOf` fold into `userActionPredicates`.
+  - **`plugin-form/ObjectForm.tsx`** — the hand-rolled `managedBy !== 'platform'` blanket lock + `userActions` unlock is replaced by the resolved affordance for the current mode (`edit` / `create`), the **same** `resolveCrudAffordances` contract the detail (`isObjectInlineEditable`) and grid surfaces use.
+
+  Behavior-preserving for `platform` / `system` / `append-only` / `better-auth`, with one deliberate alignment: an admin-editable **`config`**-bucket object (e.g. `sys_webhook`, `sys_permission_set`) is now editable in `ObjectForm` — it was previously over-locked as "non-`platform`", while detail/grid already treated it as editable (`config` resolves `edit: true`). New unit coverage for the shared parser and the config / create-mode form gate; all existing affordance/edit-gate tests stay green.
+
+- Updated dependencies [0318118]
+- Updated dependencies [1c8935a]
+- Updated dependencies [af1b0db]
+- Updated dependencies [8b8b744]
+- Updated dependencies [7cf4051]
+- Updated dependencies [803558e]
+- Updated dependencies [aefcf39]
+- Updated dependencies [2e7d7f0]
+- Updated dependencies [ef14f69]
+- Updated dependencies [94d4876]
+- Updated dependencies [1100a8b]
+- Updated dependencies [7abe4cd]
+- Updated dependencies [69fa5d1]
+- Updated dependencies [549c67d]
+- Updated dependencies [ebe6494]
+- Updated dependencies [2b17339]
+- Updated dependencies [31b77d4]
+- Updated dependencies [6d4fbe6]
+- Updated dependencies [0a3710b]
+- Updated dependencies [f80aaf2]
+- Updated dependencies [62b9ab5]
+- Updated dependencies [14cb729]
+- Updated dependencies [1629313]
+- Updated dependencies [29c6040]
+- Updated dependencies [faebac3]
+- Updated dependencies [2331ac9]
+- Updated dependencies [199fa83]
+- Updated dependencies [eee4ded]
+- Updated dependencies [3b2e4d9]
+  - @object-ui/fields@16.1.0
+  - @object-ui/i18n@16.1.0
+  - @object-ui/core@16.1.0
+  - @object-ui/types@16.1.0
+  - @object-ui/react@16.1.0
+  - @object-ui/components@16.1.0
+  - @object-ui/permissions@16.1.0
+
 ## 16.0.0
 
 ### Minor Changes
@@ -793,7 +1504,7 @@ parentData, details)` — emits a parent `update` op (index 0) then diffs each
   `type:'tabbed'` form view now renders tabbed in the modal too — not just on the
   full-page route (#1762). Non-breaking; `FormView.type` enum unchanged.
 
-  Refs objectstack-ai/framework#1890, ADR-0050
+  Refs objectstack-ai/objectstack#1890, ADR-0050
 
 - 650bd1f: fix(forms/dashboard/related-list): four business-facing rendering fixes found while QA-ing a showcase workspace