Merge origin/main (0389650) into claude/issue-9547-ongrid-onnavigate-prop

Claude-Session: https://claude.ai/code/session_0122Knsowci76D2rBWReCzzZ
Co-authored-by: Claude <noreply@anthropic.com>

Author: claude

.changeset/11168-action-family-published-inputs.md

@@ -0,0 +1,37 @@
+---
+'@object-ui/components': minor
+---
+
+The four `action:*` blocks now publish the `@objectstack/spec` keys their
+renderers honour, and stop publishing what the spec refuses (objectui#11168,
+slice 1). Each key was decided by measuring it through `SchemaRenderer` and the
+action runner, per the objectui#11111 ruling: declare what the block path
+honours, refuse or retire what it does not.
+
+Newly published, so the SDUI manifest, the JSX intrinsics and the page
+validator accept them instead of reporting `unknown-prop`:
+
+- `action:button` and `action:icon`: `visible`, `disabled`, `params`,
+  `description`, `openIn`, `method`, `bodyExtra`, `bodyShape`, `operation`,
+  `patch`, `confirmText`, `successMessage`, `errorMessage`, `refreshAfter`,
+  `locations`, `toast`, `resultDialog`, `onSuccess` and `objectName`; and
+  `recordIdField` on `action:button`. `params` is published as the list of
+  parameters to collect; static execution values stay under
+  `properties.params`.
+- `action:group`: `location` and `visible`.
+- `action:menu`: `size` and `visible`.
+
+Retired and narrowed (breaking for an author who wrote them, which the spec
+already refuses):
+
+- `action:group` no longer publishes `name`. Nothing reads a group-level
+  `name`; each member action's own `name` identifies it.
+- `actions` on `action:group` and `action:menu` is published as a list of action
+  objects, not an `object`. Both blocks read the key as a list, so an object
+  there could not render.
+- `action:group.size` publishes `default`, `sm`, `lg` and `icon`, and no longer
+  `md`. A stored `md` still renders as before.
+
+Still unpublished, pending a decision on objectui#11168: `endpoint` on
+`action:button` and `action:icon`, and `undoable` on `action:button`. The
+renderers keep forwarding both, so nothing changes at runtime.

.changeset/11189-nav-autosave-flush-generation.md

@@ -0,0 +1,26 @@
+---
+'@object-ui/app-shell': patch
+---
+
+fix(app-shell): Studio's nav autosave sends every nav edit it has shown — "Done" sends the edit, and a completing save clears only what it sent
+
+Two ways Studio's Interfaces pillar could show a nav edit on a writable package
+and never save it:
+
+- **"Done" inside the autosave's debounce.** The nav autosave only runs while
+  nav editing is open, so clicking "Done" within 1.5 s of an edit cancelled the
+  pending save. The edit stayed on screen, unsaved, until nav editing was
+  opened again, and the unsaved-changes guard stayed held.
+- **An edit taken while a nav save was in flight.** The completing save marked
+  the navigation clean whatever had been edited meanwhile, and the re-read it
+  triggers installed the saved document over the editor. The later edit
+  disappeared from the screen, was never saved, and the unsaved-changes guard
+  let go of it without a warning.
+
+"Done" now saves an unsaved nav edit at once, waits for a save already in
+flight, and closes nav editing once everything shown has been saved. If that
+save fails, editing stays open with the error on screen. A completing save now
+marks the navigation clean only if nothing was edited after it was sent, so a
+later edit stays on screen, keeps the unsaved-changes guard, and goes out in the
+next save. A re-read of the same package (after a save, a publish, or a copilot
+change) no longer replaces navigation edits that have not been saved yet.

.changeset/11206-computed-strip-wording.md

@@ -0,0 +1,26 @@
+---
+'@object-ui/app-shell': patch
+'@object-ui/i18n': patch
+---
+
+fix(app-shell): the save warning has a sentence of its own for a formula field the server ignored
+
+objectstack `b2805465` gave the write path a fourth strip reason, `computed`: a
+value the caller sends for a `formula` field is stripped on every write path,
+because the server computes that field and has nowhere to store it. The save
+warning now words that reason as what it is — "Calculated by the server from a
+formula, so the value sent did not take effect: …" — through a new
+`detail.writeStrippedComputed` key in all ten locale packs, and never as a
+read-only lock, which would send the user after a permission problem that does
+not exist.
+
+The reason table stays exhaustive over the spec's union, and one spelling now
+compiles against both the published `@objectstack/spec` 17.5.0 (which does not
+name the arm) and objectstack `main` (which does), which is what the
+`Spec Main Shape Gate` needs to go green again.
+
+When the sentence reaches a user: the adapter judges a reported reason against
+the spec release this bundle is built with, and 17.5.0 does not declare
+`computed`, so until that release carries it a formula strip from a newer server
+is still reported as "Not applied by the server: …" — truthful, but without the
+cause. The new sentence is used from the spec release that declares the arm on.

.changeset/9853-grid-display-page-size-from-spec.md

@@ -0,0 +1,62 @@
+---
+'@object-ui/plugin-grid': minor
+'@object-ui/plugin-list': minor
+'@object-ui/plugin-kanban': minor
+---
+
+A page size with nothing declared is now the one `@objectstack/spec` declares for
+`pagination.pageSize`, on every surface that has a pager; a fetch that has no
+pager keeps its own fetch batch, which does not follow it (objectui#9853).
+
+"Page size" now means one page, and only where there is a pager. The grid,
+the list and the board read the display default from the spec (`PaginationConfigSchema`)
+instead of keeping numbers of their own, so it is declared once, in the protocol.
+`@objectstack/spec` 17.5.0 declares **50**. The views that fetch one window and
+page nothing keep a fetch batch of their own, with the value they had, so no
+view loses records it could reach before.
+
+⚠️ **Visible change where no page size is declared.** Measured on the renderer
+with `@objectstack/spec` 17.5.0. Declare `pagination: { pageSize: N }` (or, on a
+board, `limit`) to keep an old count:
+
+| surface (nothing declared) | before | after |
+|:--|--:|--:|
+| `object-grid` that fetches its own rows: rows per page, and the `$top` of each page fetch | 50 | 50 (unchanged) |
+| `object-grid` over inline `data`: rows per page | 10 | **50** |
+| grouped `object-grid`: groups per page | 10 | **50** |
+| grouped `object-grid` over a data source that groups on the server: rows per group page (`$top`) | 50 | 50 (unchanged) |
+| `list-view`, grid view (paged on the server): rows per page, and `$top` | 100 | **50** |
+| `list-view`, every view it does not page (kanban, calendar, gallery, timeline and the rest, and a grouped grid): the one fetch's `$top` | 100 | 100 (unchanged) |
+| `object-kanban` with no `limit`: the board's `$top` | 100 | 100 (unchanged) |
+
+What changed underneath:
+
+- **`@object-ui/plugin-grid`.** `ObjectGrid` falls back to the spec's display
+  default on every page it shows, with no local number behind it: if a future
+  spec stops declaring the default, the module throws at load instead of
+  inventing one. The old "server window" constant is renamed
+  `DEFAULT_FETCH_BATCH_SIZE` and keeps its value. Since grouping moved to the
+  server, it is read only when the grid groups a window of rows in the browser
+  because the server does not group it (a grouping key the principal may not
+  read), and never as a page size. The grouped view's rows-per-page selector
+  also lists the size in force when it is not one of its fixed steps.
+- **`@object-ui/plugin-list`.** `ListView` splits its undeclared fallback by
+  whether the view pages. The grid view, which it pages on the server, falls
+  back to the spec's display default. Every other view falls back to a fetch
+  batch of 100, the value it had. A declared `pagination.pageSize` sizes the
+  window on every view, as before. With no declared size, switching between the
+  grid view and an unpaged view now changes the window, so the list fetches
+  again: one request, whose `$top` is the fetch batch. That qualifies the
+  objectui#10512 note in this same release, which says a switch into a dataset
+  chart with no user filter set issues no new request: it still holds when a
+  page size is declared. A refused page size still warns, and the warning names
+  the fallback that view actually used.
+- **`@object-ui/plugin-kanban`.** The board's default `limit` is renamed from
+  `DEFAULT_KANBAN_LIMIT` to `DEFAULT_KANBAN_FETCH_BATCH_SIZE` and stays 100. Its
+  diagnostic for a refused `limit` now calls it the board's fetch batch.
+
+The display default follows the `@objectstack/spec` a host installs. A host
+that resolves an older spec gets that spec's default, on every surface alike.
+
+Released as `minor`, not `major`: this repository keeps its major aligned with
+`@objectstack/spec`, so the behaviour change is spelled out here instead.

apps/console/src/__tests__/public-block-binding-reach.test.tsx

@@ -117,6 +117,19 @@ const NO_DATA_REACH: Readonly<Record<string, string>> = {
   // titles the panel.
   'record:related_list':
     'needs the parent record id from RecordContext before it may fetch; declines to fetch without one (objectstack#4413 ledger)',
+  // objectui#11168 slice 1 published the spec key `objectName` on the two
+  // action leaves, and on these blocks the key is not a data binding at all:
+  // it names the object the ACTION acts on. The block draws a button and
+  // fetches nothing; the key takes effect when the action is dispatched, where
+  // the server-action route becomes `/api/v1/actions/{objectName}/{action}`
+  // instead of the page's object. That dispatch read is pinned in
+  // `packages/components/src/renderers/action/__tests__/action-button-icon-inputs-11168.test.tsx`;
+  // what this ledger asserts is the other half — that the block still asks the
+  // data layer for NOTHING under that name.
+  'action:button':
+    'objectName names the object the action is dispatched against (the server-action route), not a data binding; the block renders a button and fetches nothing (objectui#11168)',
+  'action:icon':
+    'objectName names the object the action is dispatched against (the server-action route), not a data binding; the block renders an icon button and fetches nothing (objectui#11168)',
 
   // `list-view` and `embeddable-form` were the other two entries here for
   // exactly one release of this file. Neither registration bridged the
@@ -178,6 +191,11 @@ const EXPECTED_CANDIDATES = [
   // an `objectName`, so it joins this derived population — additive, and the
   // probe below is what decides whether the binding actually reaches.
   'object-tree',
+  // objectui#11168 slice 1 published `objectName` on the two action leaves, so
+  // they join the population too; both are ledgered in NO_DATA_REACH, because
+  // on an action block the key is a dispatch target rather than a binding.
+  'action:button',
+  'action:icon',
 ];
 
 /**