@smartbit4all/ng-client 7.3.32 → 7.3.34

package/MIGRATION-7.0.md

@@ -1,2280 +1,2280 @@
-# @smartbit4all/ng-client 6.x → 7.0 migration guide
-
-> 7.0.0 targets **Angular 22.0.8 / TypeScript 6.0.3 / Material 22.0.6**, with PrimeNG fully
-> removed (Material/CDK only), every library component `OnPush`, and **no zone.js** — the
-> configuration 7.0 is tested in. Angular's `moment` date adapter is replaced by `date-fns`.
-> It is a major because a host has to act; nothing here is a silent behaviour change that
-> you could ignore.
-
-## Where to start
-
-1. **Run the codemod** — [Migrating a host: the codemod](#migrating-a-host-the-codemod). It
-   does the mechanical part (the module imports, the provider configuration, the dead legacy
-   calls) and prints `file:line` for everything that needs a decision.
-2. Read [Full standalone + `provideSmartNgClient()`](#full-standalone--providesmartngclient-phase-32--the-big-one).
-   That section rewrites your `app.module.ts`; everything else is small next to it.
-3. Read [Dates](#dates-moment--date-fns-and-the-timezone-contract-phase-38). It is the one
-   change that needs action **at install time**, and the one that breaks at *runtime* on the
-   first screen with a date field rather than at build time.
-4. Then the rest in order. The **PrimeNG removal** sections (1.1–1.10) are API changes; the
-   **hop sections** carry the framework defaults you inherit (OnPush, fetch vs XHR, `?.`).
-5. If you write your own widget, `WIDGETS.md` next to this file is the protocol.
-
-Measured across the 12 hosts in scope on 2026-07-28, so you know what to expect: 12–17
-`Smart*Module` imports per host, 1–20 string-keyed providers, `.cssClass =` on an action
-entry at 72 sites in 7 hosts, `this.uiActionModels =` in 5 hosts, `UseUiAction` in 6.
-
-**How big is this for *your* host?** Codemod dry-run counts for the five hosts in scope
-(2026-07-30). The first column the codemod applies for you; the second is the list it refuses to
-guess at, which is the real work:
-
-| host | mechanical | needs a decision |
-|---|---|---|
-| p014 *(done — the reference)* | 121 | ~100 |
-| p043 | 121 | 96 |
-| app-tournament | 86 | 34 |
-| app-finance-ai | 62 | 18 |
-| app-fitnessmirror | 61 | 14 |
-
-The spread is not about host size — all five are within 274–841 source files — but about which
-APIs they happened to use. p043 is p014's twin and repeats its whole decision list; the other
-three have **no `.cssClass =` sites at all**, and their lists are dominated by `smart-modules`,
-the 3-line `moment-adapter` swap, and `zone-js` (which is **optional** — dropping zone.js is not
-required). Take a small one first if you want the process shaken out cheaply.
-
-**One number that is now zero: the library install.** p014 was migrated against an unpublished
-build and paid for it in hand-copies, tarballs and `ERESOLVE`. 7.0.0 is on npm, so a host today
-writes `"@smartbit4all/ng-client": "^7.0.0"` and runs `npm i`. None of that thread applies to you.
-
-## Migrating a host: the codemod
-
-It lives in the `platform-angular2` repository — `tools/ng-client-7-codemod/` — and you run
-it with plain Node, from a checkout, against your own source directory. Nothing to install.
-
-```bash
-node tools/ng-client-7-codemod/migrate.mjs ../my-host/ui-angular/src --dry-run   # look first
-node tools/ng-client-7-codemod/migrate.mjs ../my-host/ui-angular/src            # then write
-```
-
-It **refuses to run on a dirty git tree** (its diff is how you review it, and `git checkout .`
-is how you undo it), it is **idempotent**, and it prints a verdict for every rule it knows —
-including `no sites found`, because a codemod that silently matched nothing looks exactly
-like one that had nothing to do.
-
-**What it rewrites:** the `Smart*Module` imports (into the standalone declarables of the
-mapping table below), the string-keyed providers and both `forRoot()` payloads (into one
-`provideSmartNgClient(config, ...features)` call), the redundant core services in the root
-providers array, `this.useQueryLists = true` / `handleDataChangeSubscriptions()`,
-`[parentSmartComponent]` and the dead `[parent]` inputs,
-`execute(x.uiAction, x)` → `execute(x)`, the `async` / `await` around
-`getActionDescriptor`, the `SmartdialogService` `super(…)` call and its constructor
-parameters, and PrimeNG module imports **no template in your repository renders**.
-
-**What it refuses to guess at**, printing `file:line` and the section here that explains it:
-`UseUiAction` → `UiActionExecutor`, `this.uiActionModels =`, `entry.cssClass =`, `addForm()`,
-the 4th argument of `addGrid()`, `getActionDescriptor(…).then(…)`, the moment adapter,
-component-level providers, every remaining `primeng/*` import, and `::ng-deep` selectors that
-reach into the form widget.
-
-**What it deliberately does not do:** convert *your* components to standalone. That is
-Angular's own schematic (`ng generate @angular/core:standalone`) and it is not required — an
-NgModule's `imports:` array takes standalone components, which is exactly what the codemod
-puts there. Do the library migration first, get the app running, then decide about standalone
-separately.
-
-Afterwards: run your formatter, swap the date packages ([Dates §1](#1-swap-the-peer-dependency)),
-build (expect one `NG8001` per template element whose component is not imported yet — that
-loop terminates), and **smoke the app**, because the DI changes are invisible to the compiler.
-
-## Breaking changes
-
-### Dialog stack: PrimeNG dynamicdialog → MatDialog (Phase 1.1)
-
-- `SmartdialogService` and `SmartViewContextDialogService` constructors no longer
-  take a PrimeNG `DialogService` parameter. If your host extends or instantiates
-  these services, drop the argument (MatDialog is injected internally).
-
-  Both arguments PrimeNG contributed are gone, so the base constructor lost two of
-  its four parameters:
-
-  ```ts
-  // 6.x
-  constructor(dialog: MatDialog, dialogService: DialogService, inject: Injector,
-              @Inject(COMPONENT_LIBRARY) compLib: ComponentLibrary) {
-    super(dialog, dialogService, inject, compLib);
-  }
-  // 7.0
-  constructor(dialog: MatDialog, inject: Injector) {
-    super(dialog, inject);
-  }
-  ```
-
-  **The codemod does this** (rule `smartdialog-super`), including the constructor
-  parameters and the now-unused `primeng/dynamicdialog` import — except where a
-  dropped parameter carries an accessibility modifier (`protected dialogService: …`),
-  which declares a class *property* the body may still read. Those are reported.
-- The `ComponentLibrary` switch no longer has a PrimeNG branch in the dialog
-  layer — all dialogs open via `MatDialog` regardless of `COMPONENT_LIBRARY`.
-
-### smart-form widgets: PrimeNG removed (Phase 1.2)
-
-- `ComparableDropdownDirective` and `ComparableMultiselectDirective` are removed
-  (they decorated the PrimeNG `p-dropdown` / `p-multiSelect` elements, which no
-  longer exist). Use `SmartformwidgetComponent.compareItems` semantics via
-  `mat-select [compareWith]`, which the widget template already wires up.
-- `SmartformwidgetComponent` constructor no longer takes the injected
-  `COMPONENT_LIBRARY` token; the widget renders Material-only.
-- `SmartformwidgetComponent` removed PrimeNG-only public members:
-  `errorMessages`, `getControlMessages()`, `onPrimeRichTextEditorContentChanged()`,
-  `safeDropDownBlur()`/`onDropDownShow()`/`onDropDownInput()`,
-  `safeCalendarBlur()`/`onCalendarShow()`/`onCalendarInput()`, `defaultDate`.
-- `SmartFormService.setValuesFromModel()` / `toFormGroup()` /
-  `createFormControls()` no longer take a `ComponentLibrary` parameter.
-- `SmartViewContextModule` no longer imports the PrimeNG form modules
-  (Dropdown, MultiSelect, Calendar, Chips, InputSwitch, Checkbox, InputNumber,
-  InputText, InputTextarea, InputMask, FloatLabel, Messages) and no longer
-  provides `Dropdown` / `MultiSelect`.
-
-### fileupload: PrimeNG removed (Phase 1.4)
-
-- `SmartFileUploaderComponent` (selector `smart-file-uploader4sc`) is removed
-  from the public API. It was a PrimeNG `p-fileUpload` wrapper declared in
-  `SmartNgClientModule` but referenced nowhere; the Material-style
-  `SmartfileuploaderComponent` (selector `smartfileuploader`) is the uploader.
-- The internal `PrimeFileUploaderComponent` (selector `prime-file-uploader`)
-  is removed; `smart-upload-widget` always renders `smartfileuploader`.
-- `UploadWidgetComponent` constructor no longer takes the injected
-  `COMPONENT_LIBRARY` token, and its PrimeNG-only members are gone
-  (`fileUploadPrime`, `uploadFiles()`).
-- `SmartNgClientModule` and `SmartViewContextModule` no longer import the
-  PrimeNG `FileUploadModule`; `SmartViewContextModule` also dropped the dead
-  `OverlayPanelModule` import (Phase 1.3).
-
-### editor: Quill 1.3 → 2, quill-emoji removed (Phase 1.5)
-
-- Peer dependencies changed: `quill` `^1.3.7` → `^2.0.3`, `ngx-quill`
-  `16.2.1 - 24.0.5` → `^25.3.3`. Hosts must bump both together (ngx-quill 25.x
-  is the Quill 2 line for Angular 17; later Angular hops will raise it further).
-- `quill-emoji` peer dependency is **removed** (dead, Quill 1-only, unmaintained).
-  If a host needs emoji support, pick a Quill 2-compatible module on its own.
-- `@types/quill` must be removed from host devDependencies — Quill 2 ships its
-  own TypeScript types, and the stale `@types/quill` 1.x conflicts with them.
-- The bundled `quill.snow.css` (imported by the smart-form widget) is now the
-  Quill 2.0.3 stylesheet; hosts that import `quill/dist/quill.snow.css`
-  themselves must serve the Quill 2 version.
-- `SmartViewContextModule` no longer imports the PrimeNG `EditorModule`
-  (`<p-editor>` died with Phase 1.2; RICH_TEXT renders via ngx-quill).
-
-### smart-diagram: p-chart replaced by direct chart.js (Phase 1.6)
-
-- `SmartDiagramComponent` renders its own `<canvas>` and instantiates chart.js
-  directly; the PrimeNG `<p-chart>` wrapper (and the `ChartModule` import in
-  `SmartDiagramModule`) is gone. Chart.js controllers are now registered by the
-  component itself (`Chart.register(...registerables)`), so no `chart.js/auto`
-  import is needed anywhere.
-- The public `chart` property (and `getChart()`) is now the chart.js `Chart`
-  instance instead of the PrimeNG `UIChart` component. `getBase64Image()` and
-  `refresh()` keep their signatures (delegating to `toBase64Image()` /
-  `update()`).
-- `SmartDiagramComponent` constructor no longer takes the injected
-  `COMPONENT_LIBRARY` token; the component has a single render path.
-- DOM/CSS hooks changed: the internal structure is
-  `div.chart-host > div.chart-container > canvas`; host styles targeting
-  `::ng-deep p-chart` no longer match. The aspect-ratio classes
-  (`default-aspect-ratio` / `pie-aspect-ratio`) are now applied on
-  `.chart-host` and size `.chart-container`.
-
-### smart-grid: PrimeNG branch removed (Phase 1.7)
-
-- `SmartGridComponent` renders Material-only. The `@if (compLib === PRIMENG)`
-  template branch (the inline `p-table` / `p-paginator` / `p-menu` /
-  `p-multiSelect` grid) is gone; the grid always renders through the PrimeNG-free
-  `smart-table` (the `#table` slot), `mat-tree`, `app-smart-grid-card`, and
-  `mat-paginator`.
-- `SmartGridComponent` constructor no longer takes the injected
-  `COMPONENT_LIBRARY` token, nor the `SmartDatePipe` / `SmartDateTimePipe` /
-  `SmartTimePipe` (they only fed the removed inline `p-table` cell renderer);
-  those pipes are dropped from the component `providers` too.
-- Removed PrimeNG-only public members: `columns`, `menuButtons`, `menu`,
-  `onOptionsClick()`, `previousmultiSortMeta`, `gridSort()`, `lazyLoad()`,
-  `headerChange()`, `onColOrder()`, `getOrderColumNames()`, `getColValue()`,
-  `onPrimeChangePage()`, `onRowSelect()`, `onRowUnselect()`, `onSelectAllRow()`,
-  `getImageResourceIcons()`, `getImageResourceStyle()`, `getRowColumnAction()`,
-  `showCellToolbar()`, `shouldShowOptionsButton()`, `calculateMenuActions()`,
-  `createCellToActionMap()`, `getRowMenuActionModelArray()`, `rowTrackByFn()`,
-  `cellToActionMap`, `columnMetaByName`, and the `_headerToolbar`
-  (`#headerToolbar`) view child. The `headerToolbar` getter now returns the
-  smart-table's header toolbar unconditionally (its only remaining consumer,
-  `SmartComponentApiClient`, is unaffected).
-- `SmartGridModule` no longer imports the PrimeNG `TableModule`, `ButtonModule`,
-  `MenuModule`, `PaginatorModule`, `MultiSelectModule`; `MatTooltipModule` is
-  added (the grid refresh button is now a Material `mat-icon-button` +
-  `matTooltip` instead of `pButton` + `pTooltip`).
-- Note: this is the PrimeNG-branch deletion only. The `smart-grid` internals
-  rewrite to `mat-table` + `MatPaginator` and the `smart-grid`/`smart-table`
-  merge remain a Phase 3 (post-Angular-22) change.
-
-### misc widgets: PrimeNG branches removed (Phase 1.8)
-
-The remaining components that still carried a dead PrimeNG branch alongside an
-already-active Material one are now Material-only. In every case the Material
-branch was the rendered path under `COMPONENT_LIBRARY = MATERIAL` (the value all
-7.0 hosts use), so this is render-neutral; the `COMPONENT_LIBRARY` token, where
-these components still injected it, is now ignored by them.
-
-- `ExpandableSectionComponent` renders Material-only (the `p-accordion` branch is
-  gone; always `mat-expansion-panel`). Its constructor no longer takes the
-  injected `COMPONENT_LIBRARY` token. `SmartExpandableSectionModule` no longer
-  imports the PrimeNG `AccordionModule`.
-- `UiActionButtonComponent` renders Material-only (the `pButton`/`pRipple` branch
-  is gone; always `mat-button`). Its constructor no longer takes the optional
-  `COMPONENT_LIBRARY` token (it previously defaulted to `PRIMENG` when unset).
-  `getType()` no longer has a PrimeNG class-map branch — it returns the
-  `mat-mdc-*` class strings unconditionally. (The dynamic `getbtnClass()`'s
-  `p-button-<color>` class token was later dropped in Phase 1.9.)
-- `UiActionToolbarComponent` constructor no longer takes the injected
-  `COMPONENT_LIBRARY` token. The dead `getType()` / `getbtnClass()` methods
-  (never referenced by the template) were removed, and the scroll-affordance
-  buttons use the Material icons `arrow_back` / `arrow_forward` unconditionally
-  (the PrimeNG `chevron-left` / `chevron-right` fallback is gone).
-- `UiActionConfirmDialogComponent` and `UiActionInputDialogComponent` render
-  their close button as a Material `mat-icon-button` unconditionally (the `@else`
-  `p-button` branch is gone); both constructors no longer take the injected
-  `COMPONENT_LIBRARY` token.
-- `SmartIconModule` no longer imports the PrimeNG `BadgeModule` (badges render
-  via the custom `ui-badge` component, unaffected).
-- `SmartViewContextModule` no longer imports the PrimeNG `ButtonModule`,
-  `TooltipModule`, `ToastModule`, `ImageModule`, or `OrderListModule` (all
-  unused after the branch deletions). The `primeng/api` `SharedModule`
-  (`PrimeSharedModule`) import was later dropped in Phase 1.9's final sweep.
-
-### PrimeNG package dependency removed (Phase 1.9)
-
-The `primeng` npm package is gone. Most importantly it is dropped from
-`@smartbit4all/ng-client`'s own **`peerDependencies`** (in
-`projects/smart-ng-client/package.json`, which flows into the published
-`npms/smart-ng-client/package.json`) — that entry is what previously forced every
-consuming host to install PrimeNG. It is also removed from the dev workspace
-(`package.json`, `package-lock.json`, `node_modules`), and both PrimeNG theme
-stylesheets (`primeng/resources/themes/saga-blue/theme.css`,
-`primeng/resources/primeng.min.css`) are removed from the app-playground `styles`
-in `angular.json`. Hosts that still list `primeng` as a dependency or load its
-theme CSS should remove both; 7.0 renders entirely on Material/CDK.
-
-#### Your own PrimeNG usage
-
-Removing the peer dependency does not remove PrimeNG from *your* code, and the measured
-hosts carry more of it than their authors expect — mostly as **dead module imports**. Across
-the 12 hosts, `DialogService` is imported 56 times, but 8 of those in p014 turned out to be
-nothing but the base-constructor argument above, and four PrimeNG modules in its
-`app.module.ts` rendered nothing at all.
-
-So the codemod separates the two cases, and the separation is decidable rather than
-guessed:
-
-- **`primeng-modules`** — a PrimeNG NgModule in an `imports:` array is **deleted** when none
-  of its selectors appears in any template in the repository. The scan runs over `.html`
-  *and* `.ts` (for inline templates) before anything is rewritten, and it distinguishes an
-  element (`<p-tree>`) from an attribute directive (`pTooltip`) so that a leftover
-  `class="p-button"` is not read as a component still in use. What the scan found is printed
-  in the header, because it is what licenses the deletions.
-- **`primeng-imports`** — everything else from `primeng/*` is reported with its replacement.
-  These are the real ports.
-
-The replacements, for what the hosts actually import:
-
-| PrimeNG | Material / CDK |
-|---|---|
-| `p-button` / `pButton` | `MatButtonModule` — `mat-button`, `mat-icon-button` |
-| `p-tree` | the library's `<smart-tree>`, or `MatTreeModule` |
-| `p-progressSpinner` | `MatProgressSpinnerModule` — `<mat-spinner>` |
-| `pTooltip` | `MatTooltipModule` (`matTooltip`), or `SmartTooltipDirective` |
-| `p-sidebar` | `MatSidenavModule` |
-| `pInputText` | `MatInputModule` — `matInput` inside `<mat-form-field>` |
-| `p-fieldset` | `MatCardModule`, or `<fieldset>` + `<mat-divider>` |
-| `p-divider` | `MatDividerModule` |
-| `p-accordion` | `MatExpansionModule`, or `<smart-expandable-section>` |
-| `p-table` | the library's `<smart-grid>`, or `MatTableModule` |
-| `p-editor` | ngx-quill's `<quill-editor>` (already a library dependency) |
-| `p-badge` / `pBadge` | `MatBadgeModule`, or `UiBadgeComponent` / `UiBadgeDirective` |
-| `p-menu`, `p-overlayPanel` | `MatMenuModule`, or the CDK Overlay |
-| `p-inputSwitch` | `MatSlideToggleModule` |
-| `p-dialog` | `MatDialog` — open a component instead of toggling `[visible]` |
-| `DialogService` | `MatDialog`. There is **no `header` option**: put `<h2 mat-dialog-title>` in the component |
-| `DynamicDialogRef` | `MatDialogRef` — `afterClosed()` replaces `onClose` |
-| `DynamicDialogConfig` | `MAT_DIALOG_DATA` for the data, `MatDialogRef` for the rest |
-| `PrimeNGConfig` | **delete it.** `setTranslation()` of day and month names is already covered by `MAT_DATE_LOCALE` + `SmartDateFnsAdapter` — the date-fns `hu` locale carries both the names and the Monday week start. **Confirmed on a running host** (p014, 2026-07-29, against a live backend): the datepicker opens on `2026. JÚL.` with `H K Sz Cs P Sz V`, i.e. Hungarian and Monday-first, exactly what the deleted `firstDayOfWeek: 1` + `dayNamesMin` used to buy. See [Dates](#dates-moment--date-fns-and-the-timezone-contract-phase-38) |
-| `MessageService` | `MatSnackBar` |
-| `ConfirmationService` | the library's `UiActionConfirmDialogService` |
-| `MenuItem` | the library's `UiActionModel`, or a plain `<mat-menu>` item |
-| `SharedModule` (`primeng/api`) / `PrimeTemplate` | a plain `<ng-template>` — PrimeNG needed `pTemplate`, Material does not |
-
-`primeicons` is a separate package. Nothing in 7.0 needs it, but nothing breaks if you keep
-it either — `pi pi-*` class names are just a font.
-
-### `QuillModule.forRoot()` in your root module
-
-`provideSmartNgClient()` calls `importProvidersFrom(QuillModule.forRoot())` itself — ngx-quill
-has no provider function, so the module is the only way to reach its root configuration. A
-root module that also calls it is configuring quill twice, so the codemod removes the call
-and its import. In a *feature* module the same call is that module's own configuration and is
-left alone.
-
-**Keep `ngx-quill` and `quill` in your `package.json`.** They are peer dependencies of the
-library — the host provides them. npm installs peers automatically, which is why hosts have
-got away with not declaring them, but any install that runs with `--legacy-peer-deps` drops
-them silently and the next build fails on an import that has always worked. Two of the twelve
-measured hosts were in exactly that state.
-
-**7.0 adds four peer dependencies 6.x did not have**, and they bite in a way the TypeScript
-errors do not prepare you for:
-
-```bash
-npm install ngx-mask@^22.0.0 fast-equals@^5.0.1 wavesurfer.js@^7.9.5 @angular/youtube-player@^22.0.0
-```
-
-If you install the library the normal way, npm brings these in for you. If you *swap a local
-build into `node_modules` by hand* — which is how you would try the library before it is
-published — npm never runs, so nothing installs them. The symptom arrives **after** the last
-TypeScript error is fixed, as five `Module not found` errors reported against the library's
-own `fesm2022` bundle rather than against any file of yours:
-
-```
-./node_modules/@smartbit4all/ng-client/fesm2022/smartbit4all-ng-client.mjs:7:0-60 -
-  Error: Module not found: Error: Can't resolve 'ngx-mask'
-```
-
-Four packages, five errors: `wavesurfer.js` is missing twice, once for its `record` plugin.
-
-- `UiActionButtonComponent.getbtnClass()` no longer emits the dead
-  `p-button-<color>` class token — it returns only `sb4-<color>` (nothing styled
-  `.p-button-*`; the platform button theme keys off `sb4-<color>` in
-  `custom-theme.scss`). Hosts with their own `.p-button-<color>` overrides for
-  sb4 action buttons should migrate them to `.sb4-<color>`.
-- `SmartViewContextModule` no longer imports the `primeng/api` `SharedModule`
-  (`PrimeSharedModule`); no template in the module used `pTemplate`.
-- `SmartComponentLayoutModule` no longer imports `InputGroupModule` /
-  `InputGroupAddonModule` (they were dead — no `p-inputGroup` template existed).
-
-The `ComponentLibrary` enum still exists with only its `MATERIAL` member in
-active use; its `PRIMENG` member and the remaining dead `ComponentLibrary.PRIMENG`
-code branches (icon/menu/widget components, dead `.p-*`/`.pi` CSS) are removed in
-a follow-up internal-cleanup step (1.10) — they are not a package dependency and
-do not affect hosts. `deviceInfo.componentLibrary` continues to report
-`material` to the backend.
-
-### ComponentLibrary / COMPONENT_LIBRARY removed entirely (Phase 1.10)
-
-7.0 is Material-only, so the `ComponentLibrary` abstraction (which had no second
-implementation once PrimeNG was gone) is deleted outright.
-
-- **Host action required:** `ComponentLibrary` (enum) and `COMPONENT_LIBRARY`
-  (injection token) are no longer exported from `@smartbit4all/ng-client`. Hosts
-  that provide `{ provide: COMPONENT_LIBRARY, useValue: ComponentLibrary.MATERIAL }`
-  in their root providers must **remove that provider and its import** — it now
-  fails to compile (no exported member). No replacement is needed; every component
-  renders Material-only.
-- Every `@Inject(COMPONENT_LIBRARY)` constructor argument is gone from the library
-  (smart-icon, click/hover tiered menu, photo-capture / voice-record widgets,
-  smart-voice-recorder, smart-file-editor, smart-multi-file-editor, sortable
-  widget, smart-filter-editor-content, validation-result-page, message-dialog, the
-  dialog services `SmartdialogService` / `SmartViewContextDialogService` /
-  `SmartViewContextErrorDialogService` / the ui-action confirm/input/file-upload
-  dialog services, and `PdfViewerDialogService` in `@smartbit4all/document-explorer`).
-  The `SmartdialogService` base constructor is now `(dialog, injector)` — subclasses
-  that called `super(dialog, dialogService, injector, compLib)` keep the first and
-  third arguments only. See [Phase 1.1](#dialog-stack-primeng-dynamicdialog--matdialog-phase-11);
-  the codemod rewrites it.
-- `SmartViewContextService` no longer exposes the public `componentLibrary` field
-  and no longer injects the token; it now writes the literal `'material'` into
-  `deviceInfo.componentLibrary` on every view-context update (the backend keys its
-  icon set on this string — `images-playground.properties` has `.material=` vs
-  `.primeng=` variants — so the value keeps flowing; the DTO field is unchanged).
-- All dead `ComponentLibrary.PRIMENG` branches and their PrimeNG icon names
-  (`chevron-right`, `pi pi-*`, `power-off`, `trash`, `file`, `exclamation-circle`,
-  `play-circle`/`stop-circle`, etc.) are removed; the Material icon path is now
-  unconditional. Dead `.p-*` / `.pi` CSS rules were purged from the library
-  (smart-icon, smartform, smartformwidget, the file editors/uploader,
-  ui-action-file-upload-dialog) and from the app-playground `custom-theme.scss`;
-  the app-playground `index.html` no longer loads the `primeicons` CDN stylesheet.
-- After 1.10, `grep -rin primeng projects` reports a single residual: the
-  auto-generated `deviceInfo.ts` DTO doc comment (`(Material, PrimeNg)`), which
-  mirrors the backend OpenAPI field description and is regenerated from it — left
-  untouched by design (the field itself is intentionally kept).
-
-### Angular 18 hop (Phase 2, 17 → 18)
-
-The library line now builds against Angular 18. Host-relevant changes:
-
-- **Peer dependency bumps** (hosts must upgrade together with the lib):
-  `@angular/*` `^18.0.0`, `@angular/youtube-player` `^18.2.14` (was lagging on
-  `^16` — its `^16 || ^17` peer range breaks a strict `npm install` on Angular
-  18, so it can no longer lag), `ngx-quill` `^26.0.0` (the Angular 18 line;
-  quill stays `^2.0.3`), `ngx-mask` `^18.0.0`, and — for
-  `@smartbit4all/document-explorer` — `ngx-extended-pdf-viewer` `^21.0.0`
-  (the 19.x/20.x lines cap their Angular peer below 18).
-- **`parchment` hoisting quirk (ngx-quill 26):** the ngx-quill 26 typings
-  reference `import("parchment")`, but npm may leave `parchment` nested under
-  `node_modules/quill/` (even after `npm dedupe`), which fails the host build
-  with `TS2307: Cannot find module 'parchment'`. Fix: add
-  `"parchment": "^3.0.0"` to the host devDependencies so it is hoisted to the
-  top level (quill 2 depends on parchment 3, so versions cannot conflict).
-- **Material theming (M2 compat APIs):** the `ng update @angular/material@18`
-  schematic rewrites M2 theme SCSS to the prefixed compat API
-  (`mat.define-palette` → `mat.m2-define-palette`,
-  `mat.$indigo-palette` → `mat.$m2-indigo-palette`,
-  `mat.define-light-theme` → `mat.m2-define-light-theme`, …). The theme stays
-  visually **M2** — no M3 switch happens at this hop; hosts running the
-  schematic get this rewrite automatically.
-- **`HttpClientModule` deprecation:** the `ng update @angular/core@18`
-  migration replaces `HttpClientModule` imports with
-  `provideHttpClient(withInterceptorsFromDi())`. Not a library breaking
-  change (the lib's generated API services were migrated internally), but
-  hosts will get the same automatic migration in their own modules.
-- TypeScript requirement raised to `>=5.4` (the repo builds on 5.5).
-
-### Angular 19 hop (Phase 2, 18 → 19)
-
-The library line now builds against Angular 19. Host-relevant changes:
-
-- **Peer dependency bumps** (hosts must upgrade together with the lib):
-  `@angular/*` `^19.0.0`, `@angular/youtube-player` `^19.0.0`,
-  `ngx-quill` `^27.0.0` (the Angular 19 line; quill stays `^2.0.3`),
-  `ngx-mask` `^19.0.0`, and — for `@smartbit4all/document-explorer` —
-  `ngx-extended-pdf-viewer` `^22.0.0` (the 21.x line caps its Angular peer
-  below 19).
-- **ngx-extended-pdf-viewer 22 input rename:** the `[showScrollingButton]`
-  input no longer exists — it is `[showScrollingButtons]` (plural,
-  `ResponsiveVisibility`). Hosts that use `<ngx-extended-pdf-viewer>` directly
-  must rename the binding, otherwise the template fails with NG8002.
-- **Standalone-by-default:** in Angular 19 components/directives/pipes are
-  standalone unless declared otherwise. The `ng update @angular/core@19`
-  migration automatically adds `standalone: false` to every NgModule-declared
-  declarable in the host codebase — run it and review the (large, mechanical)
-  diff. Declarables not referenced by any NgModule are skipped by the
-  schematic.
-- **Material theming:** the `ng update @angular/material@19` schematic splits
-  `@include mat.core()` into `@include mat.elevation-classes()` +
-  `@include mat.app-background()`. No visual change; hosts running the
-  schematic get this rewrite automatically.
-- **New NG8111 extended diagnostic** (warning): "Function in event binding
-  should be invoked". Uninvoked event bindings like
-  `(click)="(someCallback)"` — previously silently dead — are now flagged at
-  build time. Warning only, the build stays green.
-- TypeScript requirement stays satisfied by 5.5 (Angular 19 supports
-  TS 5.5–5.8). `ng update @angular/core@19` can install **TS 5.9** all the same, and the
-  build then stops with "requires TypeScript >=5.5.0 and <5.9.0"; pin `typescript ~5.8.3`
-  (p009-angular, 2026-10-27).
-- TS 5.8 reports two dead constructs as errors: **TS2869** on a `` `${x}` ?? '' `` (a template
-  literal is never nullish) and **TS2353** on a property the widget type does not have, e.g.
-  `direction` on a `SELECT` widget. Both never did anything; delete them (p034).
-
-### Angular 20 hop (Phase 2, 19 → 20)
-
-The library line now builds against Angular 20. Host-relevant changes:
-
-- **Peer dependency bumps** (hosts must upgrade together with the lib):
-  `@angular/*` `^20.0.0`, `@angular/youtube-player` `^20.0.0`,
-  `ngx-quill` `^28.0.0` (the Angular 20 line; quill stays `^2.0.3`),
-  `ngx-mask` `^20.0.0`, and — for `@smartbit4all/document-explorer` —
-  `ngx-extended-pdf-viewer` `^23.0.0` (the 22.x line caps its Angular peer
-  below 20). No pdf-viewer API rename at this bump (unlike 22.x).
-- **TypeScript 5.9 required** (Angular 20 supports 5.8–5.9); `ng update`
-  bumps it automatically. TS 5.9 adds **TS2872 "This kind of expression is
-  always truthy"**, which turns previously-silent dead `||` alternatives into
-  build errors — expect one or two in any older codebase.
-- **Material 20 button labels no longer set `white-space: nowrap`.** Material
-  20 dropped the MDC stylesheet (`@material/button`), which used to carry it.
-  Multi-word button labels now wrap, and any rule that lets the button size to
-  its content (the lib's `.mdc-button { height: fit-content }`) makes the
-  button grow taller. The lib restores the pre-20 look inside
-  `ui-action-button` (`.mdc-button__label { white-space: nowrap }`); **hosts
-  that render Material buttons of their own must add the same rule** if they
-  relied on single-line labels (typical symptom: a navigation bar that
-  suddenly wraps and overflows into scroll arrows).
-- **Material 20 renamed the MDC-era CSS custom properties**: e.g.
-  `--mdc-text-button-container-height` → `--mat-button-text-container-height`.
-  The `ng update @angular/material@20` schematic rewrites the ones it finds in
-  `.css`/`.scss` files; token names embedded in TS strings or host templates
-  must be renamed by hand.
-- **`DOCUMENT` moved from `@angular/common` to `@angular/core`.** Automatic
-  migration; `@angular/common`'s re-export is deprecated.
-- **`moduleResolution: "node"` → `"bundler"`** in `tsconfig.json` (and any
-  `tsconfig.lib.json` that sets it explicitly). Automatic migration; it changes
-  how sub-path exports resolve, so a host with hand-written `paths` entries
-  should re-verify its build. A deep import such as
-  `import { UiAction } from '@smartbit4all/ng-client/projects'` stops resolving
-  (TS2307); import from `@smartbit4all/ng-client` instead. A 4.5-era deep import of a
-  generated model (`@smartbit4all/document-explorer/lib/api/...`,
-  `@smartbit4all/ng-client/lib/smart-generic-pages/api/...`) breaks the same way and has no
-  root export: take the host's own generated model, or derive the type from the field it
-  copies (`AdminTemplate['file']`) (p034).
-- **A host without `skipLibCheck` that still imports `primeng/dynamicdialog` stays red from
-  this hop**: PrimeNG 17's typings name `InjectFlags`, which Angular 20 removed (TS2305 inside
-  `node_modules/primeng`). The 6.x `SmartdialogService` subclasses need that import until the
-  codemod removes it, so this hop joins 21 and 22 as red until the 7.0 library is in (p034).
-- **Workspace generation defaults**: the CLI adds a `schematics` block to
-  `angular.json` pinning the pre-20 file-naming style (`type: "component"`,
-  `typeSeparator: "."`). Cosmetic — it only affects newly generated files.
-- Optional migrations **not** run here (deferred to the modernization phase):
-  `use-application-builder` (esbuild), `control-flow-migration`,
-  `router-current-navigation`.
-- The `InjectFlags`, `TestBed.get` → `TestBed.inject` and
-  `provideServerRendering` migrations were no-ops for this codebase.
-- The NG8111 warnings introduced at the 19 hop are no longer emitted by the
-  Angular 20 compiler (the dead bindings themselves are unchanged).
-
-### Angular 21 hop (Phase 2, 20 → 21)
-
-The library line now builds against Angular 21. Host-relevant changes:
-
-- **Peer dependency bumps** (hosts must upgrade together with the lib):
-  `@angular/*` `^21.0.0`, `@angular/youtube-player` `^21.0.0`,
-  `ngx-quill` `^29.0.0` (the Angular 21 line; quill stays `^2.0.3`),
-  `ngx-mask` `^21.0.0`, and — for `@smartbit4all/document-explorer` —
-  `ngx-extended-pdf-viewer` `^25.0.0` (the 24.x line still caps its Angular
-  peer below 21). No pdf-viewer API rename at this bump.
-  - **`ngx-quill` 30.x is intentionally *not* used.** 30.x is the "zoneless"
-    line and drops the `zone.js` peer dependency; the 7.0 lib is still
-    zone-based. Hosts that have already gone zoneless may use 30.x, but the
-    lib is only validated against 29.x.
-- **TypeScript stays 5.9** and **zone.js stays 0.15** (Angular 21 accepts
-  `~0.15.0 || ~0.16.0`). **Node** must satisfy
-  `^20.19.0 || ^22.12.0 || >=24.0.0`.
-- **`MatCommonModule` is removed from `@angular/material/core` (breaking).**
-  It was already deprecated in Material 20 (`@breaking-change 21.0.0`). Any
-  host NgModule that imports it will fail to compile with
-  `Unknown reference` — and because a broken NgModule cascades, the real
-  error usually shows up as a flood of `NG8001: '<some-component>' is not a
-  known element` / `NG6002: … does not appear to be an NgModule class`
-  further down the build log. **Fix: just delete the import and the array
-  entry.** `MatCommonModule` had no template surface; it only
-  (a) applied the `cdk-high-contrast-*` body classes — `A11yModule` still
-  does this, and Material components that need it import `A11yModule`
-  themselves — and (b) re-exported `BidiModule`. If your host actually uses
-  the `Dir` directive or injects `Directionality`, import
-  `BidiModule` from `@angular/cdk/bidi` explicitly.
-  The lib dropped it from all 10 of its own modules.
-- **`provideZoneChangeDetection()` is now added at bootstrap** by the
-  `ng update` migration, e.g.
-  `bootstrapModule(AppModule, { applicationProviders: [provideZoneChangeDetection()] })`.
-  This keeps zone-based change detection explicit; behaviour is unchanged.
-- **The control-flow migration (`*ngIf` → `@if`) now runs as a *mandatory*
-  `ng update` migration**, not an optional one. It rewrites every structural
-  directive in the workspace. The lib **reverted** it to keep the version hop
-  reviewable — `NgIf`/`NgForOf`/`NgSwitch` still ship in Angular 21, so
-  `*ngIf`/`*ngFor` keep working. Hosts may keep or revert it as they prefer;
-  if you want it as a separate change, run
-  `npx ng generate @angular/core:control-flow` on its own commit.
-- **New `NG8107` extended diagnostic** (warning): an optional chain `?.`
-  whose left side can no longer be `null`/`undefined` under Angular 21's
-  sharpened template inference. Warning only — expect a batch of them in any
-  older template set.
-- **`tsconfig.json` loses its explicit `lib` array** (the CLI derives it from
-  `target`). Automatic migration.
-- The Material and CDK v21 migration schematics made no source changes, and
-  the `Router.lastSuccessfulNavigation` migration was a no-op. The optional
-  `router-current-navigation` migration was not run.
-- The `.mdc-button__label { white-space: nowrap }` workaround introduced at
-  the Angular 20 hop is **still required on Material 21** — the class still
-  exists in the button template and Material still ships no `white-space`
-  rule for it.
-
-### Angular 22 hop (Phase 2, 21 → 22) — final hop
-
-The library line now builds against **Angular 22**. This is the biggest
-host-facing hop of the series: it changes the **change-detection default**, the
-**HTTP backend default** and the **meaning of `?.` in templates**. All three are
-handled by `ng update` migrations, but you must let them run.
-
-- **Peer dependency bumps** (hosts must upgrade together with the lib):
-  `@angular/*` `^22.0.0`, `@angular/youtube-player` `^22.0.0`,
-  `ngx-quill` `^31.0.0` (the Angular 22 line; quill stays `^2.0.3`),
-  `ngx-mask` `^22.0.0`, and — for `@smartbit4all/document-explorer` —
-  `ngx-extended-pdf-viewer` `^28.0.0` (25/26/27 all cap their Angular peer
-  below 22). **No pdf-viewer API rename at this bump.**
-  `@ngx-translate/core` `^14` still works (its peer is `>=13`).
-- **TypeScript must be 6.0** (`@angular/compiler-cli` peers `>=6.0 <6.1`);
-  **zone.js stays 0.15** (`~0.15.0 || ~0.16.0`) and **rxjs is unchanged**.
-  **Node** must satisfy `^22.22.3 || ^24.15.0 || >=26.0.0` — note the
-  **22.22.3** floor, which is stricter than Angular 21's `^22.12.0`.
-
-#### 1. `ChangeDetectionStrategy.OnPush` is the new default
-
-In Angular 22 the enum is redefined: `OnPush = 0` (default), `Eager = 1`, and
-`Default = 1` is kept as a **deprecated alias of `Eager`**. Any component
-without an explicit `changeDetection` therefore switches from CheckAlways to
-OnPush — a real behaviour change for components that mutate their own state
-without signals or `markForCheck()`.
-
-An `ng update` schematic **automatically adds
-`changeDetection: ChangeDetectionStrategy.Eager` to every component that had
-none**, which keeps behaviour bit-identical. The lib took exactly this route
-(114 components) and did **not** opt into OnPush at this hop. Recommended host
-approach: let the schematic run, verify your app, and move components to OnPush
-deliberately afterwards.
-
-Watch out for components the schematic can skip — it only touches components it
-can resolve. After updating, grep for `@Component` files with no
-`changeDetection` and decide about each one; a component that is dynamically
-instantiated but never statically declared can slip through.
-
-#### 2. `provideHttpClient` now defaults to the fetch backend
-
-Angular 22 switches `HttpClient` from `XMLHttpRequest` to `fetch`. An
-`ng update` migration inserts **`withXhr()`** into your `provideHttpClient(...)`
-calls to preserve the old backend:
-
-```ts
-provideHttpClient(withXhr(), withInterceptorsFromDi())
-```
-
-The lib does this in `SmartViewContextModule`. **Hosts that call
-`provideHttpClient` themselves must do the same** (or consciously move to
-fetch). This matters most for **upload progress**: `reportProgress` events
-behave differently on the fetch backend, so if your host reports upload
-progress, keep `withXhr()` until you have retested it.
-
-#### 3. `?.` in templates now yields `undefined`, not `null`
-
-Angular 22's safe-navigation operator returns `undefined` where it used to
-return `null`. Where that difference is observable, an `ng update` migration
-wraps the expression in the **`$safeNavigationMigration()` compiler builtin**:
-
-```html
-[ngStyle]="calcStyle($safeNavigationMigration(diagramModel?.descriptor?.style))"
-```
-
-This is an official builtin (handled like `$any()` — the compiler unwraps it and
-the type-checker sees straight through it), not a temporary marker, so wrapped
-templates are safe to keep. The same `ng update` run also sets the
-`nullishCoalescingNotNullable` and `optionalChainNotNullable` extended
-diagnostics to `suppress` in your tsconfigs, which silences the `NG8107`
-warnings the Angular 21 hop introduced.
-
-#### 4. `ComponentFactoryResolver` is removed (breaking)
-
-`ComponentFactoryResolver` is gone and `ComponentFactory` is no longer public
-(it only survives as `ɵRender3ComponentFactory`). Code like this stops
-compiling with `TS2305` / `NG2003`:
-
-```ts
-constructor(private resolver: ComponentFactoryResolver) {}
-ngAfterViewInit() {
-  const factory = this.resolver.resolveComponentFactory(MyComponent);
-  this.vcRef.createComponent(factory);
-}
-```
-
-Replace it with the type-based overload — behaviour is identical (v22 builds the
-same factory internally and resolves the injector from the parent):
-
-```ts
-ngAfterViewInit() {
-  this.vcRef.createComponent(MyComponent);
-}
-```
-
-**Public-API change in the lib:** `ComponentFactoryService` no longer exposes
-its `factory` field. `createComponent()` / `destroyComponent()` keep their
-signatures, so hosts that only call those need no change.
-
-#### 5. TypeScript 6.0 deprecates `baseUrl` and `downlevelIteration`
-
-TS 6.0 raises **`TS5101`** for both options ("deprecated and will stop
-functioning in TypeScript 7.0"). Two ways out:
-
-- Remove them. `downlevelIteration` is a no-op at `target: ES2022`. `baseUrl`
-  can only go once every non-relative first-party import (`from 'projects/…'`,
-  `from 'src/…'`) is relative or covered by a `paths` entry.
-- Or silence them for now with `"ignoreDeprecations": "6.0"` in
-  `compilerOptions`. This is what the lib workspace does, because `baseUrl` is
-  still load-bearing there. It only buys time until TS 7.
-
-#### 6. Other notes
-
-- **Material 22 removed no further modules or tokens** — the CDK and Material
-  v22 migration schematics made no source changes. CDK 22 moves to a
-  package `exports` map (the per-entry-point sub-directories are gone from
-  `node_modules/@angular/cdk`), but every `@angular/cdk/*` import still
-  resolves; this only matters if you referenced those paths on disk.
-- The `.mdc-button__label { white-space: nowrap }` workaround introduced at the
-  Angular 20 hop is **still required on Material 22** — the class still appears
-  in Material's button template and Material still ships no `white-space` rule
-  for it.
-- **The control-flow migration did not re-run at this hop** (it was mandatory at
-  21). The lib still ships `*ngIf`/`*ngFor` templates; `NgIf`/`NgForOf`/
-  `NgSwitch` continue to work in Angular 22.
-- **The webpack-based builders are deprecated.** `@angular-devkit/build-angular`
-  now prints a notice recommending `@angular/build`. Nothing breaks yet, but
-  plan the switch.
-- `strictTemplates` is on by default in v22; the lib workspace was already
-  strict, so nothing changed. If your host was not strict, the `ng update`
-  migration adds `"strictTemplates": false` to keep it that way.
-- A `@HostListener('document:keydown.enter', ['$event'])` handler typed `KeyboardEvent` fails
-  with TS2345 (`Event` is not assignable); type the parameter as `Event` when the handler only
-  reads `target` (p034).
-- **An Angular CLI 1x `src/test.ts` breaks `ng test`**: `require.context` is a webpack API the
-  22 karma builder no longer provides (`__webpack_require__(...).context is not a function`,
-  0 specs run). Delete the `require.context` block; the builder collects the specs from
-  `tsconfig.spec.json` itself (p034).
-
-### The third-party packages the library does *not* own (Phase 2)
-
-Every hop section above lists the library's own peer dependencies. Your host almost
-certainly carries packages the library never sees, and those have their own Angular
-peer ceilings — each one can stop a hop dead. Measured on p014 (2026-07-29), which
-went 17 → 22 with the library still installed:
-
-- **`@swimlane/ngx-charts` needs a ladder of its own**: `20 → 22 → 22 → 23 → 24 → 25`
-  across the five hops. At the Angular 21 hop it peer-caps the CDK, and because
-  `ng update`'s own `npm` step is **not** `--force`d (even when you passed `--force`
-  to `ng update`), the install fails there while `package.json` has already been
-  written correctly. The fix both times was to redo the install by hand, not to
-  re-run the update. `p043` and `app-tournament` both carry ngx-charts `^20.4.1`
-  and will hit this; `app-fitnessmirror` and `app-finance-ai` do not.
-- **`ngx-extended-pdf-viewer` moved to `.mjs`** at the 21 hop and stopped shipping
-  `pdf-3.10.560-es5.min.js`. If your `angular.json` names that file under `scripts`
-  or `assets`, the build fails on a missing file rather than on anything Angular.
-- **`karma` and `@angular/build`**: `@angular/build` 22 declares
-  `peerOptional karma@^6.4.0`. A host pinned to `~6.3.0` gets a wall of
-  `npm warn ERESOLVE overriding peer dependency` — **warnings, exit code 0**, so it
-  is not blocking. It becomes a *hard* install failure the moment `@angular/build`
-  is a direct devDependency rather than a nested one, which is what happened in the
-  library workspace. `karma@~6.4.4` clears it.
-- **`ngx-markdown` 22 lazily imports `marked-katex-extension`**, an optional peer. The
-  application builder leaves that import alone; the webpack `browser` builder every measured
-  host still runs resolves it, and the build fails with `Can't resolve
-  'marked-katex-extension'` against ngx-markdown's own bundle. Declare
-  `katex@^0.16` and `marked-katex-extension@^5`: webpack only puts them in a lazy chunk that
-  loads when KaTeX is switched on. ngx-markdown 22 also wants `marked@^17 || ^18` declared
-  (app-formmate, 2026-09-22).
-
-The general shape: **`ng update` needs `--force` at every hop** (the library and
-PrimeNG both peer-cap at Angular 17 until the very end), and `--force` covers the
-Angular schematics but not the `npm install` they trigger. When that install fails,
-check `package.json` before assuming the hop did nothing — it is usually already
-correct.
-
-### Housekeeping (Phase 3.0)
-
-#### The dialog's built-in Ok/Cancel buttons are gone
-
-`smartdialog.component.html` no longer renders an `Ok` and a `Cancel` button.
-They were dead: their `(click)` handlers were the no-op expressions
-`(click)="(data.okCallback)"` / `(click)="(data.cancelCallback)"` — a bare
-property read, not a call — so pressing them did nothing, and the whole block
-was behind `*ngIf="!data.customComponent"`, which is never true for a host
-dialog (`SmartDialog.ngAfterViewInit` unconditionally instantiates
-`data.customComponent`).
-
-**The `okCallback` / `cancelCallback` model fields stay.** Hosts set and invoke
-them from their own `customComponent` dialogs, and that keeps working
-unchanged. Only the library-rendered buttons are gone. The `actionCallback` /
-`actionLabel` button — the one with a real handler (`onActionClick()`) — is
-untouched.
-
-Action needed: none, unless you relied on the library rendering those two
-buttons — in which case they never worked, and you should render them in your
-own dialog component.
-
-### Full standalone + `provideSmartNgClient()` (Phase 3.2) — **the big one**
-
-This is the change that rewrites your `app.module.ts`. Everything else in this
-guide is small next to it.
-
-#### Every NgModule is gone
-
-The library no longer ships a single `@NgModule`. All 58 are deleted —
-`SmartNgClientModule`, `SmartViewContextModule`, `SmartSessionModule`,
-`SmartGridModule`, `SmarttableModule`, `SmarttreeModule`, `SmartdialogModule`,
-`SmartIconModule`, `SmartNavbarModule`, `SmartFilterModule`,
-`SmartFilterEditorModule`, `SmartComponentLayoutModule`,
-`SmartExpandableSectionModule`, `SmartMapModule`, `SmartDiagramModule`,
-`SmartNavigationModule`, `SmartValidationModule`, `SmartGenericPagesModule`,
-`ComponentFactoryServiceModule`, `SharedModule`, `SmartTabGroupModule`,
-`SmartDocuStoreExplorerModule` and the generated OpenAPI `ApiModule`s.
-
-Every component, directive and pipe is now **standalone**. Import the ones your
-templates use directly, in the component that uses them:
-
-```ts
-@Component({
-  selector: 'app-my-page',
-  templateUrl: './my-page.component.html',
-  imports: [SmartGridComponent, UiActionToolbarComponent, SmartEmbeddedSlotDirective],
-})
-export class MyPageComponent extends SmartComponent<MyModel> { … }
-```
-
-**The compiler tells you what is missing** — one `NG8001: '<smart-grid>' is not
-a known element` per unresolved element, per template. Work through them; there
-is no guessing involved. In practice ~16 module imports become ~40 component
-imports spread across the components that actually use them.
-
-**The compiler does NOT tell you about the DI changes below.** Nothing fails at
-build time if you get those wrong; you find out on the first page load. Smoke
-your app.
-
-#### `provideSmartNgClient(config, ...features)` replaces the module imports
-
-```ts
-bootstrapApplication(AppComponent, {
-  providers: [
-    provideAnimations(),
-    provideRouter(ROUTES),
-    provideSmartNgClient(
-      {
-        gridMenuIcon: 'more_horiz',
-        treeMenuIcon: 'more_horiz',
-        aclEditingViewName: Pages.ACL_MATRIX_PAGE,
-        invalidSmartlinkPageName: Pages.INVALID_SMARTLINK_PAGE_NAME,
-        namedValidators: [MY_VALIDATOR_FACTORY],
-      },
-      withSmartMap({ engine: MapEngine.LEAFLET }),
-      withSmartDiagram({ customOptions: [MY_CHART] })
-    ),
-    { provide: HTTP_INTERCEPTORS, useClass: MyLoadingInterceptor, multi: true },
-  ],
-});
-```
-
-The core is always wired and cannot be forgotten: session, view context, the
-three BFF interceptors, layout, form, grid, table, tree, dialog, icon, navbar,
-filter, filter editor, validation, expandable section, navigation, shared and
-the generic pages. That is the point — the session and header interceptors used
-to be easy to leave out, and leaving them out fails *silently* (no
-`Authorization` header).
-
-Only two features are opt-in, because they pull heavy third-party code that not
-every host renders: `withSmartMap()` (leaflet / Google Maps) and
-`withSmartDiagram()` (chart.js). There is **no `withSmartTabGroup()`** —
-`smart-tab-group` had no component left, only an empty module, and is deleted.
-
-`provideSmartNgClient()` calls `provideHttpClient()` itself, with
-`withInterceptorsFromDi()` and its own three functional interceptors, and leaves the backend
-on the framework default (fetch). Your own class-based `HTTP_INTERCEPTORS` keep working and
-still run after the library's three. Pass extra `HttpClient` features in
-`config.httpFeatures` rather than making a second `provideHttpClient()` call — see
-[HTTP](#http-the-library-no-longer-forces-the-xhr-backend-phase-38), which is also where the
-6.x "do not call it twice" trap went.
-
-#### String-keyed providers become typed config fields
-
-Delete these from your providers array and pass them to `provideSmartNgClient`:
-
-| 6.x provider | 7.0 config field |
-|---|---|
-| `{ provide: 'gridMenuIcon', useValue: … }` | `gridMenuIcon` |
-| `{ provide: 'treeMenuIcon', useValue: … }` | `treeMenuIcon` |
-| `{ provide: 'searchPageName' / 'searchComponentName', … }` | `searchPageName` / `searchComponentName` |
-| `{ provide: 'genericPageName' / 'genericComponentName', … }` | `genericPageName` / `genericComponentName` |
-| `{ provide: 'subjectSelectorPageName' / 'subjectSelectorComponentName', … }` | `subjectSelectorPageName` / `subjectSelectorComponentName` |
-| `{ provide: 'validationResultPageName' / 'validationResultComponentName', … }` | `validationResultPageName` / `validationResultComponentName` |
-| `{ provide: 'noPermissionPageName' / 'noPermissionComponentName', … }` | `noPermissionPageName` / `noPermissionComponentName` |
-| `{ provide: 'invalidSmartlinkPageName' / 'invalidSmartlinkComponentName', … }` | `invalidSmartlinkPageName` / `invalidSmartlinkComponentName` |
-| `{ provide: 'aclEditingViewName', useValue: … }` | `aclEditingViewName` |
-| `{ provide: DIALOG_DISABLE_CLOSE, useValue: … }` | `dialogDisableClose` |
-| `{ provide: MAT_DATE_LOCALE, useValue: 'hu-HU' }` | `dateLocale` — **or keep the provider as it is**, which is what the codemod does; see [Dates §2](#2-leave-your-mat_date_locale-provider-alone) |
-| `SmartWidgetSettings.useUtc = true` (a static, not a provider) | **delete it** — the flag is gone with the moment adapter; see [Dates §4](#4-smartngclientconfiguseutcdates-is-removed) |
-| `{ provide: NAMED_VALIDATOR, useValue: F, multi: true }` | `namedValidators: [F]` |
-| `{ provide: SMART_DEFAULT_VIEW_COMPONENTS, useValue: E, multi: true }` | `defaultViewComponents: [E]` |
-| `SmartValidationModule.forRoot([...])` | `namedValidators` — **the element type changes**, see below |
-| `SmartDiagramModule.forRoot([...])` | `withSmartDiagram({ customOptions })` |
-| `{ provide: MAP_ENGINE, useValue: … }` | `withSmartMap({ engine })` |
-
-`'pageName'`, `'componentName'` and `'treeId'` stay as string tokens on purpose:
-they identify one component instance rather than configuring the library, and
-hosts also provide them at component level.
-
-You can also delete these from your **root** providers array — the core provides them:
-`SmartSessionService`, `SmartViewContextService`, `SmartNavigationService`,
-`SmartIconService`, `SmartFilterEditorService`, `SmartFormService`,
-`SmartCookieService`, `NamedValidatorService`, `ComponentFactoryService`, and the date
-adapter wiring (`MAT_DATE_FORMATS`, `DateAdapter`).
-
-⚠️ **`namedValidators` takes factories, not providers.** `SmartValidationModule.forRoot()`
-took `Provider[]`, so hosts wrote the wrapper by hand:
-
-```ts
-// 6.x — validator.factories.ts
-export const VALIDATOR_PROVIDER_EMPTY_INPUT: Provider = {
-  provide: NAMED_VALIDATOR, useValue: VALIDATOR_FACTORY_EMPTY_INPUT, multi: true,
-};
-// app.module.ts
-imports: [SmartValidationModule.forRoot([VALIDATOR_PROVIDER_EMPTY_INPUT])]
-```
-
-`provideSmartNgClient()` adds that wrapper itself, so the config takes the bare
-`ValidatorFactory[]`. Export the factories and pass those:
-
-```ts
-// 7.0
-export const VALIDATOR_FACTORY_EMPTY_INPUT: ValidatorFactory = { … };
-provideSmartNgClient({ namedValidators: [VALIDATOR_FACTORY_EMPTY_INPUT] })
-```
-
-The codemod moves the argument into the config and **reports it**, because the entries are
-normally named constants declared in another file and only you know what each one wraps. If
-you miss the note, `TS2322: Type 'Provider' is not assignable to type 'ValidatorFactory'`
-lands on every element.
-
-⚠️ **The same line on a `@Component` is not the same thing.**
-`providers: [SmartFilterEditorService]` on a page component asks for one instance *per page*,
-which is usually deliberate — p014 does it in five components. Leave those alone; the codemod
-does.
-
-#### The module → standalone mapping
-
-What each `Smart*Module` used to export, reduced to what 7.0 still exports publicly. An
-NgModule's `imports:` array accepts standalone components, so this substitution is all a host
-that is still NgModule-based needs to keep compiling — the codemod performs it.
-
-| 6.x module | 7.0 imports |
-|---|---|
-| `SmartNgClientModule` | the union of the fourteen it re-exported (everything below except the generic pages, the filter editor, the map and the diagram) — trim it to what your templates use |
-| `SmartComponentLayoutModule` | `SmartComponentLayoutComponent` |
-| `SmartViewContextModule` | `UiActionToolbarComponent`, `UiActionButtonComponent`, `UiActionDialogButtonComponent`, `SmartformComponent`, `SmartfileuploaderComponent`, `SmartFileEditorComponent`, `SmartMultiFileEditorComponent`, `SmartVoiceRecorderComponent`, `SmartEmbeddedSlotDirective`, `HighlightPipe` |
-| `SmartGridModule` | `SmartGridComponent` |
-| `SmarttreeModule` | `SmartTreeComponent` |
-| `SmartdialogModule` | `SmartDialog` |
-| `SmartIconModule` | `SmartIconComponent`, `UiBadgeComponent`, `UiBadgeDirective` |
-| `SmartNavbarModule` | `SmartNavbarComponent` |
-| `SmartFilterModule` | `SmartFilterComponent` |
-| `SmartFilterEditorModule` | `SmartFilterEditorContentComponent` |
-| `SmartExpandableSectionModule` | `ExpandableSectionComponent` |
-| `SmartSessionModule` | `SmartSessionTimerComponent` |
-| `SmartGenericPagesModule` | `SearchPageComponent`, `GenericPageComponent`, `SubjectSelectorComponent`, `InvalidSmartlinkComponent` |
-| `SmartMapModule` | `SmartMapComponent` + `withSmartMap({ engine })` |
-| `SmartDiagramModule` | `SmartDiagramComponent` + `withSmartDiagram({ customOptions })` |
-| `SharedModule` | `SmartTooltipDirective`, `SmartDatePipe`, `SmartDateTimePipe`, `SmartTimePipe` |
-| `SmartValidationModule` | nothing — `forRoot()`'s validators become `namedValidators` |
-| `SmarttableModule` | nothing — `SmarttableComponent` is no longer public; render a `<smart-grid>` |
-| `SmartNavigationModule`, `ComponentFactoryServiceModule` | nothing — they only carried services, which the core provides |
-| `SmartTabGroupModule` | nothing — deleted; it had no component left |
-| `SmartDocuStoreExplorerModule` (`@smartbit4all/document-explorer`) | `SmartDocuStoreExplorerComponent`, `FolderContentComponent`, `PdfViewerDialogPageComponent` |
-
-Two things this table will not tell you, and the compiler will not either: an import you no
-longer need is invisible (unused entries in an NgModule `imports:` array are not reported),
-and a name you already bind from elsewhere — a `SmartDatePipe` of your own — must not be
-imported twice. The codemod reports both cases rather than guessing.
-
-#### Your `SmartComponent` subclasses silently become OnPush
-
-This is an **Angular 22 fact rather than something 7.0.0 introduces**, but it
-lands on you at the same moment, so it is worth stating plainly: `SmartComponent`
-is an abstract `@Component`, and each of your subclasses carries its own
-`@Component` decorator. On Angular 22 a component without an explicit
-`changeDetection` gets the new `OnPush` default. p014 has 75 such subclasses,
-p043 has 70.
-
-Let the `ng update` schematic add `changeDetection: ChangeDetectionStrategy.Eager`
-to all of them (that is what the library did), verify your app, and move to
-OnPush deliberately afterwards. A subclass that mutates its own state outside a
-signal and without `markForCheck()` will stop repainting under OnPush.
-
-#### Removed from the public API
-
-A major is the only chance to narrow the surface, so these are no longer
-exported. All of them are library internals; none is used by p014, p043,
-app-formmate or `@smartbit4all/document-explorer`:
-
-- `SmarttableComponent`, `SmarttableService` — use `<smart-grid>`, which renders
-  the table internally. **All `SmartTable*` model types stay** (`SmartTableType`,
-  `SmartTableInterfaceTypeEnum`, `SmartTableHeader`, …). p043 imports
-  `SmarttableComponent` in `ad-groups.component.ts` but never uses it — delete
-  that one import line. An import is not the only way in: p009-angular created it
-  through `ComponentFactoryService` (`recommendations-page`), so grep for the class
-  name, not only for the import, and rebuild such a page on `<smart-grid>`. p034 used it
-  three times for a client-side check box table (a `<smarttable>` in a template and two
-  `ComponentFactoryService` sites) whose rows come from the host, not from a backend grid;
-  there a small host component rendering the still public `SmartTable` model with
-  `mat-table` keeps the pages, because `<smart-grid>` needs a backend grid model.
-- `GoogleMap`, `LeafletMap`, `AbstractMap` — select an engine with
-  `withSmartMap({ engine })`.
-- `SmartFilterParamComponent`, `SmartFilterParamsComponent`,
-  `SmartFilterExpressionItemComponent`, `SmartFilterExpressionItemsComponent` —
-  internals of `SmartFilterEditorContentComponent`, which stays public.
-- `HoverMenuComponent`, `ClickMenuComponent` — rendered by the ui-action toolbar.
-- `UiActionConfirmDialogComponent`, `UiActionInputDialogComponent` — opened by
-  their services, which stay public.
-- `UploadWidgetComponent`, `PhotoCaptureWidgetComponent`,
-  `VoiceRecordWidgetComponent` — contents of the ui-action upload dialog.
-- `SmartNgClientService` — deleted; it was an empty stub with no members.
-- The generated `ApiModule`s — they had no usages and their `forRoot()` told you
-  to import `HttpClientModule`, which no longer applies.
-
-Two internal string tokens are gone as well, replaced by real `InjectionToken`s
-(`'confirmDialogService'`, `'textFieldDialogService'`, `'fileUploadDialogService'`).
-No host provided them, so no action is needed.
-
-#### Behaviour notes
-
-- `<mat-slide-toggle>` in the form widget no longer carries a `value` binding,
-  `<mat-nested-tree-node>` no longer carries an interpolated `matTreeNodeToggle`,
-  and the ui-action menus no longer carry `[subActions]`. All four were dead
-  bindings that the NgModules' `CUSTOM_ELEMENTS_SCHEMA` had been hiding — they
-  wrote a DOM property nobody read. Rendering is unchanged.
-- The same schema on a **host** module hides library selectors that 7.0 no longer
-  exports: the template compiles and the element renders nothing.
-  `<smart-filter-group-params>` (p009-angular, two admin pages) is one; grep the
-  templates for `smart-` selectors that the build does not resolve.
-- The dead `ExpandableGridComponent` is deleted (it was declared in
-  `SmartGridModule` but its selector was used nowhere).
-
-### Widget ↔ SmartComponent: the model routing is inverted (Phase 3.4)
-
-A widget no longer waits to be collected by the screen component it lives in: it finds its
-`SmartComponentApiClient` through DI and registers itself. `SmartComponent` carries the
-channel as an inherited host directive, so **no host component has to be changed for the
-routing itself** — everything below is the *legacy surface* that went with the old
-collection path. The protocol is written up in `WIDGETS.md` next to this file; the decision
-record behind it is ADR-0005 in the `platform-angular2` working copy.
-
-#### What a host must delete (all of it mechanical, all reported by the compiler)
-
-| Delete | Why |
-|---|---|
-| `this.useQueryLists = true;` | The property is gone. Its setter rejected anything but `true`, so every branch behind it was unreachable — this was a no-op that logged a warning. |
-| `[parentSmartComponent]="this"` on `<smart-component-layout>` | The input is gone; the layout injects the client. `strictTemplates` reports leftovers as **NG8002**. |
-| `this.addForm(id, smartForm, formComponent)` | Gone. A `<smartform>` that displays the client's model registers itself. Two call styles existed; where the return value was used, it was the `smartForm` argument — use that (which makes those lines self-assignments, so they just go). **Delete the scaffolding around the call too**: in p014 the 21 calls left behind 9 empty `if (this.formX) { }` guards and 3 `new Promise((r) => setTimeout(r, 500)).then(() => { })` wrappers whose only content had been the registration. The compiler does not complain about either. |
-| `this.widgets.delete(…)` / `this.widgets.set(…)` / `this.formWidgets…` | The maps are gone (they were only written by the legacy path and read by nothing). |
-| the 4th argument of `addGrid(smartGrid, options, useAsDefaultGrid, componentReference)` | `addGrid()` keeps the options and the default-grid role; the services it used to copy into the grid model (`uiActionService`, `uiActionDescriptorService`, `serviceToUse`, `viewContextService`) are the grid's own DI job now. |
-| `override getSmartXxxQL()` (e.g. the two `throw new Error` overrides in a `FilterPageService`) | The eight abstract getters are gone from `SmartComponentApiClient`. |
-| `this.getSmartGridsQL()` and friends | If a component really wants its own widgets, it declares the view query itself: `@ViewChildren(SmartGridComponent) grids!: QueryList<SmartGridComponent>` — same reach as the removed getter had. |
-| `handleDataChangeSubscriptions()` | Gone. A form publishes its own value-change keys when it constructs. |
-
-Removed from the public API in the same step, in case a host imported them directly:
-`SmartComponentLayoutUtility` and its `EmbeddedSlotInfo` interface (the whole file — its
-collectors walked the layout tree for widgets, which nothing does now), and the `[parent]`
-inputs of `<smart-map>` / `<smart-diagram>` (they were bound to `parentSmartComponent` and read
-by nothing; both widgets resolve the client themselves). `initActions()` also runs less often:
-only when the model or its action list changes, no longer after every layout render, grid view
-init and filter model change — a host override that relied on one of those extra calls has to
-key off `dataChanged` instead.
-
-The [codemod](#migrating-a-host-the-codemod) deletes the first two rows and the last one, and
-lists the rest — `addForm()`, the 4th `addGrid()` argument, the getter overrides — with their
-line numbers, because each of those is a small decision rather than a substitution.
-
-#### What stays
-
-- `SmartService` — a view-less client. Its `@ViewChildren` never populated anyway; they are
-  simply gone now.
-- `initActions()` — still the hook a host overrides to build its own action list. The base
-  implementation only asks for a render; toolbars pull their actions themselves.
-- `setUpDefaultTree()` / `createTreeService()`, `addGrid()`, `submitForms()`,
-  `getInvalidFields()`, `uiActionModels` (now a getter over the model's actions).
-
-#### `uiActionModels` is read-only now — assigning to it no longer compiles
-
-It became a getter over the `actionModels` computed, so a host that *replaced* the list in
-place gets `TS2540: Cannot assign to 'uiActionModels' because it is a read-only property`.
-Measured in **p014 and p043**, `document-storage-editor.component.ts`:
-
-```ts
-// before — no longer compiles
-this.uiActionModels = this.uiActionModels.filter((a) => a.uiAction.code !== 'CANCEL');
-
-// after — filter into a field of your own and bind it
-protected readonly visibleActions = signal<UiActionModel[]>([]);
-// …
-this.visibleActions.set(this.uiActionModels.filter((a) => a.uiAction.code !== 'CANCEL'));
-```
-
-```html
-<smart-ui-action-toolbar [uiActionModels]="visibleActions()"></smart-ui-action-toolbar>
-```
-
-A plain field works just as well; what matters is that the **array reference changes**, which
-is what tells the toolbar to re-render. See also the entry-freeze note in the Phase 3.7
-section.
-
-#### Behavioural deltas, accepted
-
-- **Wider reach.** A widget in a host's *own* sub-component now participates, where a view
-  query could not see it (measured on p014/p043: 5 toolbars and 3–4 forms per host). A form
-  takes part only if it displays the client's component model, which is what the forms the
-  queries used to find have in common; a form that renders something else of its own (a
-  search box, a field editor) does not.
-- Two widgets sharing one identifier both reload; the old map kept only the last.
-- `getInvalidFields()` collects in subscription order rather than view order — visible only
-  in the order of the names in the validation dialog.
-- A toolbar entry is tracked by a synthesized key (action code + ordinal among entries with
-  the same code), so a button's DOM node — with its focus and ripple — follows its action
-  across reordering. Rendering is otherwise identical.
-
-#### `[smartComponentDetached]`
-
-The one brake on the automatic registration. Put it on an element whose subtree deliberately
-renders something other than the client's model; widgets below it resolve an empty slot and
-neither reload nor take part in submit/validation.
-
-```html
-<div smartComponentDetached>
-  <smart-grid [smartGrid]="ownGrid" [uuid]="ownUuid"></smart-grid>
-</div>
-```
-
-#### `SmartSubject` is deleted
-
-It was a no-op wrapper over `Subject`: `subscription.add(this.unsubscribe$.subscribe())`
-registers the teardown in the wrong direction, so after `destroy$.next()`, `.complete()` or
-`.unsubscribe()` subscribers still received values. Replace `new SmartSubject(destroy$)`
-with `new Subject()`; where a subscription really must die with a component, use
-`takeUntil(this._destroy$)` (which is what actually stopped delivery all along) or
-`takeUntilDestroyed()`. No host used it.
-
-### Toolbars resolve their own actions and own the execution context (Phase 3.5)
-
-One rule decides which actions a toolbar shows, and the toolbar — not each list entry —
-says who performs them. `WIDGETS.md`, *Toolbars*, is the short version; the decision record
-behind it is ADR-0006 in the `platform-angular2` working copy.
-
-> A toolbar renders the actions **addressed to its `id`** (`uiAction.toolbar == id`). The
-> list comes from an explicit `[uiActionModels]` binding if there is one, otherwise from the
-> screen component above it in the DOM. **Without an `id` it never pulls** — "unaddressed" is
-> not an address, so a toolbar with neither an id nor a binding shows nothing.
-
-`[uiActionModels]="uiActionModels"` therefore keeps meaning "put my page's unaddressed
-actions here" and needs no change.
-
-#### `UseUiAction` is deleted; `UseUiAction2` is now `UiActionExecutor`
-
-There is one executor interface. If a host class implements `UseUiAction` — a `submit` /
-`reSubscribeToChange` subject handshake — replace the two subjects with the two methods:
-
-```ts
-// before
-export class DelegateInboxDialogService implements UseUiAction {
-  submit: Subject<void> = new Subject();
-  reSubscribeToChange: Subject<void> = new Subject();
-  …
-}
-
-// after
-export class DelegateInboxDialogService implements UiActionExecutor {
-  submitForm(validate: boolean): void {
-    this.submit.next();   // keep the subject if a component subscribes to it
-  }
-  getInvalidFields(): SmartFormInvalidFields {
-    return { invalidFieldKeys: [], invalidFieldNames: [] };
-  }
-  …
-}
-```
-
-`Subject.next()` is synchronous, so a component that subscribed to `submit` has already run
-by the time `submitForm()` returns — which is exactly what the old handshake tried to
-express. Keep `reSubscribeToChange` only if something subscribes to it; the library no longer
-fires it.
-
-This also **fixes a silent hang**: the old branch `await`ed `submit.toPromise()`, which only
-settles when somebody `complete()`s the subject. Three of the five implementors never did, so
-a `submit`/`model` action on those services waited forever.
-
-#### `UiActionService.execute()` lost its first argument
-
-It was always `uiActionModel.uiAction`:
-
-```ts
-- this.uiActionService.execute(uiActionModel.uiAction, uiActionModel);
-+ this.uiActionService.execute(uiActionModel);
-```
-
-#### The execution context moved from the entry to the toolbar
-
-| what | bind on the toolbar | entry field (still honoured) |
-|---|---|---|
-| who performs the action | `[executor]` | `serviceToUse` — **deprecated** |
-| which widget it runs against | `[widgetId]` | `widgetId` — **deprecated**, wins if set |
-| which row inside it | `[nodeId]` | `nodeId` — **deprecated**, wins if set |
-| extra params for every action | `[actionParams]` | (clone the `UiAction` — no longer necessary) |
-
-`[executor]` defaults to the screen component the toolbar sits under, which is what almost
-every entry named. Bind it only when the actions belong to another API — a tree service, a
-filter editor, a dialog service of your own:
-
-```html
-<smart-ui-action-toolbar [uiActionModels]="actions" [executor]="myService"></smart-ui-action-toolbar>
-```
-
-`[actionParams]` replaces cloning a `UiAction` per row just to inject a model:
-
-```html
-<smart-ui-action-toolbar
-  [uiActionModels]="rowActions"
-  [widgetId]="gridId"
-  [nodeId]="row.id"
-  [actionParams]="{ model: row }"
-></smart-ui-action-toolbar>
-```
-
-#### Removed from the public API
-
-| Removed | Replacement |
-|---|---|
-| `UseUiAction` | `UiActionExecutor` (see above) |
-| the third `SmartTable` constructor parameter and `getServiceToUse()` | nothing — the executor no longer travels through the table (0 host call sites) |
-| `SmartformComponent.getToolbars()` | nothing collects toolbars any more; each one resolves its own actions |
-| `ISmartFilterEditorService.get/setComplexToolbars()` and the `submit` / `reSubscribeToChange` members | as above |
-| `FileEditorToolbarComponent` | a plain `<smart-ui-action-toolbar>` with `[actionParams]` |
-| `SmartGridComponent.setupToolbar()` / `.toolbar` / `.headerToolbar` | the id is a binding; there is nothing to reach into |
-
-#### Behavioural deltas, accepted
-
-- A widget renders a toolbar exactly when its model carries a `toolbarId`, with no type list.
-  A `toolbarId` on a type whose template has no place for a toolbar (`RECORDING_UPLOADER`)
-  now logs a warning instead of being silently dropped.
-- Only the actions a toolbar actually shows are scheduled. Since 3.4 a toolbar armed every
-  scheduled action of the view, so one action could fire from several toolbars at once.
-- A grid row's actions are no longer cloned per row; the row model travels as
-  `[actionParams]`. The multi-file editor's per-file toolbars appear when their own list
-  resolves rather than when a hidden sibling's did, and the tree's `doAction` clones instead
-  of mutating the caller's `UiAction`.
-
-### The form widget's rendering decisions (Phase 3.6)
-
-Nothing here needs a code change in a host — there is no API to adapt to. What
-changes is what the widget puts on the page, so read this before you compare
-screenshots.
-
-#### Every widget carried a spare empty wrapper; it is gone
-
-The `COMPONENT` branch's wrapper had no type guard, so
-`<div class="widgetContainer"><div class="widgetContent"><ng-template
-#customComponent>` rendered after **every** widget of every type. Measured on the
-playground: 14 widgets, 28 `.widgetContainer` — one spare, empty, per widget.
-
-The library's own CSS puts no box properties on `.widgetContainer`, so most pages
-will look identical. **Yours may not**, if you style that class with anything that
-occupies space. Both in-house hosts do, on one page:
-
-```css
-/* p014 + p043, dossier-publication.component.css */
-:host ::ng-deep .widgetContainer { margin-bottom: 0.5rem !important; }
-```
-
-There, every widget loses half a rem of trailing space. Grep your stylesheets for
-`.widgetContainer` and check the pages the matching selectors reach. Rules that
-need content still match what they always matched — an empty wrapper never
-satisfied `.label.widgetContainer` or `.widgetContainer:has(…)`.
-
-#### `MATRIX` and `YOUTUBE_PLAYER` now obey `isVisible` and get their `cssClass`
-
-Those two branches sat outside the `@if (isVisible)` guard and outside the
-`<div [ngClass]="cssClass" class="container">` every other type lives in, so
-`isVisible: false` did not hide them and `cssClass` never reached them. Both are
-inside now. If a backend view relies on a matrix rendering while marked invisible,
-it will stop rendering.
-
-#### A container keeps its invisible children
-
-A `CONTAINER` widget's `ngOnInit` used to overwrite `widgetInstance.valueList`
-with the visible subset, destroying the invisible children in the model the
-backend sent. The visible subset is derived per check now, so the model stays
-whole and a later `applyConstraints()` that flips a child's `isVisible` brings it
-back — which it could not before. The DOM is unchanged: the same children render.
-
-Side effect worth knowing: the model walks that recurse into a container's
-`valueList` (`applyComponentConstraints`, `copyValueFromFormToWidgetBeans`,
-`translateWidgets`) now see the invisible children too. Their form controls always
-existed — `createFormControls` runs over the whole model before any widget renders
-— so this only makes the widget beans agree with the controls.
-
-#### A YouTube shorts link resolves
-
-`parseYoutubeUrl` threw away its own `replace('/shorts/', '/watch?v=')`, so a
-shorts link produced no player. It plays now.
-
-#### Removed from the public API
-
-| Removed | Replacement |
-|---|---|
-| `SmartformwidgetComponent` | nothing — no host imported the class; `<smartform>` still renders it. 7.3 splits it into per-type components |
-| `SmartWidgetSettings` (its only member was `static useUtc`) | nothing — **delete the assignment** |
-
-3.6 moved the `useUtc` static into `SmartNgClientConfig.useUtcDates`; **3.8 then removed the
-field altogether**, together with the moment adapter it fed. If you set
-`SmartWidgetSettings.useUtc = true` before bootstrap, delete that line and read
-[Dates §4](#4-smartngclientconfiguseutcdates-is-removed) — the timezone contract is fixed now,
-and the flag defaulted to `false` everywhere anyway.
-
-#### What deliberately did not change
-
-A required field is marked in both label positions, by two different mechanisms:
-a shown label (`showLabel: true`) is the widget's own `<h4>` and carries a literal
-` *`; a `mat-label` sits inside a `mat-form-field`, which renders
-`.mat-mdc-form-field-required-marker` from the control's own validators. That is
-why `getWidgetLabel` ties its asterisk to `showLabel` — dropping the condition
-would mark the floating label twice.
-
-### Change detection: frozen action entries, no zone.js (Phase 3.7)
-
-7.0 runs without zone.js. Every component of the library is `OnPush` — nothing is checked
-just because something, somewhere, ticked — and the library says when its own state changed.
-Two consequences reach a host.
-
-#### A `UiActionModel` is frozen: build an entry, never edit one
-
-Every field is `readonly`, and `[uiActionModels]` takes `readonly UiActionModel[]`.
-
-```ts
-// before — compiles on 6.x, and on 7.0 changes nothing on screen
-entry.cssClass = 'active-nav-action';
-
-// after
-this.actions = this.actions.map((a) =>
-  a.uiAction.code === code ? { ...a, cssClass: 'active-nav-action' } : a
-);
-```
-
-Measured across the 12 hosts in scope (2026-07-28): **72 sites in 7 hosts**, all of them
-`cssClass` — p009-angular alone has 38, p014 and p043 12 each. The codemod prints every one
-of them with its line number; it cannot rewrite them, because only you know which array the
-entry belongs to.
-
-The compile error and the fix are the same thing. Writing into an entry that a toolbar is
-already rendering never reached the screen under zone.js either — it worked only because
-some other event happened to tick the application. Rebuilding the array is what actually
-re-renders.
-
-**The gap this does not close.** `this.actions[0] = { ...this.actions[0], cssClass: 'x' }`
-compiles: `actions` is your field, and the freeze only covers the entries. It keeps the same
-array reference, so the toolbar does not re-render. Reassign the array — or, if you hold it
-in a `signal`, `update()` it.
-
-**A component's own toolbar entries come from its `actionModels` signal.** The 6.x pattern
-`this.uiActionModels.forEach((a) => (a.cssClass = 'eji-button'))` in `initActions` becomes an
-override of that signal, which bound, pulled and layout-embedded toolbars all read:
-
-```ts
-// the helper runs while this.actionModels is still the base class's signal
-function withCssClass(component: SmartComponent<any>, cssClass: string) {
-  const source = component.actionModels;
-  return computed(() => source().map((a) => ({ ...a, cssClass })));
-}
-
-override readonly actionModels = withCssClass(this, 'eji-button');
-```
-
-Reading `this.actionModels` directly in its own initializer is `TS2729`; passing `this` to a
-function is what captures the base signal (p009-angular, `src/app/utils/action-css-class.ts`).
-A host field of its own named `actionModels` now collides with the base signal
-(`TS2416` + `TS4114`): rename it.
-
-When the mapping reads the component's data (mark the entry of `data.currentPage`), read
-`component.modelSignal()` inside the `computed` as well: `data` is a plain field, so without it
-the class does not follow a data change that leaves the action list alone (p034,
-`src/app/utils/action-models.ts`).
-
-The descriptor a toolbar resolves is no longer written back into the entry either. Nothing
-outside the toolbar read it; if you did, resolve it yourself through
-`UiActionDescriptorService.getActionDescriptor(uiAction)` — which is
-[synchronous in 7.0](#getactiondescriptor-is-synchronous-phase-39).
-
-#### Client-side translation is gone
-
-`SmartTranslateService`, `viewContext.translateService` and the `translateServiceChanged`
-subject are removed, together with `originalLabel` / `originalPlaceholder` on the widget
-interfaces, and the `translateService` field of `SmartForm`, `SmartGrid` and `SmartFilter`. The
-backend localizes server-side, and in p014/p043 the three references were unused imports.
-
-**A host that sends translation keys still needs translating.** p009-angular keeps ngx-translate
-keys in its client-built forms, its client action descriptors and its titles; deleting the
-calls would put raw keys on screen. It now translates in the host: the widget labels,
-placeholders, validator messages and item labels when a form is built, and the descriptor map
-on every `onLangChange`, with `bootstrap.start()` waiting for the language to load. **Grid
-column headers and filter labels have no host-side replacement**: they show what the backend
-sends, so localize them on the backend. A page that read `this.translate` without assigning it
-got `undefined` already on 6.x (the base class never set it), so check what a title showed
-before calling a now-translated one a regression.
-
-What the frontend authors itself is now configuration:
-
-```ts
-provideSmartNgClient({
-  errorDialog: { title: 'Hiba', message: 'Váratlan hiba történt.', buttonLabel: 'Rendben' },
-});
-```
-
-`SmartViewContextService.getSmartViewContextApiErrorByCode()` is no longer `async`.
-
-**`SmartComponent` no longer has a `translate` member**, and a host that injected
-ngx-translate's `TranslateService` under that name as `override translate: TranslateService`
-now gets `TS4113` on every such constructor (app-formmate had 22). Do not just delete
-`override`: it was also what made the parameter a property, so without an access modifier
-`this.translate` disappears. Write `public translate: TranslateService` — and keep `override`
-on subclasses of your own pages, which now override *your* base class instead of the library's.
-
-#### If your host still bootstraps with zone.js
-
-Nothing forces you to drop it — the library works either way, because it no longer depends
-on an application-wide tick. The playground runs `provideZonelessChangeDetection()` with no
-`zone.js` polyfill, and that is the configuration 7.0 is tested in.
-
-If you do go zoneless, the same rule applies to your own components: state written from a
-subscription, a promise or a timer needs a signal or a `markForCheck()`; state written from a
-template event or an input does not.
-
-### Dates: moment → date-fns, and the timezone contract (Phase 3.8)
-
-**This section needs action at install time.** The reasoning is ADR-0008 in the
-`platform-angular2` working copy; the contract itself is stated in §4 below.
-
-#### 1. Swap the peer dependency
-
-`@angular/material-moment-adapter` is out of the library's `peerDependencies`;
-`@angular/material-date-fns-adapter` and `date-fns` are in. `date-fns` is listed explicitly
-rather than left transitive, because the library imports `date-fns/locale` itself.
-
-```bash
-npm uninstall @angular/material-moment-adapter moment
-npm install @angular/material-date-fns-adapter@^22.0.0 date-fns@^4
-```
-
-If your own code imports moment for something unrelated, keep it — nothing here forces its
-removal, only the adapter's.
-
-**But check *how* it imports moment.** `import * as moment from 'moment'` stops being callable
-under `moduleResolution: "bundler"`, which the Angular 20 hop turns on: moment is an
-`export =` module, and a namespace import of one is not a callable value. The symptom is
-**`TS2349: This expression is not callable`** on every `moment(...)` call, and it arrives at the
-Angular 20 hop rather than at this step. Two ways out:
-
-- `esModuleInterop: true` plus `import moment from 'moment'` — correct, but it changes how every
-  CommonJS import in the app resolves, which is a wide blast radius for one file.
-- Replace the calls. Worth checking first how much moment is actually doing: in p014 the three
-  surviving calls were `moment(new Date()).toDate()` (i.e. `new Date()`) and two moments compared
-  with `<=` (`Date` compares through `valueOf()` identically). All three became plain `Date`s, and
-  **nothing under `src/` imported moment any more** — so the `npm uninstall … moment` above was
-  right for that host after all, just for a reason nobody predicted.
-
-#### 2. Leave your `MAT_DATE_LOCALE` provider alone
-
-If you have this line — p014 and p043 both do — **keep it as it is**:
-
-```ts
-{ provide: MAT_DATE_LOCALE, useValue: 'hu-HU' },
-```
-
-The strict reading of the date-fns adapter would require a `Locale` **object** here, and a bare
-string would throw inside date-fns the first time a user opened a date field. The library's
-`SmartDateFnsAdapter` accepts both: it resolves `'hu'` / `'hu-HU'` / `'en'` / `'en-US'`
-(case-insensitively) to a date-fns locale, passes a real `Locale` object through untouched, and
-falls back to Hungarian with a `console.warn` for anything else.
-
-So: **hosts on Hungarian or English need no change.** For any other language, provide a real
-date-fns locale:
-
-```ts
-import { de } from 'date-fns/locale';
-…
-{ provide: MAT_DATE_LOCALE, useValue: de },
-```
-
-`SmartNgClientConfig.dateLocale` is unchanged — still a `string`, still defaulting to `'hu-HU'`.
-
-#### 3. If you override `MAT_DATE_FORMATS`, your format strings will throw — and you probably want to delete the override
-
-Measured across 12 hosts on 2026-07-28: three of them (**p014**, **p043**, **p009-angular**)
-provide their own formats next to the locale, and two more (`app-vlab`, `app-tournament`) have the
-same line commented out:
-
-```ts
-{ provide: MAT_DATE_FORMATS, useValue: MY_FORMATS },
-```
-
-with
-
-```ts
-export const MY_FORMATS = {
-  parse:   { dateInput: 'YYYY.MM.DD' },
-  display: { dateInput: 'YYYY.MM.DD', monthYearLabel: 'YYYY',
-             dateA11yLabel: 'LL', monthYearA11yLabel: 'YYYY' },
-};
-```
-
-Those are **moment tokens**. date-fns treats `YYYY`, `DD`, `YY` and `D` as *protected* and throws a
-`RangeError` on them, and its `LL` means something else entirely (stand-alone month, not a
-localized long date). So this override **crashes at runtime, on the first screen with a date
-field** — the same failure shape as the string locale above, and just as invisible to the compiler.
-
-**The fix is almost certainly deletion.** That `MY_FORMATS` exists to render `YYYY.MM.DD`, which is
-exactly what the library's own `SMART_DATE_FORMATS` now produces (`2026.07.28.`). Drop the
-provider and the constant and you get the format you wanted, plus the more forgiving parsing.
-
-If you genuinely need a different format, translate the tokens rather than copying them:
-
-| moment | date-fns |
-|---|---|
-| `YYYY` | `yyyy` |
-| `DD` | `dd` |
-| `LL` | `PP` (or spell it out: `yyyy. MMMM d.`) |
-| `MMM YYYY` | `yyyy. LLL` |
-
-Note that the library's `parse.dateInput` is an **array** — `DateFnsAdapter._parse` tries each entry
-in turn (and ISO-8601 first), so you can list several accepted spellings instead of one.
-
-#### 4. `SmartNgClientConfig.useUtcDates` is removed
-
-Delete it if you set it. No known host does. It existed for a client-configurable timezone that
-was abandoned as a requirement; the contract is now fixed and explicit:
-
-> **The browser's zone on screen. Zulu (`…Z`) on the wire. The server converts.**
-
-This is unchanged behaviour in practice — `useUtcDates` defaulted to `false`, and the moment
-adapter with `useUtc: false` behaves exactly like a plain `Date`.
-
-#### 5. What a date widget's value now *is*
-
-Form control values from the date pickers are plain **`Date`** objects, where they were
-`Moment` objects. The values reach your backend through a `UiActionRequest` param, so the wire
-format is `JSON.stringify` of that value — and `Date.toJSON()` emits the same ISO-8601 UTC string
-`Moment.toJSON()` did. **Nothing changes on the wire.** Only host code that read a value out of a
-form control and called a moment method on it (`.format()`, `.add()`, `.startOf()`) needs
-rewriting; the platform APIs never exposed a `Moment` in a signature.
-
-#### 6. The one visible difference
-
-Date inputs render **`2026.07.28.`** where 6.x rendered `2026.7.28.` — the documented `YYYY.MM.DD`
-convention. The old rendering was not a decision: `MAT_MOMENT_DATE_FORMATS` used moment's `'l'`,
-which strips the zero padding off the Hungarian `L`. Typed input is **more** forgiving than 6.x,
-not less: `2026.07.28.`, `2026.07.28`, `2026.7.28.`, `2026.7.28` and ISO-8601 are all accepted.
-
-The month picker is unchanged (`07/2026`), and grid/table date columns were never affected —
-`SmartDatePipe` and friends extend Angular's own `DatePipe` and never used moment.
-
-**Verified on a running host** (p014, 2026-07-29, live backend, `Europe/Budapest`). Picking
-2026-07-15 in a `Kezdődátum` field gave, end to end:
-
-| | |
-|---|---|
-| input | `2026.07.15.` |
-| widget value | `instanceof Date` — not a moment, not a luxon `DateTime` |
-| `JSON.stringify` of that value | `"2026-07-14T22:00:00.000Z"` |
-| `getHours()` | `0` |
-
-That third row is the whole contract in one line: the value's `toJSON()` **is** the wire format
-(see §4), and it is zulu, while the screen and `getHours()` stay local — 15 July 00:00 CEST is
-14 July 22:00 UTC. A grid column on the same host rendered `2026.04.20 0:03`, confirming the
-untouched pipe path.
-
-### HTTP: the library no longer forces the XHR backend (Phase 3.8)
-
-`provideSmartNgClient()` used to pass `withXhr()` to its internal `provideHttpClient()` call,
-overriding the Angular 22 default on your behalf. It no longer does — the application runs on the
-framework default **fetch** backend.
-
-For almost every host this is invisible. The one behavioural difference that matters: **the fetch
-backend does not support upload progress.** A request with `reportProgress: true` and a body
-throws `NG2824` instead of emitting `HttpUploadProgress` events.
-
-Measured 2026-07-28 across 12 hosts: **`reportProgress: true` and `observe: 'events'` appear
-nowhere** outside the generated API services' unused parameters. So this is a theoretical risk for
-the current host set, not a live one. If *your* code does ask for upload progress, pass the
-feature back in:
-
-```ts
-import { withXhr } from '@angular/common/http';
-
-provideSmartNgClient({ httpFeatures: [withXhr()] })
-```
-
-The upside is that the "**do not call `provideHttpClient()` twice**" trap this guide warned about
-is gone rather than merely documented: a second call now re-provides the same backend the library
-already uses. The library's interceptors were never at risk from it — they are `multi` providers.
-
-### `getActionDescriptor()` is synchronous (Phase 3.9)
-
-`UiActionDescriptorService.getActionDescriptor(uiAction)` returns a `UiActionDescriptor`.
-It used to return a `Promise<UiActionDescriptor>`, and it was `async` for exactly one
-reason: the client-side translation layer that [Phase 3.7](#client-side-translation-is-gone)
-retired. Nothing it reads has been asynchronous since, so every caller was awaiting a value
-that was already there.
-
-**If you only `await` the call, you are already fine.** `await` on a non-promise is legal
-TypeScript, so this compiles and behaves identically before and after. The codemod drops the
-`await` anyway, so the code stops claiming an asynchrony that is not there:
-
-```ts
-const descriptor = await this.uiActionDescriptor.getActionDescriptor(uiAction);   // 6.x
-const descriptor = this.uiActionDescriptor.getActionDescriptor(uiAction);         // 7.0
-```
-
-Two shapes genuinely break. Measured 2026-07-28 across the 12 hosts in scope: **5 hosts,
-7 sites** — and none of them in a host's own `getActionDescriptor**s**()` map helper, which
-is an unrelated API and is left alone.
-
-**1. A subclass that overrides it** — `TS2416`, because `Promise<UiActionDescriptor>` is not
-assignable to `UiActionDescriptor`. Found in three hosts, as a byte-identical
-`MdmUiActionDescriptorService`. **The codemod rewrites this one.**
-
-```ts
-// 6.x
-override async getActionDescriptor(uiAction: UiAction): Promise<UiActionDescriptor> {
-  let d: UiActionDescriptor = await super.getActionDescriptor(basicUiAction);
-  …
-}
-
-// 7.0
-override getActionDescriptor(uiAction: UiAction): UiActionDescriptor {
-  let d: UiActionDescriptor = super.getActionDescriptor(basicUiAction);
-  …
-}
-```
-
-This is also the service you hand to a toolbar through `[uiActionDescriptorService]`, so a
-host with a custom one hits this at compile time rather than on screen.
-
-**2. `.then(…)` on the result** — `TS2339`, because a descriptor has no `.then`. Found in
-two hosts, four sites. **The codemod reports this one and does not rewrite it**: turning a
-callback into straight-line code means moving its body, which is a judgment call. The fix is
-mechanical anyway — assign, then inline:
-
-```ts
-// 6.x
-constructForm() {
-  this.actionDescriptorService.getActionDescriptor(this.uiAction).then((d) => {
-    this.buttonTitle = d.title;
-    this.buttonColor = d.color;
-  });
-  …
-}
-
-// 7.0
-constructForm() {
-  const d = this.actionDescriptorService.getActionDescriptor(this.uiAction);
-  this.buttonTitle = d.title;
-  this.buttonColor = d.color;
-  …
-}
-```
-
-If the callback was the reason a field lived in a `signal` — because the value arrived after
-the first render — it no longer needs to. The library made that same simplification in its
-own three action dialogs and its snack bar.
-
-**What went synchronous with it, inside the library:** the toolbar's descriptor resolution,
-`SmartGridComponent`'s header construction, and `SmartTreeGenericService.cacheActionDesciptors()`
-and **`syncTree()`**. `syncTree()` now returns `void`, which is what
-`SmartTreeServiceInterface` always declared; a host that calls it and discards the result —
-the only shape measured — needs no change, and a host that `await`s it still compiles.
-
-#### The same cleanup, elsewhere: `SmartdialogService.closeDialog()` returns `void`
-
-A sweep for the same shape found eight more library functions declared `async` with nothing
-asynchronous in them. Only one of them is on a surface a host touches:
-**`SmartdialogService.closeDialog(stopPropagate?)` returns `void`** instead of
-`Promise<void>`.
-
-**Nothing to do.** Both measured hosts that extend `SmartdialogService` override this method
-as `override async closeDialog(): Promise<void>`, and that **still compiles**: TypeScript
-accepts any return type where the base declares `void`. `await this.closeDialog()` keeps
-compiling too. This is the difference from `getActionDescriptor` above — that one returns a
-*value*, which is why the same override shape fails there with `TS2416` and not here.
-
-You may of course drop the `async` from your own override; nothing requires it.
-
-### Upload actions now wait for the server, and report their failures (Phase 3.9)
-
-**This one changes behaviour, on purpose.** `SmartViewContextService.performUploadAction()`
-and `performUploadMultipleAction()` used to start the upload and resolve immediately,
-without waiting for it and without passing on its failure. Every other action in the family
-(`performAction`, `performWidgetAction`, `performWidgetMainAction`, `dataChanged`) always
-waited; the two upload ones were an omission.
-
-Two things follow, and both are visible in a running app:
-
-1. **An upload action now blocks until the server has answered.** Before, the action was
-   "done" the moment the request went out — so `UiActionService` showed its success snackbar
-   over an upload that was still in flight, and anything the action was sequenced before ran
-   against a view the server had not updated yet. Now the snackbar appears when the upload
-   really has succeeded. On a large file that is a longer wait than 6.x showed you.
-
-2. **A failed upload now reaches your error handling.** The rejection used to be dropped —
-   it became an unhandled promise rejection, `UiActionService`'s `catch` never ran, and the
-   user was told the upload had worked. It now propagates, which means
-   `setActionErrorHandler()` (or the default error dialog) will fire on upload failures it
-   never fired on before. **If your host reports "new" upload errors after upgrading, they
-   are not new** — they were happening silently.
-
-Multi-file uploads also go out **one batch at a time** now. The batches were already being
-computed from the descriptor's `maxSize` and `maxBatchSize`, but they were then all sent at
-once, which put the whole set on the server simultaneously and defeated the split. If your
-backend measured upload concurrency, this is why it drops.
-
-Nothing to change in host code.
-
-### New in 7.0: a grid row can render a backend layout (#29717)
-
-A card-mode grid row that carries `layoutDescriptor.componentLayouts['GRID_ROW_LAYOUT']`
-renders that layout instead of the card component the host registered under
-`'<GRID_ID>Card'`. Both branches stay: a row without the descriptor behaves exactly as
-before, and this needs no host change.
-
-Two consequences worth knowing if you style or extend it:
-
-- The rendered layout's root element gets the `gridCardLayout` class, applied by the card to
-  its own child rather than pushed into the `style.classesToAdd` of the object the backend
-  sent. Nothing mutates the server model.
-- **The row's actions reach the layout's toolbars by a pull, not a walk.** The card provides
-  a `SmartActionHost` for its row subtree and writes the row's action list into it; a toolbar
-  inside the layout resolves that host before falling back to the page client. If you build
-  a component that owns such a subtree, do the same — `WIDGETS.md`, *Toolbars*.
-
-This shipped in 7.0.0 rather than as a 6.0.3x patch because it is built on the inverted
-widget contract that 7.0 introduces.
-
-### Table detail rows: rendered on demand, `example-*` classes renamed (7.0.10)
-
-The Material table used to define its expandable detail row the way the Angular Material
-example does: a second `matRowDef` rendered under **every** data row, kept at zero height
-with `tr.example-detail-row { height: 0 }` and an `@angular/animations` trigger. Any host
-rule that gave table cells vertical padding, or rows a height, made those empty rows visible
-— the p043 report — and every table carried twice its rows in the DOM.
-
-Now the detail row exists only in an expandable table (`SmartTable.expandable`), and only
-under the row that is expanded. There is nothing a host stylesheet can inflate. Expanding
-and collapsing animate through the native `animate.enter` / `animate.leave` of Angular 20.2+
-(a `grid-template-rows: 0fr ↔ 1fr` keyframe, as `mat-expansion-panel` does it), so the table
-no longer uses `@angular/animations` at all.
-
-The classes lost their `example-` prefix, taken over from the Material sample:
-
-| 6.x | 7.0.10 |
-|---|---|
-| `example-element-row` | `smart-table-row` |
-| `example-expanded-row` | `smart-table-row-expanded` |
-| `example-detail-row` | `smart-table-detail-row` |
-| `example-element-detail` | `smart-table-detail` |
-
-`.example-element-diagram`, `-symbol`, `-description` and `-description-attribution` — the
-sample's own styles, referenced by nothing — are gone.
-
-What to do in a host:
-
-- Rename the classes in any stylesheet that targets them. The usual suspects are a hover
-  rule on `tr.example-element-row:not(.example-expanded-row)` and a
-  `:host ::ng-deep tr.example-detail-row { display: table-row !important }` in a page that
-  expands rows; the latter can simply be deleted, the row is rendered when it is needed.
-- A data row now carries its own bottom border. Before, the always-present detail row drew
-  it, and the data row's border was turned off to avoid a double line. Nothing changes on
-  screen unless you drew your own row separators to compensate.
-
-### Writing your own widget
-
-`WIDGETS.md`, next to this file, is the protocol: how a widget finds its screen component
-through DI and registers itself, when to opt out with `[smartComponentDetached]`, what has to
-be a signal now that there is no zone, how a toolbar resolves its actions, and the three
-traps that have actually bitten (imperatively-fed inputs cannot be signal inputs; `@for`
-tracking over backend objects; clear-then-apply styling).
-
-In 6.x this was not possible at all — `SmartComponentApiClient` collected its children with
-eight `@ViewChildren` over eight concrete widget classes.
-
-### Imperatively created components are given their inputs properly
-
-`ComponentFactoryService` creates the components the library instantiates by hand — grid
-cards, expanded rows, table cell components, the expandable section's content, the form's
-`COMPONENT` widget, the filter editor's field editors — and most of those classes come from a
-host. It used to write their inputs by assigning the field. Two things follow, and both are
-fixed:
-
-- **A declared input is now written with `ref.setInput()`**, i.e. the same way a template
-  binding writes it. So a **signal input** works (assignment used to overwrite the input
-  function with the value, and the component's next `this.x()` threw `x is not a function`),
-  an **aliased** input is addressable under either name, and **`ngOnChanges` runs**.
-- **Falsy values arrive.** The old guard was `if (value)`, so `false`, `0` and `''` never
-  reached the component. Only `undefined` is skipped now, which keeps meaning "not passed".
-
-If your component takes something from the library this way and the key is **not** a declared
-input, the field is still assigned — nothing breaks — but you get one `console.warn` per
-component type and key. Declaring it with `@Input()` (or as a signal input) is the fix.
-
-**Check your falsy defaults.** If a host component relied on the old guard — expecting to
-keep its own default when the library passed `false` or `''` — it now receives the value.
-This is the only part of 7.0 where a bugfix can change what you see on screen without any
-code of yours changing.
-
-### Model sync: the client's models travel with every call (7.1.0)
-
-Whether an action carried the page model used to be a per-action decision of the backend
-(`UiAction.submit` / `model` / `composite`) plus one hidden rule (an action with no params sent
-it anyway), and the model travelled under three ad-hoc `params` keys (`model`, `clientPageModel`,
-`compositeModel`) that only one endpoint wrote into the backend view automatically. The bug that
-forced the change: an action on an embedded view sent only its own model, the handler changed the
-container's model, the container's whole component model came back, and whatever the user had
-typed into the container since the last round-trip was gone.
-
-From 7.1.0 the client sends, with **every** action, widget action, upload and grid selection
-call, the data of **every open view that changed since it was last synced** — slot-hosted and
-dialog views alike — in a new `UiActionRequest.modelSync.models` map keyed by view uuid. The
-backend writes each one into the matching view **before the handler runs and before it takes the
-base of its change push**, so a handler always sees what is on screen and the client's own values
-are never echoed back. A view equal to its last synced copy is left out; a view without a copy is
-always sent.
-
-**Backend minimum, and the server switch.** The platform build that ships
-`UiActionRequest.modelSync` (platform ADR-0011 on the server side), **with model sync switched
-on**: `view.model-sync.enabled=true` in the host's `application.properties`. The switch defaults
-to `false`, and in that mode the server behaves exactly as before model sync existed: nothing is
-written into the views before the handler, and a request that carries `modelSync` is **rejected**
-with an error naming the property, not ignored. A 7.1.0 client sends the envelope with every
-call, so against a server with the switch off every call fails loudly; against an older platform
-the field is silently ignored and every handler that read `params.model` sees nothing. **Order:
-upgrade the backend, set the flag, then upgrade the client.** Server code can read the mode as
-`viewApi.isModelSyncEnabled()`.
-
-**A 6.x client against a backend with the switch on** is rejected too: with
-`view.model-sync.enabled=true` every request that can carry `modelSync` — an action, a widget or
-upload action, a tree action, a grid selection change — must carry it, and one without it (an
-old client, or host code that builds a `UiActionRequest` by hand and calls the view context
-service directly) gets an error saying so. A call that cannot carry it (loading a view, a
-message result, expanding a tree node, a map interaction) is neither synced nor refused. The old `params.model` / `clientPageModel` / `compositeModel`
-keys are never read as a sync source; they are only *filled* by the backend, see below. So the
-switch and the client upgrade go together per host: flip the flag in the same deploy that ships
-the 7.1.0 client. Internal Java callers with nothing to sync send an empty `new ModelSync()`.
-
-#### What changed on the client
-
-- `UiAction.model` and `UiAction.composite` are **deprecated no-ops** for a view's own actions.
-  `submit` keeps one meaning: validate before sending, the embedded views' forms included. For an
-  executor that is not a view (a tree, the filter editor) `model` still flushes its form and its
-  model still rides on `params.model` as before, because it has no view to sync.
-- Forms are flushed into their data (`submitForm(false)`) on every open view before a call, so an
-  unsaved field value is part of what is compared and sent. **Only the user's edits are
-  flushed**: the form remembers, per control, the value it last exchanged with the data (built
-  or refreshed from it, or written into it), and a control still equal to that writes nothing.
-  This is what keeps an untouched `false` or `0` from turning into `''` on a round trip (the
-  control is now built with `value ?? ''`, and a value written back takes the type the field has
-  in the data: `'true'` → `true`, `'12'` → `12`, `''` → `null`), and a backend push from
-  reaching the data only to be overwritten by the control's stale value on the next call. The
-  same rule the other way: a data field the backend changed reaches its control even when the
-  user edited it (the backend wins on a field it changed), a field it did not change keeps what
-  the user typed. `SmartFormService.resetExchangedValues()` starts over when a form is rebuilt.
-  The form's own dirty flag is not involved: it lives until the form is rebuilt and says nothing
-  about what the data holds.
-- A push of some `data.*` paths marks only those paths as synced; whatever else the view holds
-  keeps its standing, so a value written into the data outside a form while a call was in flight
-  is still sent by the next one. A whole-model push and the initial load mark all of it.
-- Calls run concurrently, and an envelope built earlier may complete later: its copies are never
-  written over the copies a later envelope or push already settled. The server-side ordering of
-  rapid per-field actions stays out of scope (ADR-0010).
-- A dialog the backend closed (`ViewState.TO_CLOSE`) no longer fires a `DEFAULT_CLOSE` action of
-  its own on top of the response that closed it; only the user's own close does.
-- The per-field actions a widget's `valueChangeMode` fires are ordinary actions and inherit the
-  sync; they no longer set `model: true`, and still carry `params.item`.
-
-#### Removed from the public API
-
-| Gone | What to do |
-|---|---|
-| `SmartComponentApiClient.sendModelOnWidgetAction` | Delete the assignment. Every widget action carries the changed models now. Loud: `this.sendModelOnWidgetAction = true` no longer compiles. |
-| `SmartComponentApiClient.addModelToWidgetParams()` / `addModelToWidgetAction()` | Delete. The grid service builds its own envelope. |
-| `SmartViewContextService.getCompositeModel()` | Delete. The backend gets every changed view. |
-| `SmartViewContextService.submitEmbeddedForms()` | `validateEmbeddedForms(containerUuid)` — validation only; the flush is part of every call. |
-| `SmartViewContextService.dataChanged()` | Delete. It was never wired on the client (`handleValueChanges` had no caller); a field change is a uiAction. |
-
-New on `SmartViewContextService`: `joinModelSync(uuid, participant)` / `leaveModelSync(uuid,
-participant)` (the client does this on its own uuid; leaving only takes effect for the participant
-that is registered, so a component destroyed after its successor joined under the same uuid does
-not take the successor with it), `markModelSynced(uuid, keys?)` (the client calls it whenever the
-backend's model reached it: without keys the whole data, with keys the pushed `data` paths), and `withModelSync(carrier, call)` for a host that issues its own backend call on a request
-that can carry the envelope (a `UiActionRequest`, a `GridSelectionChange`): it puts the envelope
-on the carrier, runs the call with it and settles the copies on success, and hands back the raw
-`ViewContextChange` — what to do with the response stays with the caller. The grid and tree
-services are the in-tree examples; `beginModelSync()` / `completeModelSync()` underneath are
-public too.
-
-#### The Java side of the host: three kinds of handler
-
-The backend **backfills** the old `params` keys from the synced model on every request (with the
-switch on, every request carries `modelSync`), so no handler has to change on the day the client
-is upgraded. Two kinds must be
-looked at anyway, and one of them breaks without a compiler error. Run
-`node tools/model-sync-audit/cli.mjs ../<host>` — it lists every read of the request model with
-one of these categories and a reason ([its README](../../tools/model-sync-audit/README.md)):
-
-| | The handler | What to do |
-|---|---|---|
-| **A** | reads `params.model` (`extractClientModel(request)`, `actionRequestHelper(request).get(UiActions.MODEL, …)`) and only passes it to `setModel(viewUuid, …)` | Delete both statements. The sync already wrote the client's model into the view. |
-| **B** | reads it for something else: saves it, validates it, forwards it, mutates it before setting it back | Nothing required. `getModel(viewUuid)` is the honest read now; `extractClientModel` is `@Deprecated`. A grid row action's `params.model` is still the clicked row and is never synced. |
-| **C** | reads the view's model too (`getModel(viewUuid)`, `view.getModel()`) and uses the two together — a diff, a merge, "what changed" | **Breaks silently.** After the sync `getModel` *is* the client's model, so the comparison compares a thing with itself. The server-side read must become `viewApi.isModelSyncEnabled() ? getPreviousModel(viewUuid) : getModel(viewUuid)`: the model as the server knew it before this call, request-scoped (`viewApi.getPreviousModel(uuid, Class)` outside a `PageApiImpl`). The off branch is the old code. |
-
-A handler that must work in both server modes — a shared module deployed to hosts with the
-switch off as well as on — branches inline on `viewApi.isModelSyncEnabled()` and keeps its old
-code verbatim in the off branch: an A site becomes
-`if (!viewApi.isModelSyncEnabled()) { setModel(viewUuid, extractClientModel(request)); }`, a
-client read `viewApi.isModelSyncEnabled() ? getModel(viewUuid) : extractClientModel(request)`, a
-C site's server read the ternary above. No wrapper helper on purpose: once every host runs with
-the switch on, the off branches are deleted line by line and what remains is the plain new code.
-The platform's own handlers are written this way. `getPreviousModel` with the switch off returns
-`getModel` and logs an ERROR: that code assumes a mode the server is not running in.
-
-Two traps the audit cannot see:
-
-- A handler that forwards the *request* to a callback which reads `params.model` (the platform's
-  password editor does this) depends on `extractClientModel` writing the typed instance back into
-  the params. Keep `extractClientModel` there, or hand the model over explicitly.
-- A handler that reads `compositeModel` by hand gets it backfilled only when its action still
-  has `composite=true`. Read the children's models from `viewApi` instead; the flag goes away
-  once no host reads the key.
-
-The measured spread, over the 56 host repositories that were audited when this shipped: 1061 read
-sites, 301 A, 671 B, 77 C.
-
-### New in 7.2: HTML widget, row layouts, hydrated toolbars (#30388)
-
-Additive, with **one behaviour change** and one removed field. The reference is
-`HTML-WIDGET.md`, shipped in the package next to this file.
-
-- **`SmartFormWidgetType.HTML`**: server-sent html whose client placeholders (`{{…}}`) the client
-  resolves against the model, with toolbars hydrated into its toolbar slots
-  (`<smart-ui-action-toolbar data-sb4-toolbar="…">`) and action triggers (`data-sb4-action`) on
-  any element. The `DIV` widget is untouched. A host that never sends the widget sees no change.
-  The widget can bring its own style sheet (`HtmlProperties.css`), which the client adds to the
-  document head once per distinct text; a host with a nonce-based `style-src` provides
-  Angular's `CSP_NONCE`. A style sheet can animate new html coming in and, through the
-  `sb4-html-leaving` class the client puts on the widget or cell before it replaces the html,
-  going out.
-  Inside a `{{#section}}` a placeholder reads the surrounding scope only when it says so,
-  `{{../title}}`: one step per entering section, never above the widget's root.
-- **Icon slots (in the tree, released after 7.2.4)**: an element in the html marked with
-  `data-sb4-icon` hydrates into a
-  `smart-icon` — the same component a button or a cell uses. The marker addresses a name
-  (`data-sb4-icon="mail"`, coloured by `data-sb4-icon-color`, a theme or host class name), an
-  `ImageResource` (a placeholder that resolves to one, or the json `Tag.icon(resource)` writes
-  in), or a key of the template's icon dictionary (`data-sb4-icon-key`,
-  `HtmlProperties.icons`), which sends a finite type-to-icon mapping once with the template
-  rather than once per row. An address that resolves to nothing renders no icon and says
-  nothing; an unknown dictionary key warns. Nothing changes for a host that sends no icon slot.
-- **Row layouts**: a cards grid can carry its card layouts once per grid
-  (`GridViewDescriptor.rowLayouts`, picked per row by `GridRow.rowLayout`) instead of once per
-  row. The per-row `layoutDescriptor.GRID_ROW_LAYOUT` still works and wins over them; a
-  host-registered `'<GRID_ID>Card'` component still renders the rows that get no layout.
-- **Clicking a card rendered from a layout — 7.2.0 changed it, 7.2.1 takes the change back.**
-  7.2.0 made a click select the row and moved the default row action to the double click. That
-  broke `mod-contact`'s contact list, and a cards grid naming no `selectionMode` lost its click
-  altogether. **From 7.2.1 a card behaves as in 7.1.x again unless the server says otherwise**: a
-  click fires the row's first applicable default action, and nothing is selected by click while
-  the click belongs to the default action. A host that put a root trigger on its cards for 7.2.0
-  can keep it; it is no longer needed.
-- **`GridViewDescriptor.defaultRowActionTrigger` (7.2.1, `click` | `doubleClick`)** makes the
-  gesture data, so a cards grid is programmed like a table: `selectionMode` decides whether rows
-  are selectable, the trigger decides what fires the default row action. With `doubleClick` a
-  click selects the card and a double click fires the default action, as on a `ROW_SELECT` table.
-  With an explicit trigger several applicable default actions open a menu at the pointer, filtered
-  to what the row offers. Without a value a card keeps the click and a table the double click; in
-  7.2 a table fires on double click whatever the value is (7.3 honours an explicit `click`, see
-  below). The second click of a double click is not a
-  click of its own on a card: it neither fires the default action again nor toggles the selection
-  back, and further clicks are dropped while the default action runs. Needs a platform that knows
-  the field; an older client ignores it.
-- **The double-click menu of a table works again.** A grid row offering several of the grid's
-  `defaultRowActions` opens a menu at the pointer on double click. The position override behind it
-  had been written for an older Material signature and threw on open, so until 7.2.1 such a double
-  click did nothing.
-- **`SmartGrid.layoutComponent` is removed.** The card gets the layout class through the
-  `SMART_ROW_LAYOUT_COMPONENT` token that `provideSmartNgClient()` provides, so a cards grid a
-  host builds with `addGrid()` renders backend layouts too. Delete the field if a host grid model
-  sets it; nothing else changes.
-- A toolbar no longer lets a `dblclick` on its buttons through to the element around it (it
-  already kept the `click`).
-- The toolbar's re-entry guard is per action now: while one action runs, another button of the
-  same toolbar can be fired. It is also released when the action fails.
-- **Trusted Types**: the HTML widget writes backend-authored html as it is, as the `DIV` widget
-  always has. A host that enforces Trusted Types must allow that write.
-- **Table cells**: `GridColumnMeta.contentType` now reaches the table. A column that names none
-  (or `html`) renders exactly as before, sanitized; `text` escapes the value. A column with
-  `htmlProperties` renders a column template — the HTML widget's dialect, resolved per row, with
-  toolbar slots and triggers offering the row's actions. A row action addressed to
-  `UiActions.NO_TOOLBAR` no longer shows in the row menu; in a table with column templates no row
-  action addressed to a toolbar does.
-
-### New in 7.3: object navigation and editing screens (#23616)
-
-Additive for a host that uses the components as they are, with **visible style changes in every
-host**; a host that calls `TreeService.selectNode2` or extends `Table` has source changes (see
-"Source changes" at the end of this section). Needs the matching platform (`TreeSelectionRequest`,
-`ViewContext.sequence`); release the two together. With an older platform the edits a tree
-selection carried are not sent again and late responses are always applied.
-
-- **Theme token defaults.** The first `ThemeService` (every host has one through
-  `SmartViewContextService`) puts a `<style id="sb4-theme-defaults">` first in `<head>`: light
-  values of the library's tokens on `:root`, dark values under `.theme-dark`. Tokens a host sets
-  on `body` or `:root` win; tokens set on `html { }` do not, so move them to `body`. The defaults
-  cover 14 tokens (`--color-surface(-alt)`, `--color-text(-muted)`, `--color-border`,
-  `--primary / secondary / accent / warn / success / warning / info-color`,
-  `--primary-text-color`, `--tree-active-color`). The optional tokens the library also reads
-  (`--tree-active-background`, `--grid-open-row-background`, `--grid-open-row-bar`,
-  `--primary-light-color` and the other old names below) get no default and fall back where they
-  are read, for example `--tree-active-background` to `--accent-color`. A token the host never
-  defined now has a value, for example `--tree-active-color: #ffffff`. A host with a
-  nonce-based `style-src` provides Angular's `CSP_NONCE`, which the element then carries.
-- **Dark defaults** stand under `.theme-dark` only (with `color-scheme: dark`), so they apply
-  only when the host offers a theme named `dark`. A host that sets its light tokens on a plain
-  `body` hides them and ships its dark theme with the full token set.
-- **Components read the theme tokens.** The menus, action buttons, tables, the mobile table and
-  the grid take their colours from `--color-surface`, `--color-surface-alt`, `--color-text`,
-  `--color-text-muted`, `--color-border`, `--primary-color` and `--primary-text-color` instead of
-  fixed values. A host without these tokens sees the defaults above, which are close to, but not
-  exactly, the old colours (menu text `black` → `#132033`, disabled `#aaa` → `#68778e`, table
-  hover `whitesmoke` → `#f4f6fb`). The old names `--primary-light-color` (selected table row),
-  `--disabled` (disabled row), `--light-gray` (grid edit icon), `--mat-sys-primary` (selected
-  card outline) and `--primary-color-text` (activated view button) are still honoured before the
-  new ones. The grid overlay uses relative colour syntax (`rgb(from …)`, Chrome 119 / Safari
-  16.4 / Firefox 128), inside Angular 22's browser floor.
-- **Row states.** `GridRow.rowState` is rendered as the row class `sm-grid-row-<state>`
-  (`new`, `modified`, `deleted`, `moved`, `contains-change`, or an application code in lower
-  case) on table, mobile-table and card rows, with default styles: new green italic, modified
-  accent bold, deleted muted with struck-through cell text (`.smart-table-cell-text`), moved
-  italic, contains-change the accent colour only. A card only takes the colour: a deleted card is
-  muted, nothing is struck through. A selected row keeps its normal text colour. Any grid whose
-  server already fills `rowState` shows them.
-- **Row state column.** `GridViewDescriptor.rowStateDisplay` (`GridRowStateDisplay`) picks how a
-  table and a mobile table show the states: `STYLE` (the default when absent) the row classes
-  above, `COLUMN` a first column of state icons without the row classes, `BOTH` the two
-  together. The column shows an icon for the platform states (an application state has none),
-  with the tooltip and accessible name from `rowStateLabels` (by state code); the column itself is
-  named by `rowStateColumnLabel` and has no header text. It is not a descriptor column: not
-  editable, not in the column chooser. The platform fills both labels in the session's locale.
-  A cards grid has no column and keeps the row classes whatever the value.
-- **Mark of the open row.** A grid whose `GridViewDescriptor.markOpenRow` is true gives the row
-  of `GridPage.openRowId` the class `sm-grid-row-open` (table and mobile table): a light accent
-  tint and a bar at the row's start, restyled by `--grid-open-row-background` and
-  `--grid-open-row-bar`. A default row action, from a double click, a click or the row menu, moves
-  the mark at once; a grid page requested before the action's answer keeps the new mark, the first
-  one requested after it brings the server's `openRowId`.
-- **`defaultRowActionTrigger: click` on a table.** A table now honours an explicit `click`: a click
-  on a row with an applicable default action fires it (several open the menu at the pointer), does
-  not select the row, and a double click does nothing more. A click on a button, link or input in
-  the row stays the control's own. Without a value or with `doubleClick` nothing changes. Table
-  rows are tracked by their id, so a reloaded row keeps its elements.
-- **Tree grid controls.** The header of a TREE_GRID shows expand all / expand level / collapse
-  level / collapse all as small icon buttons, disabled when there is nothing to do. The server
-  picks and orders them with `GridViewDescriptor.treeGridControls` (`TreeGridControl`): absent or
-  null shows all four, `[]` none (before: two mini-fab buttons).
-- **Trees.**
-  - A tree reload keeps the node objects of the nodes it still has and writes the new data
-    into them. Rows survive a reload, a click that started before it still lands, and
-    `smartTreeModelChanged` fires once per reload (before: twice, first empty).
-  - A node keeps the icon the backend sends; a node without one gets `Folders` if the host
-    registered it, Material `folder` otherwise (before: always `Folders`).
-  - A node action with its own `descriptor.title` is labelled by it.
-  - The caption shows the short description as a tooltip.
-  - Without a `[treeStyle]` a row is indented 15px per level and the selected row gets
-    `sm-tree-node-selected` (`--tree-active-background`, else `--accent-color` /
-    `--tree-active-color`); its caption and short description take the colour with
-    `color: inherit`, so a host rule on every element (`* { color: … }`) does not reach them.
-    With a `treeStyle` nothing changes.
-  - Server classes `sm-tree-branch-new|modified|deleted|foreign|own-other-view-context` have
-    default styles.
-- **Tree selection syncs the models.** Selecting a tree node sends the client's changed models
-  like an action does (`TreeSelectionRequest.modelSync`). Needs the matching platform:
-  an older one ignores the body and the edits it carried are not sent again.
-- **Tree widgets in a server layout** provision their own tree service from the widget
-  identifier when the screen's default tree is a different one or there is none, so a generic
-  page can show a tree and a layout can hold several.
-- **Late responses.** The server raises `ViewContext.sequence` on every save of the view
-  context; the response of an action or of a tree selection whose view context is not newer
-  than the one the client holds no longer overwrites it, its changes are still applied. Needs
-  the matching platform: an older platform sends no sequence and its responses are always
-  applied. Such a response first waits for the view-context updates the client still has in
-  flight, and their answers count in the comparison (they are applied as before, without the
-  guard). A response that is not applied still closes the views it marks `TO_CLOSE`.
-- **Views entering a slot.** When one response closes an embedded view and opens another in
-  the same slot, the two are exchanged in one step: the old component stays (inert, cut off
-  from the server) until the new one has its model, at most 3 s. Every view opened into a slot
-  of a server layout likewise stays hidden until its model arrives, so the layout beside it
-  changes once. Showing such a view fires one `window` `resize` event, so content that measured
-  itself while hidden (textarea autosize, scrolling toolbars) measures again.
-- **Empty slots.** An embedded slot of a layout that shows no view carries `sm-slot-empty`; an
-  empty `sm-nav-pane` takes no width, so the list beside it has the full width.
-- **Focus after a pane closes.** When the view of an `sm-nav-pane` closes and the focus went
-  with it, the focus moves to the open row (`sm-grid-row-open`) of the `sm-nav-list` beside the
-  pane, else to the row that was open while the pane showed the view, else to the list.
-- **Navigation frame styles.** Default layout for the server classes `sm-nav-view`,
-  `sm-nav-pane`, `sm-nav-list`, `sm-nav-header`, `sm-nav-caption`, `sm-nav-section(-title)`,
-  `sm-nav-tree`, `sm-nav-slot`, `sm-nav-crumbs`, `sm-crumb-ahead`, `sm-crumb-current`; a host may
-  restyle them by the same names. `sm-nav-header` puts the caption of a pane view and the toolbar
-  with the pane's close on one line. Inside `.sm-nav-list` a grid toolbar without a button is
-  hidden and the grid has no top padding; the search page container has a 0.5rem gap there.
-- **Icon buttons** get an `aria-label`: the action's title, else its tooltip. A button that shows
-  its title is named by it and gets none.
-- **Row actions in a table's action column** stand side by side; the toolbar no longer wraps
-  in the narrow column (row actions the server shows as icons).
-- **Prerendered pages.** A page shown after browser prerendering keeps its view context uuid
-  (sessionStorage written during prerendering is dropped; the client restores it from the request
-  header), so a tree on it loads its nodes.
-- **Search page title**: `.search-page-title` is 1.35rem / 600 / no margin on every search
-  page, a deliberate global change.
-- **`--primary-color` fallback.** Where the menus and the activated view button fall back
-  without the token, the value is `#384372` instead of `#1976d2`; the tree grid header buttons
-  are 28px squares.
-- New public API: `GridViewDescriptor.treeGridControls`, enum `TreeGridControl`,
-  `SmartTableInterface.treeGridControls`, `SmartIconService.hasCustomIcon()`,
-  `ViewContext.sequence`, `ViewContextData.sequence`, `SmartTreeComponent.trackByIdentifier`,
-  `SmartGridComponent.calcRowClasses()`; `GridViewDescriptor.rowStateDisplay`, `rowStateLabels`,
-  `rowStateColumnLabel`, `markOpenRow`, enum `GridRowStateDisplay`, `GridPage.openRowId`;
-  `SmartTableInterface.defaultActionOnClick`, `markOpenRow`, `openRowId`, `rowStateDisplay`,
-  `rowStateLabels`, `rowStateColumnLabel`, `onRowAction`; `UiActionToolbarComponent.actionFired`;
-  `EmbeddedSlotProperties` (`singleView`: the server closes the view standing in the slot before
-  it opens the next; generated for completeness, the client does not read it).
-- **Source changes** for a host that calls these members or extends the classes:
-  - `TreeService.selectNode2(viewUuid, treeId, nodeId, treeSelectionRequest?, observe?, …)`: the
-    optional `TreeSelectionRequest` stands before `observe` in every overload, and the call sends
-    a JSON body. A call that passed `observe` in the fourth place does not compile; insert
-    `undefined` or the request.
-  - `Table` (the base of the table components): `handleOnRowClick(element)` became
-    `handleOnRowClick(event: MouseEvent, element)`; the getters `expandTreeGridLevel` and
-    `closeTreeGridLevel` are gone (the controls come from `treeGridControls`); the rows and the
-    header render `displayedColumns` instead of `smartTable.tableHeaders`, and the expanded
-    detail row spans `displayedColumns.length`. New members: `trackRow`, `rowStateColumn`,
-    `onRowActionFired`. A host template copied from the library's must follow.
-  - `SmartTreeComponent.treeControl`'s children accessor returns an `Observable` of the children,
-    not the array. `SmarttreeGenericService` writes a reload into the node objects a host holds
-    (same objects, new data) and sets `treeFromBackend` to the merged nodes.
-
-### New in 7.3.2: keybindings (#19122)
-
-Additive: a host without a keymap gets one binding, Escape closes a dialog that offers
-`DEFAULT_CLOSE`. Needs the matching platform (`Keybinding`, `View.keybindings`,
-`ComponentModel.keybindings`); release the two together.
-
-- **The keymap.** Properties files on the server, `CODE=chord[,chord]` binds every action of
-  that code, `viewName.CODE=chord[,chord]` only in that view and wins over `CODE`; an empty
-  `viewName.CODE=` disables the chord in that view. The host lists its own file before the
-  platform's, the first file with the key wins:
-  `spring.keybindings.basename=keybindings-<app>,keybindings-platform`. The platform's file binds
-  Escape to `DEFAULT_CLOSE`, `CANCEL` and `CLOSE_SEARCH_PAGE`, which close the view on every
-  platform page offering them; without the property only that file is read.
-- **Chord grammar.** Modifiers, then one key, joined by `+`: `Mod+Shift+S`. `Mod` is Cmd on a Mac
-  and Ctrl elsewhere, so one chord serves both; `Ctrl`, `Alt`, `Shift`, `Meta` are the literal
-  keys. The server writes every chord canonically (modifier order `Mod`, `Ctrl`, `Alt`, `Shift`,
-  `Meta`, letters upper case), so the order and case in the file do not matter. The key is the
-  browser's `KeyboardEvent.key` name (`Escape`, `Enter`, `ArrowUp`, `F2`, `Delete`), the space
-  bar is `Space`. A letter or digit also matches by its physical key when a modifier changes the
-  character (Option+N on a Mac). Chords the browser keeps for itself (`Mod`/`Ctrl` with `W`,
-  `T`, `N`, `Q`, `R`, `Tab`, and `F5`) and unparsable ones are dropped with an ERROR log.
-- **Bindings in code.** A page binds its own actions on the view, typically in `initModel`:
-  ```java
-  view.addKeybindingsItem(new Keybinding()
-      .chord(KeyChord.of(KeyboardKeys.MOD, KeyboardKeys.SHIFT, KeyboardKeys.ARROW_UP))
-      .uiActionCode(MOVE_UP)
-      .uiActionIdentifier(rowId)); // optional: without it every MOVE_UP action is bound
-  ```
-  Per action the code level wins over `viewName.CODE`, which wins over `CODE`; a code-level entry
-  replaces the keymap of its action, they are not merged. Only the code level can name an
-  identifier. When two actions of a view share a chord, the more specific source keeps it, then
-  the earlier action, with a WARN log. The server resolves all this into
-  `ComponentModel.keybindings`; a keymap entry of an action the view does not offer yields
-  nothing.
-- **Which view gets the key.** One document listener serves every view. The key goes to the view
-  holding the focus, the innermost one when views are nested; when nothing has the focus, to the
-  view that had it last (the focus is lost when a pushed layout re-renders the field), else the
-  top-most dialog, else the current page. If that view has no enabled binding for the chord, the key
-  bubbles to the enclosing views, but never out of a dialog: the page behind it does not react
-  while a dialog is open. A NORMAL view opened by the user's action takes the focus, a view
-  restored on reload does not.
-- **What does not fire.** Unmodified typing in an editable element (text inputs, textareas,
-  selects, contenteditable): letters, digits, editing and caret keys, and `Enter` in a multi-line
-  field stay the element's; `Escape`, the function keys, chords with Ctrl, Alt or Cmd, and `Enter`
-  in a single-line input reach the bindings. A disabled or not offered action does not fire: the
-  key bubbles on and reaches the browser when nothing takes it. Auto-repeated keys, a key a panel
-  already handled (`defaultPrevented`) and a key pressed in an overlay of no view (an open select
-  or menu panel) fire nothing. An unmodified `Enter` or `Space` on a focused button, link or
-  ARIA-interactive control stays with that control (the browser activates it), and the `Enter`
-  that confirms an IME composition fires nothing. A fired chord is `preventDefault`ed.
-- **Tooltip and accessibility.** A toolbar button shows its chords in its tooltip, formatted for
-  the platform (`⌘⇧S` on a Mac, `Ctrl+Shift+S` elsewhere), after the server tooltip or alone; the
-  tooltip also opens on keyboard focus. The button names them in `aria-keyshortcuts`.
-- **Two host rules.** Do not bind `Enter` on a view whose form uses `SmartForm.submitOnEnter`:
-  both would run. With `dialogDisableClose: false` MatDialog closes the dialog on Escape itself,
-  as before; the `DEFAULT_CLOSE=Escape` binding is what closes it under the default `true`.
-- **Focus survives a push.** When a push re-renders the field being edited, the view focuses it
-  again: the field with the same widget key (`data-testid`) at the same position within the view,
-  with the caret or selection of a native input or textarea and of a Quill editor. Nothing
-  happens when the field left the layout or the focus moved elsewhere meanwhile (a dialog, a click).
-- **Pending edits are saved first.** A fired action (a key, a toolbar click, an HTML trigger)
-  waits until the view's widgets have saved what was typed into them — today the filter editor,
-  which saves its fields on blur — so a query bound to `Enter` runs with the value just typed. If
-  that save fails, the action is not sent.
-- **Messages.** A message with a single option focuses it and sends it on Escape. Otherwise the
-  first `confirm`-typed option gets the initial focus (Enter presses it) and Escape sends the first
-  `cancel`-typed option. A `reject` option is never chosen by a key, and untyped options (a YES/NO
-  without types) get neither: Escape does nothing, the focus stays on the first button.
-- **Out of scope.** Row actions (grid, table, card rows) and actions inside widgets have no
-  keybindings; only the view's own actions do.
-- **New in the public API:** model `Keybinding`, `View.keybindings`,
-  `ComponentModel.keybindings`; Java `KeyChord`, `KeyboardKeys`, `KeybindingSettingApi`.
-
-### New in 7.3.5: a stored layout names its HTML template by key (#30388)
-
-Additive, and needs the matching platform. Nothing changes for a layout that names no key.
-
-- **`HtmlProperties.templateKey`.** An HTML widget of a stored layout (an
-  `ObjectLayoutDescriptor`) names the template its html and style sheet come from:
-  `h.templateKey("CONTACT_CARD")` in code, `html card { template: CONTACT_CARD }` in the layout
-  DSL. The key stays in the widget and wins over a stored html.
-- **`resolvedCopy(ctx, viewName, layout)`** (`PageApiImpl`, `ObjectLayouts`) is how a stored
-  layout goes onto a view: a deep copy with the keys loaded and the server placeholders resolved.
-  The platform's own paths use it (`ObjectLayoutDescriptorUtilApi.initLayoutDescriptor`, the MDM
-  entry editor, object navigation). **A host that puts `descriptor.getLayouts()` or the layout of
-  `getObjectDisplay` onto a view itself has to call it** before it stores a key in such a layout.
-- **A widget whose key was never loaded renders nothing** and logs one console warning naming
-  the key.
-- **Behaviour changes on the server.** `ObjectLayoutDescriptorUtilApi.initLayoutDescriptor` now
-  puts a copy of the descriptor's layout on the view, not the descriptor's own instance, and
-  fails on an html with a server placeholder (`${alias:/…}`) it has no context for — pass the
-  context with the new `initLayoutDescriptor(view, descriptor, ctx)`. `NavigationNodeLayoutInternalApi
-  .createBodyLayoutWithFieldEdges` takes the view name as its first argument.
-  `PageApiImpl.gridBuilder(...)` hands the template resolver to the `GridBuilder`, so
-  `htmlColumn(c -> c.template(ctx, KEY))` works.
-- **New in the public API:** `HtmlProperties.templateKey`; Java `HtmlWidgetBuilder.templateKey`,
-  `ObjectLayouts.resolvedCopy` / `templateKeys` / `unloadedTemplateKeys`, the `viewName` variants
-  of `resolveHtml`, `DataSheetPageApi.CONTEXT_DATA_SHEET`. See HTML-WIDGET.md, *Template-kulcs egy
-  tárolt layoutban*.
-
-### Bugfixes shipped with 7.0
-
-- (7.3.2) A view dialog no longer disappears on the browser's back button. MatDialog's default
-  `closeOnNavigation` disposed every dialog on a Location change without any action, so the
-  backend kept the views open and a reload brought them back; view dialogs now open with it off.
-- `SmartformwidgetComponent.ngAfterViewInit` no longer crashes with
-  `Cannot read properties of undefined (reading 'valueChanges')` when the form
-  contains a `MONTH_PICKER` widget (it wrongly subscribed to the non-existent
-  `<key>-time` control; only `DATE_TIME_PICKER` has one).
-- A widget nested in a CONTAINER receives `blurSophisticatedValueChange`; the recursion never
-  passed it down, so a BLUR-mode child would have thrown on blur.
-- `SmartformComponent` reaches widgets nested in a CONTAINER when it changes them in place
-  (values, constraints, the touched state after a failed submit). The view query it used
-  could not see them.
-- `UiActionDescriptorService` no longer shares one dialog object between actions. Any action
-  whose descriptor had no `dialog` of its own was given the service's single placeholder — the
-  same object every time — and had its title and button caption written into it, so resolving
-  one action renamed the dialog every other one was holding. The service is
-  `providedIn: 'root'`, so this outlasted the view.
-
-  What you saw on screen, measured on both versions:
-
-  | The action | 6.x, when the dialog opened | 7.0 |
-  |---|---|---|
-  | described by the backend, no dialog of its own | **another action's code** | its own code |
-  | described by nothing at all | **another action's code**, or empty | empty |
-  | registered client-side, no dialog of its own | its own code | unchanged |
-
-  The middle column is not a typo. An action the backend describes is resolved twice in the
-  normal flow — once when the toolbar renders it, again when the dialog it opens resolves it
-  for itself — and the first resolution wrote a dialog onto the action's own descriptor, so the
-  second one skipped the step that fills in the title. What the dialog then showed was whatever
-  code had last passed through the shared object. An **already open** dialog could change too,
-  since its title is re-read on every change-detection pass.
-
-  An action nothing describes still gets an untitled placeholder dialog: its *button* carries
-  the code, the dialog does not. That is unchanged and deliberate — such an action is a gap in
-  the host's descriptor map, and this is the honest rendering of it.
-
-  A resolved descriptor is now the caller's own object throughout, which also means
-  `getActionDescriptor()` no longer writes a placeholder dialog and a `SNACKBAR` feedbackType
-  into the `descriptor` the backend put on the action itself.
+# @smartbit4all/ng-client 6.x → 7.0 migration guide
+
+> 7.0.0 targets **Angular 22.0.8 / TypeScript 6.0.3 / Material 22.0.6**, with PrimeNG fully
+> removed (Material/CDK only), every library component `OnPush`, and **no zone.js** — the
+> configuration 7.0 is tested in. Angular's `moment` date adapter is replaced by `date-fns`.
+> It is a major because a host has to act; nothing here is a silent behaviour change that
+> you could ignore.
+
+## Where to start
+
+1. **Run the codemod** — [Migrating a host: the codemod](#migrating-a-host-the-codemod). It
+   does the mechanical part (the module imports, the provider configuration, the dead legacy
+   calls) and prints `file:line` for everything that needs a decision.
+2. Read [Full standalone + `provideSmartNgClient()`](#full-standalone--providesmartngclient-phase-32--the-big-one).
+   That section rewrites your `app.module.ts`; everything else is small next to it.
+3. Read [Dates](#dates-moment--date-fns-and-the-timezone-contract-phase-38). It is the one
+   change that needs action **at install time**, and the one that breaks at *runtime* on the
+   first screen with a date field rather than at build time.
+4. Then the rest in order. The **PrimeNG removal** sections (1.1–1.10) are API changes; the
+   **hop sections** carry the framework defaults you inherit (OnPush, fetch vs XHR, `?.`).
+5. If you write your own widget, `WIDGETS.md` next to this file is the protocol.
+
+Measured across the 12 hosts in scope on 2026-07-28, so you know what to expect: 12–17
+`Smart*Module` imports per host, 1–20 string-keyed providers, `.cssClass =` on an action
+entry at 72 sites in 7 hosts, `this.uiActionModels =` in 5 hosts, `UseUiAction` in 6.
+
+**How big is this for *your* host?** Codemod dry-run counts for the five hosts in scope
+(2026-07-30). The first column the codemod applies for you; the second is the list it refuses to
+guess at, which is the real work:
+
+| host | mechanical | needs a decision |
+|---|---|---|
+| p014 *(done — the reference)* | 121 | ~100 |
+| p043 | 121 | 96 |
+| app-tournament | 86 | 34 |
+| app-finance-ai | 62 | 18 |
+| app-fitnessmirror | 61 | 14 |
+
+The spread is not about host size — all five are within 274–841 source files — but about which
+APIs they happened to use. p043 is p014's twin and repeats its whole decision list; the other
+three have **no `.cssClass =` sites at all**, and their lists are dominated by `smart-modules`,
+the 3-line `moment-adapter` swap, and `zone-js` (which is **optional** — dropping zone.js is not
+required). Take a small one first if you want the process shaken out cheaply.
+
+**One number that is now zero: the library install.** p014 was migrated against an unpublished
+build and paid for it in hand-copies, tarballs and `ERESOLVE`. 7.0.0 is on npm, so a host today
+writes `"@smartbit4all/ng-client": "^7.0.0"` and runs `npm i`. None of that thread applies to you.
+
+## Migrating a host: the codemod
+
+It lives in the `platform-angular2` repository — `tools/ng-client-7-codemod/` — and you run
+it with plain Node, from a checkout, against your own source directory. Nothing to install.
+
+```bash
+node tools/ng-client-7-codemod/migrate.mjs ../my-host/ui-angular/src --dry-run   # look first
+node tools/ng-client-7-codemod/migrate.mjs ../my-host/ui-angular/src            # then write
+```
+
+It **refuses to run on a dirty git tree** (its diff is how you review it, and `git checkout .`
+is how you undo it), it is **idempotent**, and it prints a verdict for every rule it knows —
+including `no sites found`, because a codemod that silently matched nothing looks exactly
+like one that had nothing to do.
+
+**What it rewrites:** the `Smart*Module` imports (into the standalone declarables of the
+mapping table below), the string-keyed providers and both `forRoot()` payloads (into one
+`provideSmartNgClient(config, ...features)` call), the redundant core services in the root
+providers array, `this.useQueryLists = true` / `handleDataChangeSubscriptions()`,
+`[parentSmartComponent]` and the dead `[parent]` inputs,
+`execute(x.uiAction, x)` → `execute(x)`, the `async` / `await` around
+`getActionDescriptor`, the `SmartdialogService` `super(…)` call and its constructor
+parameters, and PrimeNG module imports **no template in your repository renders**.
+
+**What it refuses to guess at**, printing `file:line` and the section here that explains it:
+`UseUiAction` → `UiActionExecutor`, `this.uiActionModels =`, `entry.cssClass =`, `addForm()`,
+the 4th argument of `addGrid()`, `getActionDescriptor(…).then(…)`, the moment adapter,
+component-level providers, every remaining `primeng/*` import, and `::ng-deep` selectors that
+reach into the form widget.
+
+**What it deliberately does not do:** convert *your* components to standalone. That is
+Angular's own schematic (`ng generate @angular/core:standalone`) and it is not required — an
+NgModule's `imports:` array takes standalone components, which is exactly what the codemod
+puts there. Do the library migration first, get the app running, then decide about standalone
+separately.
+
+Afterwards: run your formatter, swap the date packages ([Dates §1](#1-swap-the-peer-dependency)),
+build (expect one `NG8001` per template element whose component is not imported yet — that
+loop terminates), and **smoke the app**, because the DI changes are invisible to the compiler.
+
+## Breaking changes
+
+### Dialog stack: PrimeNG dynamicdialog → MatDialog (Phase 1.1)
+
+- `SmartdialogService` and `SmartViewContextDialogService` constructors no longer
+  take a PrimeNG `DialogService` parameter. If your host extends or instantiates
+  these services, drop the argument (MatDialog is injected internally).
+
+  Both arguments PrimeNG contributed are gone, so the base constructor lost two of
+  its four parameters:
+
+  ```ts
+  // 6.x
+  constructor(dialog: MatDialog, dialogService: DialogService, inject: Injector,
+              @Inject(COMPONENT_LIBRARY) compLib: ComponentLibrary) {
+    super(dialog, dialogService, inject, compLib);
+  }
+  // 7.0
+  constructor(dialog: MatDialog, inject: Injector) {
+    super(dialog, inject);
+  }
+  ```
+
+  **The codemod does this** (rule `smartdialog-super`), including the constructor
+  parameters and the now-unused `primeng/dynamicdialog` import — except where a
+  dropped parameter carries an accessibility modifier (`protected dialogService: …`),
+  which declares a class *property* the body may still read. Those are reported.
+- The `ComponentLibrary` switch no longer has a PrimeNG branch in the dialog
+  layer — all dialogs open via `MatDialog` regardless of `COMPONENT_LIBRARY`.
+
+### smart-form widgets: PrimeNG removed (Phase 1.2)
+
+- `ComparableDropdownDirective` and `ComparableMultiselectDirective` are removed
+  (they decorated the PrimeNG `p-dropdown` / `p-multiSelect` elements, which no
+  longer exist). Use `SmartformwidgetComponent.compareItems` semantics via
+  `mat-select [compareWith]`, which the widget template already wires up.
+- `SmartformwidgetComponent` constructor no longer takes the injected
+  `COMPONENT_LIBRARY` token; the widget renders Material-only.
+- `SmartformwidgetComponent` removed PrimeNG-only public members:
+  `errorMessages`, `getControlMessages()`, `onPrimeRichTextEditorContentChanged()`,
+  `safeDropDownBlur()`/`onDropDownShow()`/`onDropDownInput()`,
+  `safeCalendarBlur()`/`onCalendarShow()`/`onCalendarInput()`, `defaultDate`.
+- `SmartFormService.setValuesFromModel()` / `toFormGroup()` /
+  `createFormControls()` no longer take a `ComponentLibrary` parameter.
+- `SmartViewContextModule` no longer imports the PrimeNG form modules
+  (Dropdown, MultiSelect, Calendar, Chips, InputSwitch, Checkbox, InputNumber,
+  InputText, InputTextarea, InputMask, FloatLabel, Messages) and no longer
+  provides `Dropdown` / `MultiSelect`.
+
+### fileupload: PrimeNG removed (Phase 1.4)
+
+- `SmartFileUploaderComponent` (selector `smart-file-uploader4sc`) is removed
+  from the public API. It was a PrimeNG `p-fileUpload` wrapper declared in
+  `SmartNgClientModule` but referenced nowhere; the Material-style
+  `SmartfileuploaderComponent` (selector `smartfileuploader`) is the uploader.
+- The internal `PrimeFileUploaderComponent` (selector `prime-file-uploader`)
+  is removed; `smart-upload-widget` always renders `smartfileuploader`.
+- `UploadWidgetComponent` constructor no longer takes the injected
+  `COMPONENT_LIBRARY` token, and its PrimeNG-only members are gone
+  (`fileUploadPrime`, `uploadFiles()`).
+- `SmartNgClientModule` and `SmartViewContextModule` no longer import the
+  PrimeNG `FileUploadModule`; `SmartViewContextModule` also dropped the dead
+  `OverlayPanelModule` import (Phase 1.3).
+
+### editor: Quill 1.3 → 2, quill-emoji removed (Phase 1.5)
+
+- Peer dependencies changed: `quill` `^1.3.7` → `^2.0.3`, `ngx-quill`
+  `16.2.1 - 24.0.5` → `^25.3.3`. Hosts must bump both together (ngx-quill 25.x
+  is the Quill 2 line for Angular 17; later Angular hops will raise it further).
+- `quill-emoji` peer dependency is **removed** (dead, Quill 1-only, unmaintained).
+  If a host needs emoji support, pick a Quill 2-compatible module on its own.
+- `@types/quill` must be removed from host devDependencies — Quill 2 ships its
+  own TypeScript types, and the stale `@types/quill` 1.x conflicts with them.
+- The bundled `quill.snow.css` (imported by the smart-form widget) is now the
+  Quill 2.0.3 stylesheet; hosts that import `quill/dist/quill.snow.css`
+  themselves must serve the Quill 2 version.
+- `SmartViewContextModule` no longer imports the PrimeNG `EditorModule`
+  (`<p-editor>` died with Phase 1.2; RICH_TEXT renders via ngx-quill).
+
+### smart-diagram: p-chart replaced by direct chart.js (Phase 1.6)
+
+- `SmartDiagramComponent` renders its own `<canvas>` and instantiates chart.js
+  directly; the PrimeNG `<p-chart>` wrapper (and the `ChartModule` import in
+  `SmartDiagramModule`) is gone. Chart.js controllers are now registered by the
+  component itself (`Chart.register(...registerables)`), so no `chart.js/auto`
+  import is needed anywhere.
+- The public `chart` property (and `getChart()`) is now the chart.js `Chart`
+  instance instead of the PrimeNG `UIChart` component. `getBase64Image()` and
+  `refresh()` keep their signatures (delegating to `toBase64Image()` /
+  `update()`).
+- `SmartDiagramComponent` constructor no longer takes the injected
+  `COMPONENT_LIBRARY` token; the component has a single render path.
+- DOM/CSS hooks changed: the internal structure is
+  `div.chart-host > div.chart-container > canvas`; host styles targeting
+  `::ng-deep p-chart` no longer match. The aspect-ratio classes
+  (`default-aspect-ratio` / `pie-aspect-ratio`) are now applied on
+  `.chart-host` and size `.chart-container`.
+
+### smart-grid: PrimeNG branch removed (Phase 1.7)
+
+- `SmartGridComponent` renders Material-only. The `@if (compLib === PRIMENG)`
+  template branch (the inline `p-table` / `p-paginator` / `p-menu` /
+  `p-multiSelect` grid) is gone; the grid always renders through the PrimeNG-free
+  `smart-table` (the `#table` slot), `mat-tree`, `app-smart-grid-card`, and
+  `mat-paginator`.
+- `SmartGridComponent` constructor no longer takes the injected
+  `COMPONENT_LIBRARY` token, nor the `SmartDatePipe` / `SmartDateTimePipe` /
+  `SmartTimePipe` (they only fed the removed inline `p-table` cell renderer);
+  those pipes are dropped from the component `providers` too.
+- Removed PrimeNG-only public members: `columns`, `menuButtons`, `menu`,
+  `onOptionsClick()`, `previousmultiSortMeta`, `gridSort()`, `lazyLoad()`,
+  `headerChange()`, `onColOrder()`, `getOrderColumNames()`, `getColValue()`,
+  `onPrimeChangePage()`, `onRowSelect()`, `onRowUnselect()`, `onSelectAllRow()`,
+  `getImageResourceIcons()`, `getImageResourceStyle()`, `getRowColumnAction()`,
+  `showCellToolbar()`, `shouldShowOptionsButton()`, `calculateMenuActions()`,
+  `createCellToActionMap()`, `getRowMenuActionModelArray()`, `rowTrackByFn()`,
+  `cellToActionMap`, `columnMetaByName`, and the `_headerToolbar`
+  (`#headerToolbar`) view child. The `headerToolbar` getter now returns the
+  smart-table's header toolbar unconditionally (its only remaining consumer,
+  `SmartComponentApiClient`, is unaffected).
+- `SmartGridModule` no longer imports the PrimeNG `TableModule`, `ButtonModule`,
+  `MenuModule`, `PaginatorModule`, `MultiSelectModule`; `MatTooltipModule` is
+  added (the grid refresh button is now a Material `mat-icon-button` +
+  `matTooltip` instead of `pButton` + `pTooltip`).
+- Note: this is the PrimeNG-branch deletion only. The `smart-grid` internals
+  rewrite to `mat-table` + `MatPaginator` and the `smart-grid`/`smart-table`
+  merge remain a Phase 3 (post-Angular-22) change.
+
+### misc widgets: PrimeNG branches removed (Phase 1.8)
+
+The remaining components that still carried a dead PrimeNG branch alongside an
+already-active Material one are now Material-only. In every case the Material
+branch was the rendered path under `COMPONENT_LIBRARY = MATERIAL` (the value all
+7.0 hosts use), so this is render-neutral; the `COMPONENT_LIBRARY` token, where
+these components still injected it, is now ignored by them.
+
+- `ExpandableSectionComponent` renders Material-only (the `p-accordion` branch is
+  gone; always `mat-expansion-panel`). Its constructor no longer takes the
+  injected `COMPONENT_LIBRARY` token. `SmartExpandableSectionModule` no longer
+  imports the PrimeNG `AccordionModule`.
+- `UiActionButtonComponent` renders Material-only (the `pButton`/`pRipple` branch
+  is gone; always `mat-button`). Its constructor no longer takes the optional
+  `COMPONENT_LIBRARY` token (it previously defaulted to `PRIMENG` when unset).
+  `getType()` no longer has a PrimeNG class-map branch — it returns the
+  `mat-mdc-*` class strings unconditionally. (The dynamic `getbtnClass()`'s
+  `p-button-<color>` class token was later dropped in Phase 1.9.)
+- `UiActionToolbarComponent` constructor no longer takes the injected
+  `COMPONENT_LIBRARY` token. The dead `getType()` / `getbtnClass()` methods
+  (never referenced by the template) were removed, and the scroll-affordance
+  buttons use the Material icons `arrow_back` / `arrow_forward` unconditionally
+  (the PrimeNG `chevron-left` / `chevron-right` fallback is gone).
+- `UiActionConfirmDialogComponent` and `UiActionInputDialogComponent` render
+  their close button as a Material `mat-icon-button` unconditionally (the `@else`
+  `p-button` branch is gone); both constructors no longer take the injected
+  `COMPONENT_LIBRARY` token.
+- `SmartIconModule` no longer imports the PrimeNG `BadgeModule` (badges render
+  via the custom `ui-badge` component, unaffected).
+- `SmartViewContextModule` no longer imports the PrimeNG `ButtonModule`,
+  `TooltipModule`, `ToastModule`, `ImageModule`, or `OrderListModule` (all
+  unused after the branch deletions). The `primeng/api` `SharedModule`
+  (`PrimeSharedModule`) import was later dropped in Phase 1.9's final sweep.
+
+### PrimeNG package dependency removed (Phase 1.9)
+
+The `primeng` npm package is gone. Most importantly it is dropped from
+`@smartbit4all/ng-client`'s own **`peerDependencies`** (in
+`projects/smart-ng-client/package.json`, which flows into the published
+`npms/smart-ng-client/package.json`) — that entry is what previously forced every
+consuming host to install PrimeNG. It is also removed from the dev workspace
+(`package.json`, `package-lock.json`, `node_modules`), and both PrimeNG theme
+stylesheets (`primeng/resources/themes/saga-blue/theme.css`,
+`primeng/resources/primeng.min.css`) are removed from the app-playground `styles`
+in `angular.json`. Hosts that still list `primeng` as a dependency or load its
+theme CSS should remove both; 7.0 renders entirely on Material/CDK.
+
+#### Your own PrimeNG usage
+
+Removing the peer dependency does not remove PrimeNG from *your* code, and the measured
+hosts carry more of it than their authors expect — mostly as **dead module imports**. Across
+the 12 hosts, `DialogService` is imported 56 times, but 8 of those in p014 turned out to be
+nothing but the base-constructor argument above, and four PrimeNG modules in its
+`app.module.ts` rendered nothing at all.
+
+So the codemod separates the two cases, and the separation is decidable rather than
+guessed:
+
+- **`primeng-modules`** — a PrimeNG NgModule in an `imports:` array is **deleted** when none
+  of its selectors appears in any template in the repository. The scan runs over `.html`
+  *and* `.ts` (for inline templates) before anything is rewritten, and it distinguishes an
+  element (`<p-tree>`) from an attribute directive (`pTooltip`) so that a leftover
+  `class="p-button"` is not read as a component still in use. What the scan found is printed
+  in the header, because it is what licenses the deletions.
+- **`primeng-imports`** — everything else from `primeng/*` is reported with its replacement.
+  These are the real ports.
+
+The replacements, for what the hosts actually import:
+
+| PrimeNG | Material / CDK |
+|---|---|
+| `p-button` / `pButton` | `MatButtonModule` — `mat-button`, `mat-icon-button` |
+| `p-tree` | the library's `<smart-tree>`, or `MatTreeModule` |
+| `p-progressSpinner` | `MatProgressSpinnerModule` — `<mat-spinner>` |
+| `pTooltip` | `MatTooltipModule` (`matTooltip`), or `SmartTooltipDirective` |
+| `p-sidebar` | `MatSidenavModule` |
+| `pInputText` | `MatInputModule` — `matInput` inside `<mat-form-field>` |
+| `p-fieldset` | `MatCardModule`, or `<fieldset>` + `<mat-divider>` |
+| `p-divider` | `MatDividerModule` |
+| `p-accordion` | `MatExpansionModule`, or `<smart-expandable-section>` |
+| `p-table` | the library's `<smart-grid>`, or `MatTableModule` |
+| `p-editor` | ngx-quill's `<quill-editor>` (already a library dependency) |
+| `p-badge` / `pBadge` | `MatBadgeModule`, or `UiBadgeComponent` / `UiBadgeDirective` |
+| `p-menu`, `p-overlayPanel` | `MatMenuModule`, or the CDK Overlay |
+| `p-inputSwitch` | `MatSlideToggleModule` |
+| `p-dialog` | `MatDialog` — open a component instead of toggling `[visible]` |
+| `DialogService` | `MatDialog`. There is **no `header` option**: put `<h2 mat-dialog-title>` in the component |
+| `DynamicDialogRef` | `MatDialogRef` — `afterClosed()` replaces `onClose` |
+| `DynamicDialogConfig` | `MAT_DIALOG_DATA` for the data, `MatDialogRef` for the rest |
+| `PrimeNGConfig` | **delete it.** `setTranslation()` of day and month names is already covered by `MAT_DATE_LOCALE` + `SmartDateFnsAdapter` — the date-fns `hu` locale carries both the names and the Monday week start. **Confirmed on a running host** (p014, 2026-07-29, against a live backend): the datepicker opens on `2026. JÚL.` with `H K Sz Cs P Sz V`, i.e. Hungarian and Monday-first, exactly what the deleted `firstDayOfWeek: 1` + `dayNamesMin` used to buy. See [Dates](#dates-moment--date-fns-and-the-timezone-contract-phase-38) |
+| `MessageService` | `MatSnackBar` |
+| `ConfirmationService` | the library's `UiActionConfirmDialogService` |
+| `MenuItem` | the library's `UiActionModel`, or a plain `<mat-menu>` item |
+| `SharedModule` (`primeng/api`) / `PrimeTemplate` | a plain `<ng-template>` — PrimeNG needed `pTemplate`, Material does not |
+
+`primeicons` is a separate package. Nothing in 7.0 needs it, but nothing breaks if you keep
+it either — `pi pi-*` class names are just a font.
+
+### `QuillModule.forRoot()` in your root module
+
+`provideSmartNgClient()` calls `importProvidersFrom(QuillModule.forRoot())` itself — ngx-quill
+has no provider function, so the module is the only way to reach its root configuration. A
+root module that also calls it is configuring quill twice, so the codemod removes the call
+and its import. In a *feature* module the same call is that module's own configuration and is
+left alone.
+
+**Keep `ngx-quill` and `quill` in your `package.json`.** They are peer dependencies of the
+library — the host provides them. npm installs peers automatically, which is why hosts have
+got away with not declaring them, but any install that runs with `--legacy-peer-deps` drops
+them silently and the next build fails on an import that has always worked. Two of the twelve
+measured hosts were in exactly that state.
+
+**7.0 adds four peer dependencies 6.x did not have**, and they bite in a way the TypeScript
+errors do not prepare you for:
+
+```bash
+npm install ngx-mask@^22.0.0 fast-equals@^5.0.1 wavesurfer.js@^7.9.5 @angular/youtube-player@^22.0.0
+```
+
+If you install the library the normal way, npm brings these in for you. If you *swap a local
+build into `node_modules` by hand* — which is how you would try the library before it is
+published — npm never runs, so nothing installs them. The symptom arrives **after** the last
+TypeScript error is fixed, as five `Module not found` errors reported against the library's
+own `fesm2022` bundle rather than against any file of yours:
+
+```
+./node_modules/@smartbit4all/ng-client/fesm2022/smartbit4all-ng-client.mjs:7:0-60 -
+  Error: Module not found: Error: Can't resolve 'ngx-mask'
+```
+
+Four packages, five errors: `wavesurfer.js` is missing twice, once for its `record` plugin.
+
+- `UiActionButtonComponent.getbtnClass()` no longer emits the dead
+  `p-button-<color>` class token — it returns only `sb4-<color>` (nothing styled
+  `.p-button-*`; the platform button theme keys off `sb4-<color>` in
+  `custom-theme.scss`). Hosts with their own `.p-button-<color>` overrides for
+  sb4 action buttons should migrate them to `.sb4-<color>`.
+- `SmartViewContextModule` no longer imports the `primeng/api` `SharedModule`
+  (`PrimeSharedModule`); no template in the module used `pTemplate`.
+- `SmartComponentLayoutModule` no longer imports `InputGroupModule` /
+  `InputGroupAddonModule` (they were dead — no `p-inputGroup` template existed).
+
+The `ComponentLibrary` enum still exists with only its `MATERIAL` member in
+active use; its `PRIMENG` member and the remaining dead `ComponentLibrary.PRIMENG`
+code branches (icon/menu/widget components, dead `.p-*`/`.pi` CSS) are removed in
+a follow-up internal-cleanup step (1.10) — they are not a package dependency and
+do not affect hosts. `deviceInfo.componentLibrary` continues to report
+`material` to the backend.
+
+### ComponentLibrary / COMPONENT_LIBRARY removed entirely (Phase 1.10)
+
+7.0 is Material-only, so the `ComponentLibrary` abstraction (which had no second
+implementation once PrimeNG was gone) is deleted outright.
+
+- **Host action required:** `ComponentLibrary` (enum) and `COMPONENT_LIBRARY`
+  (injection token) are no longer exported from `@smartbit4all/ng-client`. Hosts
+  that provide `{ provide: COMPONENT_LIBRARY, useValue: ComponentLibrary.MATERIAL }`
+  in their root providers must **remove that provider and its import** — it now
+  fails to compile (no exported member). No replacement is needed; every component
+  renders Material-only.
+- Every `@Inject(COMPONENT_LIBRARY)` constructor argument is gone from the library
+  (smart-icon, click/hover tiered menu, photo-capture / voice-record widgets,
+  smart-voice-recorder, smart-file-editor, smart-multi-file-editor, sortable
+  widget, smart-filter-editor-content, validation-result-page, message-dialog, the
+  dialog services `SmartdialogService` / `SmartViewContextDialogService` /
+  `SmartViewContextErrorDialogService` / the ui-action confirm/input/file-upload
+  dialog services, and `PdfViewerDialogService` in `@smartbit4all/document-explorer`).
+  The `SmartdialogService` base constructor is now `(dialog, injector)` — subclasses
+  that called `super(dialog, dialogService, injector, compLib)` keep the first and
+  third arguments only. See [Phase 1.1](#dialog-stack-primeng-dynamicdialog--matdialog-phase-11);
+  the codemod rewrites it.
+- `SmartViewContextService` no longer exposes the public `componentLibrary` field
+  and no longer injects the token; it now writes the literal `'material'` into
+  `deviceInfo.componentLibrary` on every view-context update (the backend keys its
+  icon set on this string — `images-playground.properties` has `.material=` vs
+  `.primeng=` variants — so the value keeps flowing; the DTO field is unchanged).
+- All dead `ComponentLibrary.PRIMENG` branches and their PrimeNG icon names
+  (`chevron-right`, `pi pi-*`, `power-off`, `trash`, `file`, `exclamation-circle`,
+  `play-circle`/`stop-circle`, etc.) are removed; the Material icon path is now
+  unconditional. Dead `.p-*` / `.pi` CSS rules were purged from the library
+  (smart-icon, smartform, smartformwidget, the file editors/uploader,
+  ui-action-file-upload-dialog) and from the app-playground `custom-theme.scss`;
+  the app-playground `index.html` no longer loads the `primeicons` CDN stylesheet.
+- After 1.10, `grep -rin primeng projects` reports a single residual: the
+  auto-generated `deviceInfo.ts` DTO doc comment (`(Material, PrimeNg)`), which
+  mirrors the backend OpenAPI field description and is regenerated from it — left
+  untouched by design (the field itself is intentionally kept).
+
+### Angular 18 hop (Phase 2, 17 → 18)
+
+The library line now builds against Angular 18. Host-relevant changes:
+
+- **Peer dependency bumps** (hosts must upgrade together with the lib):
+  `@angular/*` `^18.0.0`, `@angular/youtube-player` `^18.2.14` (was lagging on
+  `^16` — its `^16 || ^17` peer range breaks a strict `npm install` on Angular
+  18, so it can no longer lag), `ngx-quill` `^26.0.0` (the Angular 18 line;
+  quill stays `^2.0.3`), `ngx-mask` `^18.0.0`, and — for
+  `@smartbit4all/document-explorer` — `ngx-extended-pdf-viewer` `^21.0.0`
+  (the 19.x/20.x lines cap their Angular peer below 18).
+- **`parchment` hoisting quirk (ngx-quill 26):** the ngx-quill 26 typings
+  reference `import("parchment")`, but npm may leave `parchment` nested under
+  `node_modules/quill/` (even after `npm dedupe`), which fails the host build
+  with `TS2307: Cannot find module 'parchment'`. Fix: add
+  `"parchment": "^3.0.0"` to the host devDependencies so it is hoisted to the
+  top level (quill 2 depends on parchment 3, so versions cannot conflict).
+- **Material theming (M2 compat APIs):** the `ng update @angular/material@18`
+  schematic rewrites M2 theme SCSS to the prefixed compat API
+  (`mat.define-palette` → `mat.m2-define-palette`,
+  `mat.$indigo-palette` → `mat.$m2-indigo-palette`,
+  `mat.define-light-theme` → `mat.m2-define-light-theme`, …). The theme stays
+  visually **M2** — no M3 switch happens at this hop; hosts running the
+  schematic get this rewrite automatically.
+- **`HttpClientModule` deprecation:** the `ng update @angular/core@18`
+  migration replaces `HttpClientModule` imports with
+  `provideHttpClient(withInterceptorsFromDi())`. Not a library breaking
+  change (the lib's generated API services were migrated internally), but
+  hosts will get the same automatic migration in their own modules.
+- TypeScript requirement raised to `>=5.4` (the repo builds on 5.5).
+
+### Angular 19 hop (Phase 2, 18 → 19)
+
+The library line now builds against Angular 19. Host-relevant changes:
+
+- **Peer dependency bumps** (hosts must upgrade together with the lib):
+  `@angular/*` `^19.0.0`, `@angular/youtube-player` `^19.0.0`,
+  `ngx-quill` `^27.0.0` (the Angular 19 line; quill stays `^2.0.3`),
+  `ngx-mask` `^19.0.0`, and — for `@smartbit4all/document-explorer` —
+  `ngx-extended-pdf-viewer` `^22.0.0` (the 21.x line caps its Angular peer
+  below 19).
+- **ngx-extended-pdf-viewer 22 input rename:** the `[showScrollingButton]`
+  input no longer exists — it is `[showScrollingButtons]` (plural,
+  `ResponsiveVisibility`). Hosts that use `<ngx-extended-pdf-viewer>` directly
+  must rename the binding, otherwise the template fails with NG8002.
+- **Standalone-by-default:** in Angular 19 components/directives/pipes are
+  standalone unless declared otherwise. The `ng update @angular/core@19`
+  migration automatically adds `standalone: false` to every NgModule-declared
+  declarable in the host codebase — run it and review the (large, mechanical)
+  diff. Declarables not referenced by any NgModule are skipped by the
+  schematic.
+- **Material theming:** the `ng update @angular/material@19` schematic splits
+  `@include mat.core()` into `@include mat.elevation-classes()` +
+  `@include mat.app-background()`. No visual change; hosts running the
+  schematic get this rewrite automatically.
+- **New NG8111 extended diagnostic** (warning): "Function in event binding
+  should be invoked". Uninvoked event bindings like
+  `(click)="(someCallback)"` — previously silently dead — are now flagged at
+  build time. Warning only, the build stays green.
+- TypeScript requirement stays satisfied by 5.5 (Angular 19 supports
+  TS 5.5–5.8). `ng update @angular/core@19` can install **TS 5.9** all the same, and the
+  build then stops with "requires TypeScript >=5.5.0 and <5.9.0"; pin `typescript ~5.8.3`
+  (p009-angular, 2026-10-27).
+- TS 5.8 reports two dead constructs as errors: **TS2869** on a `` `${x}` ?? '' `` (a template
+  literal is never nullish) and **TS2353** on a property the widget type does not have, e.g.
+  `direction` on a `SELECT` widget. Both never did anything; delete them (p034).
+
+### Angular 20 hop (Phase 2, 19 → 20)
+
+The library line now builds against Angular 20. Host-relevant changes:
+
+- **Peer dependency bumps** (hosts must upgrade together with the lib):
+  `@angular/*` `^20.0.0`, `@angular/youtube-player` `^20.0.0`,
+  `ngx-quill` `^28.0.0` (the Angular 20 line; quill stays `^2.0.3`),
+  `ngx-mask` `^20.0.0`, and — for `@smartbit4all/document-explorer` —
+  `ngx-extended-pdf-viewer` `^23.0.0` (the 22.x line caps its Angular peer
+  below 20). No pdf-viewer API rename at this bump (unlike 22.x).
+- **TypeScript 5.9 required** (Angular 20 supports 5.8–5.9); `ng update`
+  bumps it automatically. TS 5.9 adds **TS2872 "This kind of expression is
+  always truthy"**, which turns previously-silent dead `||` alternatives into
+  build errors — expect one or two in any older codebase.
+- **Material 20 button labels no longer set `white-space: nowrap`.** Material
+  20 dropped the MDC stylesheet (`@material/button`), which used to carry it.
+  Multi-word button labels now wrap, and any rule that lets the button size to
+  its content (the lib's `.mdc-button { height: fit-content }`) makes the
+  button grow taller. The lib restores the pre-20 look inside
+  `ui-action-button` (`.mdc-button__label { white-space: nowrap }`); **hosts
+  that render Material buttons of their own must add the same rule** if they
+  relied on single-line labels (typical symptom: a navigation bar that
+  suddenly wraps and overflows into scroll arrows).
+- **Material 20 renamed the MDC-era CSS custom properties**: e.g.
+  `--mdc-text-button-container-height` → `--mat-button-text-container-height`.
+  The `ng update @angular/material@20` schematic rewrites the ones it finds in
+  `.css`/`.scss` files; token names embedded in TS strings or host templates
+  must be renamed by hand.
+- **`DOCUMENT` moved from `@angular/common` to `@angular/core`.** Automatic
+  migration; `@angular/common`'s re-export is deprecated.
+- **`moduleResolution: "node"` → `"bundler"`** in `tsconfig.json` (and any
+  `tsconfig.lib.json` that sets it explicitly). Automatic migration; it changes
+  how sub-path exports resolve, so a host with hand-written `paths` entries
+  should re-verify its build. A deep import such as
+  `import { UiAction } from '@smartbit4all/ng-client/projects'` stops resolving
+  (TS2307); import from `@smartbit4all/ng-client` instead. A 4.5-era deep import of a
+  generated model (`@smartbit4all/document-explorer/lib/api/...`,
+  `@smartbit4all/ng-client/lib/smart-generic-pages/api/...`) breaks the same way and has no
+  root export: take the host's own generated model, or derive the type from the field it
+  copies (`AdminTemplate['file']`) (p034).
+- **A host without `skipLibCheck` that still imports `primeng/dynamicdialog` stays red from
+  this hop**: PrimeNG 17's typings name `InjectFlags`, which Angular 20 removed (TS2305 inside
+  `node_modules/primeng`). The 6.x `SmartdialogService` subclasses need that import until the
+  codemod removes it, so this hop joins 21 and 22 as red until the 7.0 library is in (p034).
+- **Workspace generation defaults**: the CLI adds a `schematics` block to
+  `angular.json` pinning the pre-20 file-naming style (`type: "component"`,
+  `typeSeparator: "."`). Cosmetic — it only affects newly generated files.
+- Optional migrations **not** run here (deferred to the modernization phase):
+  `use-application-builder` (esbuild), `control-flow-migration`,
+  `router-current-navigation`.
+- The `InjectFlags`, `TestBed.get` → `TestBed.inject` and
+  `provideServerRendering` migrations were no-ops for this codebase.
+- The NG8111 warnings introduced at the 19 hop are no longer emitted by the
+  Angular 20 compiler (the dead bindings themselves are unchanged).
+
+### Angular 21 hop (Phase 2, 20 → 21)
+
+The library line now builds against Angular 21. Host-relevant changes:
+
+- **Peer dependency bumps** (hosts must upgrade together with the lib):
+  `@angular/*` `^21.0.0`, `@angular/youtube-player` `^21.0.0`,
+  `ngx-quill` `^29.0.0` (the Angular 21 line; quill stays `^2.0.3`),
+  `ngx-mask` `^21.0.0`, and — for `@smartbit4all/document-explorer` —
+  `ngx-extended-pdf-viewer` `^25.0.0` (the 24.x line still caps its Angular
+  peer below 21). No pdf-viewer API rename at this bump.
+  - **`ngx-quill` 30.x is intentionally *not* used.** 30.x is the "zoneless"
+    line and drops the `zone.js` peer dependency; the 7.0 lib is still
+    zone-based. Hosts that have already gone zoneless may use 30.x, but the
+    lib is only validated against 29.x.
+- **TypeScript stays 5.9** and **zone.js stays 0.15** (Angular 21 accepts
+  `~0.15.0 || ~0.16.0`). **Node** must satisfy
+  `^20.19.0 || ^22.12.0 || >=24.0.0`.
+- **`MatCommonModule` is removed from `@angular/material/core` (breaking).**
+  It was already deprecated in Material 20 (`@breaking-change 21.0.0`). Any
+  host NgModule that imports it will fail to compile with
+  `Unknown reference` — and because a broken NgModule cascades, the real
+  error usually shows up as a flood of `NG8001: '<some-component>' is not a
+  known element` / `NG6002: … does not appear to be an NgModule class`
+  further down the build log. **Fix: just delete the import and the array
+  entry.** `MatCommonModule` had no template surface; it only
+  (a) applied the `cdk-high-contrast-*` body classes — `A11yModule` still
+  does this, and Material components that need it import `A11yModule`
+  themselves — and (b) re-exported `BidiModule`. If your host actually uses
+  the `Dir` directive or injects `Directionality`, import
+  `BidiModule` from `@angular/cdk/bidi` explicitly.
+  The lib dropped it from all 10 of its own modules.
+- **`provideZoneChangeDetection()` is now added at bootstrap** by the
+  `ng update` migration, e.g.
+  `bootstrapModule(AppModule, { applicationProviders: [provideZoneChangeDetection()] })`.
+  This keeps zone-based change detection explicit; behaviour is unchanged.
+- **The control-flow migration (`*ngIf` → `@if`) now runs as a *mandatory*
+  `ng update` migration**, not an optional one. It rewrites every structural
+  directive in the workspace. The lib **reverted** it to keep the version hop
+  reviewable — `NgIf`/`NgForOf`/`NgSwitch` still ship in Angular 21, so
+  `*ngIf`/`*ngFor` keep working. Hosts may keep or revert it as they prefer;
+  if you want it as a separate change, run
+  `npx ng generate @angular/core:control-flow` on its own commit.
+- **New `NG8107` extended diagnostic** (warning): an optional chain `?.`
+  whose left side can no longer be `null`/`undefined` under Angular 21's
+  sharpened template inference. Warning only — expect a batch of them in any
+  older template set.
+- **`tsconfig.json` loses its explicit `lib` array** (the CLI derives it from
+  `target`). Automatic migration.
+- The Material and CDK v21 migration schematics made no source changes, and
+  the `Router.lastSuccessfulNavigation` migration was a no-op. The optional
+  `router-current-navigation` migration was not run.
+- The `.mdc-button__label { white-space: nowrap }` workaround introduced at
+  the Angular 20 hop is **still required on Material 21** — the class still
+  exists in the button template and Material still ships no `white-space`
+  rule for it.
+
+### Angular 22 hop (Phase 2, 21 → 22) — final hop
+
+The library line now builds against **Angular 22**. This is the biggest
+host-facing hop of the series: it changes the **change-detection default**, the
+**HTTP backend default** and the **meaning of `?.` in templates**. All three are
+handled by `ng update` migrations, but you must let them run.
+
+- **Peer dependency bumps** (hosts must upgrade together with the lib):
+  `@angular/*` `^22.0.0`, `@angular/youtube-player` `^22.0.0`,
+  `ngx-quill` `^31.0.0` (the Angular 22 line; quill stays `^2.0.3`),
+  `ngx-mask` `^22.0.0`, and — for `@smartbit4all/document-explorer` —
+  `ngx-extended-pdf-viewer` `^28.0.0` (25/26/27 all cap their Angular peer
+  below 22). **No pdf-viewer API rename at this bump.**
+  `@ngx-translate/core` `^14` still works (its peer is `>=13`).
+- **TypeScript must be 6.0** (`@angular/compiler-cli` peers `>=6.0 <6.1`);
+  **zone.js stays 0.15** (`~0.15.0 || ~0.16.0`) and **rxjs is unchanged**.
+  **Node** must satisfy `^22.22.3 || ^24.15.0 || >=26.0.0` — note the
+  **22.22.3** floor, which is stricter than Angular 21's `^22.12.0`.
+
+#### 1. `ChangeDetectionStrategy.OnPush` is the new default
+
+In Angular 22 the enum is redefined: `OnPush = 0` (default), `Eager = 1`, and
+`Default = 1` is kept as a **deprecated alias of `Eager`**. Any component
+without an explicit `changeDetection` therefore switches from CheckAlways to
+OnPush — a real behaviour change for components that mutate their own state
+without signals or `markForCheck()`.
+
+An `ng update` schematic **automatically adds
+`changeDetection: ChangeDetectionStrategy.Eager` to every component that had
+none**, which keeps behaviour bit-identical. The lib took exactly this route
+(114 components) and did **not** opt into OnPush at this hop. Recommended host
+approach: let the schematic run, verify your app, and move components to OnPush
+deliberately afterwards.
+
+Watch out for components the schematic can skip — it only touches components it
+can resolve. After updating, grep for `@Component` files with no
+`changeDetection` and decide about each one; a component that is dynamically
+instantiated but never statically declared can slip through.
+
+#### 2. `provideHttpClient` now defaults to the fetch backend
+
+Angular 22 switches `HttpClient` from `XMLHttpRequest` to `fetch`. An
+`ng update` migration inserts **`withXhr()`** into your `provideHttpClient(...)`
+calls to preserve the old backend:
+
+```ts
+provideHttpClient(withXhr(), withInterceptorsFromDi())
+```
+
+The lib does this in `SmartViewContextModule`. **Hosts that call
+`provideHttpClient` themselves must do the same** (or consciously move to
+fetch). This matters most for **upload progress**: `reportProgress` events
+behave differently on the fetch backend, so if your host reports upload
+progress, keep `withXhr()` until you have retested it.
+
+#### 3. `?.` in templates now yields `undefined`, not `null`
+
+Angular 22's safe-navigation operator returns `undefined` where it used to
+return `null`. Where that difference is observable, an `ng update` migration
+wraps the expression in the **`$safeNavigationMigration()` compiler builtin**:
+
+```html
+[ngStyle]="calcStyle($safeNavigationMigration(diagramModel?.descriptor?.style))"
+```
+
+This is an official builtin (handled like `$any()` — the compiler unwraps it and
+the type-checker sees straight through it), not a temporary marker, so wrapped
+templates are safe to keep. The same `ng update` run also sets the
+`nullishCoalescingNotNullable` and `optionalChainNotNullable` extended
+diagnostics to `suppress` in your tsconfigs, which silences the `NG8107`
+warnings the Angular 21 hop introduced.
+
+#### 4. `ComponentFactoryResolver` is removed (breaking)
+
+`ComponentFactoryResolver` is gone and `ComponentFactory` is no longer public
+(it only survives as `ɵRender3ComponentFactory`). Code like this stops
+compiling with `TS2305` / `NG2003`:
+
+```ts
+constructor(private resolver: ComponentFactoryResolver) {}
+ngAfterViewInit() {
+  const factory = this.resolver.resolveComponentFactory(MyComponent);
+  this.vcRef.createComponent(factory);
+}
+```
+
+Replace it with the type-based overload — behaviour is identical (v22 builds the
+same factory internally and resolves the injector from the parent):
+
+```ts
+ngAfterViewInit() {
+  this.vcRef.createComponent(MyComponent);
+}
+```
+
+**Public-API change in the lib:** `ComponentFactoryService` no longer exposes
+its `factory` field. `createComponent()` / `destroyComponent()` keep their
+signatures, so hosts that only call those need no change.
+
+#### 5. TypeScript 6.0 deprecates `baseUrl` and `downlevelIteration`
+
+TS 6.0 raises **`TS5101`** for both options ("deprecated and will stop
+functioning in TypeScript 7.0"). Two ways out:
+
+- Remove them. `downlevelIteration` is a no-op at `target: ES2022`. `baseUrl`
+  can only go once every non-relative first-party import (`from 'projects/…'`,
+  `from 'src/…'`) is relative or covered by a `paths` entry.
+- Or silence them for now with `"ignoreDeprecations": "6.0"` in
+  `compilerOptions`. This is what the lib workspace does, because `baseUrl` is
+  still load-bearing there. It only buys time until TS 7.
+
+#### 6. Other notes
+
+- **Material 22 removed no further modules or tokens** — the CDK and Material
+  v22 migration schematics made no source changes. CDK 22 moves to a
+  package `exports` map (the per-entry-point sub-directories are gone from
+  `node_modules/@angular/cdk`), but every `@angular/cdk/*` import still
+  resolves; this only matters if you referenced those paths on disk.
+- The `.mdc-button__label { white-space: nowrap }` workaround introduced at the
+  Angular 20 hop is **still required on Material 22** — the class still appears
+  in Material's button template and Material still ships no `white-space` rule
+  for it.
+- **The control-flow migration did not re-run at this hop** (it was mandatory at
+  21). The lib still ships `*ngIf`/`*ngFor` templates; `NgIf`/`NgForOf`/
+  `NgSwitch` continue to work in Angular 22.
+- **The webpack-based builders are deprecated.** `@angular-devkit/build-angular`
+  now prints a notice recommending `@angular/build`. Nothing breaks yet, but
+  plan the switch.
+- `strictTemplates` is on by default in v22; the lib workspace was already
+  strict, so nothing changed. If your host was not strict, the `ng update`
+  migration adds `"strictTemplates": false` to keep it that way.
+- A `@HostListener('document:keydown.enter', ['$event'])` handler typed `KeyboardEvent` fails
+  with TS2345 (`Event` is not assignable); type the parameter as `Event` when the handler only
+  reads `target` (p034).
+- **An Angular CLI 1x `src/test.ts` breaks `ng test`**: `require.context` is a webpack API the
+  22 karma builder no longer provides (`__webpack_require__(...).context is not a function`,
+  0 specs run). Delete the `require.context` block; the builder collects the specs from
+  `tsconfig.spec.json` itself (p034).
+
+### The third-party packages the library does *not* own (Phase 2)
+
+Every hop section above lists the library's own peer dependencies. Your host almost
+certainly carries packages the library never sees, and those have their own Angular
+peer ceilings — each one can stop a hop dead. Measured on p014 (2026-07-29), which
+went 17 → 22 with the library still installed:
+
+- **`@swimlane/ngx-charts` needs a ladder of its own**: `20 → 22 → 22 → 23 → 24 → 25`
+  across the five hops. At the Angular 21 hop it peer-caps the CDK, and because
+  `ng update`'s own `npm` step is **not** `--force`d (even when you passed `--force`
+  to `ng update`), the install fails there while `package.json` has already been
+  written correctly. The fix both times was to redo the install by hand, not to
+  re-run the update. `p043` and `app-tournament` both carry ngx-charts `^20.4.1`
+  and will hit this; `app-fitnessmirror` and `app-finance-ai` do not.
+- **`ngx-extended-pdf-viewer` moved to `.mjs`** at the 21 hop and stopped shipping
+  `pdf-3.10.560-es5.min.js`. If your `angular.json` names that file under `scripts`
+  or `assets`, the build fails on a missing file rather than on anything Angular.
+- **`karma` and `@angular/build`**: `@angular/build` 22 declares
+  `peerOptional karma@^6.4.0`. A host pinned to `~6.3.0` gets a wall of
+  `npm warn ERESOLVE overriding peer dependency` — **warnings, exit code 0**, so it
+  is not blocking. It becomes a *hard* install failure the moment `@angular/build`
+  is a direct devDependency rather than a nested one, which is what happened in the
+  library workspace. `karma@~6.4.4` clears it.
+- **`ngx-markdown` 22 lazily imports `marked-katex-extension`**, an optional peer. The
+  application builder leaves that import alone; the webpack `browser` builder every measured
+  host still runs resolves it, and the build fails with `Can't resolve
+  'marked-katex-extension'` against ngx-markdown's own bundle. Declare
+  `katex@^0.16` and `marked-katex-extension@^5`: webpack only puts them in a lazy chunk that
+  loads when KaTeX is switched on. ngx-markdown 22 also wants `marked@^17 || ^18` declared
+  (app-formmate, 2026-09-22).
+
+The general shape: **`ng update` needs `--force` at every hop** (the library and
+PrimeNG both peer-cap at Angular 17 until the very end), and `--force` covers the
+Angular schematics but not the `npm install` they trigger. When that install fails,
+check `package.json` before assuming the hop did nothing — it is usually already
+correct.
+
+### Housekeeping (Phase 3.0)
+
+#### The dialog's built-in Ok/Cancel buttons are gone
+
+`smartdialog.component.html` no longer renders an `Ok` and a `Cancel` button.
+They were dead: their `(click)` handlers were the no-op expressions
+`(click)="(data.okCallback)"` / `(click)="(data.cancelCallback)"` — a bare
+property read, not a call — so pressing them did nothing, and the whole block
+was behind `*ngIf="!data.customComponent"`, which is never true for a host
+dialog (`SmartDialog.ngAfterViewInit` unconditionally instantiates
+`data.customComponent`).
+
+**The `okCallback` / `cancelCallback` model fields stay.** Hosts set and invoke
+them from their own `customComponent` dialogs, and that keeps working
+unchanged. Only the library-rendered buttons are gone. The `actionCallback` /
+`actionLabel` button — the one with a real handler (`onActionClick()`) — is
+untouched.
+
+Action needed: none, unless you relied on the library rendering those two
+buttons — in which case they never worked, and you should render them in your
+own dialog component.
+
+### Full standalone + `provideSmartNgClient()` (Phase 3.2) — **the big one**
+
+This is the change that rewrites your `app.module.ts`. Everything else in this
+guide is small next to it.
+
+#### Every NgModule is gone
+
+The library no longer ships a single `@NgModule`. All 58 are deleted —
+`SmartNgClientModule`, `SmartViewContextModule`, `SmartSessionModule`,
+`SmartGridModule`, `SmarttableModule`, `SmarttreeModule`, `SmartdialogModule`,
+`SmartIconModule`, `SmartNavbarModule`, `SmartFilterModule`,
+`SmartFilterEditorModule`, `SmartComponentLayoutModule`,
+`SmartExpandableSectionModule`, `SmartMapModule`, `SmartDiagramModule`,
+`SmartNavigationModule`, `SmartValidationModule`, `SmartGenericPagesModule`,
+`ComponentFactoryServiceModule`, `SharedModule`, `SmartTabGroupModule`,
+`SmartDocuStoreExplorerModule` and the generated OpenAPI `ApiModule`s.
+
+Every component, directive and pipe is now **standalone**. Import the ones your
+templates use directly, in the component that uses them:
+
+```ts
+@Component({
+  selector: 'app-my-page',
+  templateUrl: './my-page.component.html',
+  imports: [SmartGridComponent, UiActionToolbarComponent, SmartEmbeddedSlotDirective],
+})
+export class MyPageComponent extends SmartComponent<MyModel> { … }
+```
+
+**The compiler tells you what is missing** — one `NG8001: '<smart-grid>' is not
+a known element` per unresolved element, per template. Work through them; there
+is no guessing involved. In practice ~16 module imports become ~40 component
+imports spread across the components that actually use them.
+
+**The compiler does NOT tell you about the DI changes below.** Nothing fails at
+build time if you get those wrong; you find out on the first page load. Smoke
+your app.
+
+#### `provideSmartNgClient(config, ...features)` replaces the module imports
+
+```ts
+bootstrapApplication(AppComponent, {
+  providers: [
+    provideAnimations(),
+    provideRouter(ROUTES),
+    provideSmartNgClient(
+      {
+        gridMenuIcon: 'more_horiz',
+        treeMenuIcon: 'more_horiz',
+        aclEditingViewName: Pages.ACL_MATRIX_PAGE,
+        invalidSmartlinkPageName: Pages.INVALID_SMARTLINK_PAGE_NAME,
+        namedValidators: [MY_VALIDATOR_FACTORY],
+      },
+      withSmartMap({ engine: MapEngine.LEAFLET }),
+      withSmartDiagram({ customOptions: [MY_CHART] })
+    ),
+    { provide: HTTP_INTERCEPTORS, useClass: MyLoadingInterceptor, multi: true },
+  ],
+});
+```
+
+The core is always wired and cannot be forgotten: session, view context, the
+three BFF interceptors, layout, form, grid, table, tree, dialog, icon, navbar,
+filter, filter editor, validation, expandable section, navigation, shared and
+the generic pages. That is the point — the session and header interceptors used
+to be easy to leave out, and leaving them out fails *silently* (no
+`Authorization` header).
+
+Only two features are opt-in, because they pull heavy third-party code that not
+every host renders: `withSmartMap()` (leaflet / Google Maps) and
+`withSmartDiagram()` (chart.js). There is **no `withSmartTabGroup()`** —
+`smart-tab-group` had no component left, only an empty module, and is deleted.
+
+`provideSmartNgClient()` calls `provideHttpClient()` itself, with
+`withInterceptorsFromDi()` and its own three functional interceptors, and leaves the backend
+on the framework default (fetch). Your own class-based `HTTP_INTERCEPTORS` keep working and
+still run after the library's three. Pass extra `HttpClient` features in
+`config.httpFeatures` rather than making a second `provideHttpClient()` call — see
+[HTTP](#http-the-library-no-longer-forces-the-xhr-backend-phase-38), which is also where the
+6.x "do not call it twice" trap went.
+
+#### String-keyed providers become typed config fields
+
+Delete these from your providers array and pass them to `provideSmartNgClient`:
+
+| 6.x provider | 7.0 config field |
+|---|---|
+| `{ provide: 'gridMenuIcon', useValue: … }` | `gridMenuIcon` |
+| `{ provide: 'treeMenuIcon', useValue: … }` | `treeMenuIcon` |
+| `{ provide: 'searchPageName' / 'searchComponentName', … }` | `searchPageName` / `searchComponentName` |
+| `{ provide: 'genericPageName' / 'genericComponentName', … }` | `genericPageName` / `genericComponentName` |
+| `{ provide: 'subjectSelectorPageName' / 'subjectSelectorComponentName', … }` | `subjectSelectorPageName` / `subjectSelectorComponentName` |
+| `{ provide: 'validationResultPageName' / 'validationResultComponentName', … }` | `validationResultPageName` / `validationResultComponentName` |
+| `{ provide: 'noPermissionPageName' / 'noPermissionComponentName', … }` | `noPermissionPageName` / `noPermissionComponentName` |
+| `{ provide: 'invalidSmartlinkPageName' / 'invalidSmartlinkComponentName', … }` | `invalidSmartlinkPageName` / `invalidSmartlinkComponentName` |
+| `{ provide: 'aclEditingViewName', useValue: … }` | `aclEditingViewName` |
+| `{ provide: DIALOG_DISABLE_CLOSE, useValue: … }` | `dialogDisableClose` |
+| `{ provide: MAT_DATE_LOCALE, useValue: 'hu-HU' }` | `dateLocale` — **or keep the provider as it is**, which is what the codemod does; see [Dates §2](#2-leave-your-mat_date_locale-provider-alone) |
+| `SmartWidgetSettings.useUtc = true` (a static, not a provider) | **delete it** — the flag is gone with the moment adapter; see [Dates §4](#4-smartngclientconfiguseutcdates-is-removed) |
+| `{ provide: NAMED_VALIDATOR, useValue: F, multi: true }` | `namedValidators: [F]` |
+| `{ provide: SMART_DEFAULT_VIEW_COMPONENTS, useValue: E, multi: true }` | `defaultViewComponents: [E]` |
+| `SmartValidationModule.forRoot([...])` | `namedValidators` — **the element type changes**, see below |
+| `SmartDiagramModule.forRoot([...])` | `withSmartDiagram({ customOptions })` |
+| `{ provide: MAP_ENGINE, useValue: … }` | `withSmartMap({ engine })` |
+
+`'pageName'`, `'componentName'` and `'treeId'` stay as string tokens on purpose:
+they identify one component instance rather than configuring the library, and
+hosts also provide them at component level.
+
+You can also delete these from your **root** providers array — the core provides them:
+`SmartSessionService`, `SmartViewContextService`, `SmartNavigationService`,
+`SmartIconService`, `SmartFilterEditorService`, `SmartFormService`,
+`SmartCookieService`, `NamedValidatorService`, `ComponentFactoryService`, and the date
+adapter wiring (`MAT_DATE_FORMATS`, `DateAdapter`).
+
+⚠️ **`namedValidators` takes factories, not providers.** `SmartValidationModule.forRoot()`
+took `Provider[]`, so hosts wrote the wrapper by hand:
+
+```ts
+// 6.x — validator.factories.ts
+export const VALIDATOR_PROVIDER_EMPTY_INPUT: Provider = {
+  provide: NAMED_VALIDATOR, useValue: VALIDATOR_FACTORY_EMPTY_INPUT, multi: true,
+};
+// app.module.ts
+imports: [SmartValidationModule.forRoot([VALIDATOR_PROVIDER_EMPTY_INPUT])]
+```
+
+`provideSmartNgClient()` adds that wrapper itself, so the config takes the bare
+`ValidatorFactory[]`. Export the factories and pass those:
+
+```ts
+// 7.0
+export const VALIDATOR_FACTORY_EMPTY_INPUT: ValidatorFactory = { … };
+provideSmartNgClient({ namedValidators: [VALIDATOR_FACTORY_EMPTY_INPUT] })
+```
+
+The codemod moves the argument into the config and **reports it**, because the entries are
+normally named constants declared in another file and only you know what each one wraps. If
+you miss the note, `TS2322: Type 'Provider' is not assignable to type 'ValidatorFactory'`
+lands on every element.
+
+⚠️ **The same line on a `@Component` is not the same thing.**
+`providers: [SmartFilterEditorService]` on a page component asks for one instance *per page*,
+which is usually deliberate — p014 does it in five components. Leave those alone; the codemod
+does.
+
+#### The module → standalone mapping
+
+What each `Smart*Module` used to export, reduced to what 7.0 still exports publicly. An
+NgModule's `imports:` array accepts standalone components, so this substitution is all a host
+that is still NgModule-based needs to keep compiling — the codemod performs it.
+
+| 6.x module | 7.0 imports |
+|---|---|
+| `SmartNgClientModule` | the union of the fourteen it re-exported (everything below except the generic pages, the filter editor, the map and the diagram) — trim it to what your templates use |
+| `SmartComponentLayoutModule` | `SmartComponentLayoutComponent` |
+| `SmartViewContextModule` | `UiActionToolbarComponent`, `UiActionButtonComponent`, `UiActionDialogButtonComponent`, `SmartformComponent`, `SmartfileuploaderComponent`, `SmartFileEditorComponent`, `SmartMultiFileEditorComponent`, `SmartVoiceRecorderComponent`, `SmartEmbeddedSlotDirective`, `HighlightPipe` |
+| `SmartGridModule` | `SmartGridComponent` |
+| `SmarttreeModule` | `SmartTreeComponent` |
+| `SmartdialogModule` | `SmartDialog` |
+| `SmartIconModule` | `SmartIconComponent`, `UiBadgeComponent`, `UiBadgeDirective` |
+| `SmartNavbarModule` | `SmartNavbarComponent` |
+| `SmartFilterModule` | `SmartFilterComponent` |
+| `SmartFilterEditorModule` | `SmartFilterEditorContentComponent` |
+| `SmartExpandableSectionModule` | `ExpandableSectionComponent` |
+| `SmartSessionModule` | `SmartSessionTimerComponent` |
+| `SmartGenericPagesModule` | `SearchPageComponent`, `GenericPageComponent`, `SubjectSelectorComponent`, `InvalidSmartlinkComponent` |
+| `SmartMapModule` | `SmartMapComponent` + `withSmartMap({ engine })` |
+| `SmartDiagramModule` | `SmartDiagramComponent` + `withSmartDiagram({ customOptions })` |
+| `SharedModule` | `SmartTooltipDirective`, `SmartDatePipe`, `SmartDateTimePipe`, `SmartTimePipe` |
+| `SmartValidationModule` | nothing — `forRoot()`'s validators become `namedValidators` |
+| `SmarttableModule` | nothing — `SmarttableComponent` is no longer public; render a `<smart-grid>` |
+| `SmartNavigationModule`, `ComponentFactoryServiceModule` | nothing — they only carried services, which the core provides |
+| `SmartTabGroupModule` | nothing — deleted; it had no component left |
+| `SmartDocuStoreExplorerModule` (`@smartbit4all/document-explorer`) | `SmartDocuStoreExplorerComponent`, `FolderContentComponent`, `PdfViewerDialogPageComponent` |
+
+Two things this table will not tell you, and the compiler will not either: an import you no
+longer need is invisible (unused entries in an NgModule `imports:` array are not reported),
+and a name you already bind from elsewhere — a `SmartDatePipe` of your own — must not be
+imported twice. The codemod reports both cases rather than guessing.
+
+#### Your `SmartComponent` subclasses silently become OnPush
+
+This is an **Angular 22 fact rather than something 7.0.0 introduces**, but it
+lands on you at the same moment, so it is worth stating plainly: `SmartComponent`
+is an abstract `@Component`, and each of your subclasses carries its own
+`@Component` decorator. On Angular 22 a component without an explicit
+`changeDetection` gets the new `OnPush` default. p014 has 75 such subclasses,
+p043 has 70.
+
+Let the `ng update` schematic add `changeDetection: ChangeDetectionStrategy.Eager`
+to all of them (that is what the library did), verify your app, and move to
+OnPush deliberately afterwards. A subclass that mutates its own state outside a
+signal and without `markForCheck()` will stop repainting under OnPush.
+
+#### Removed from the public API
+
+A major is the only chance to narrow the surface, so these are no longer
+exported. All of them are library internals; none is used by p014, p043,
+app-formmate or `@smartbit4all/document-explorer`:
+
+- `SmarttableComponent`, `SmarttableService` — use `<smart-grid>`, which renders
+  the table internally. **All `SmartTable*` model types stay** (`SmartTableType`,
+  `SmartTableInterfaceTypeEnum`, `SmartTableHeader`, …). p043 imports
+  `SmarttableComponent` in `ad-groups.component.ts` but never uses it — delete
+  that one import line. An import is not the only way in: p009-angular created it
+  through `ComponentFactoryService` (`recommendations-page`), so grep for the class
+  name, not only for the import, and rebuild such a page on `<smart-grid>`. p034 used it
+  three times for a client-side check box table (a `<smarttable>` in a template and two
+  `ComponentFactoryService` sites) whose rows come from the host, not from a backend grid;
+  there a small host component rendering the still public `SmartTable` model with
+  `mat-table` keeps the pages, because `<smart-grid>` needs a backend grid model.
+- `GoogleMap`, `LeafletMap`, `AbstractMap` — select an engine with
+  `withSmartMap({ engine })`.
+- `SmartFilterParamComponent`, `SmartFilterParamsComponent`,
+  `SmartFilterExpressionItemComponent`, `SmartFilterExpressionItemsComponent` —
+  internals of `SmartFilterEditorContentComponent`, which stays public.
+- `HoverMenuComponent`, `ClickMenuComponent` — rendered by the ui-action toolbar.
+- `UiActionConfirmDialogComponent`, `UiActionInputDialogComponent` — opened by
+  their services, which stay public.
+- `UploadWidgetComponent`, `PhotoCaptureWidgetComponent`,
+  `VoiceRecordWidgetComponent` — contents of the ui-action upload dialog.
+- `SmartNgClientService` — deleted; it was an empty stub with no members.
+- The generated `ApiModule`s — they had no usages and their `forRoot()` told you
+  to import `HttpClientModule`, which no longer applies.
+
+Two internal string tokens are gone as well, replaced by real `InjectionToken`s
+(`'confirmDialogService'`, `'textFieldDialogService'`, `'fileUploadDialogService'`).
+No host provided them, so no action is needed.
+
+#### Behaviour notes
+
+- `<mat-slide-toggle>` in the form widget no longer carries a `value` binding,
+  `<mat-nested-tree-node>` no longer carries an interpolated `matTreeNodeToggle`,
+  and the ui-action menus no longer carry `[subActions]`. All four were dead
+  bindings that the NgModules' `CUSTOM_ELEMENTS_SCHEMA` had been hiding — they
+  wrote a DOM property nobody read. Rendering is unchanged.
+- The same schema on a **host** module hides library selectors that 7.0 no longer
+  exports: the template compiles and the element renders nothing.
+  `<smart-filter-group-params>` (p009-angular, two admin pages) is one; grep the
+  templates for `smart-` selectors that the build does not resolve.
+- The dead `ExpandableGridComponent` is deleted (it was declared in
+  `SmartGridModule` but its selector was used nowhere).
+
+### Widget ↔ SmartComponent: the model routing is inverted (Phase 3.4)
+
+A widget no longer waits to be collected by the screen component it lives in: it finds its
+`SmartComponentApiClient` through DI and registers itself. `SmartComponent` carries the
+channel as an inherited host directive, so **no host component has to be changed for the
+routing itself** — everything below is the *legacy surface* that went with the old
+collection path. The protocol is written up in `WIDGETS.md` next to this file; the decision
+record behind it is ADR-0005 in the `platform-angular2` working copy.
+
+#### What a host must delete (all of it mechanical, all reported by the compiler)
+
+| Delete | Why |
+|---|---|
+| `this.useQueryLists = true;` | The property is gone. Its setter rejected anything but `true`, so every branch behind it was unreachable — this was a no-op that logged a warning. |
+| `[parentSmartComponent]="this"` on `<smart-component-layout>` | The input is gone; the layout injects the client. `strictTemplates` reports leftovers as **NG8002**. |
+| `this.addForm(id, smartForm, formComponent)` | Gone. A `<smartform>` that displays the client's model registers itself. Two call styles existed; where the return value was used, it was the `smartForm` argument — use that (which makes those lines self-assignments, so they just go). **Delete the scaffolding around the call too**: in p014 the 21 calls left behind 9 empty `if (this.formX) { }` guards and 3 `new Promise((r) => setTimeout(r, 500)).then(() => { })` wrappers whose only content had been the registration. The compiler does not complain about either. |
+| `this.widgets.delete(…)` / `this.widgets.set(…)` / `this.formWidgets…` | The maps are gone (they were only written by the legacy path and read by nothing). |
+| the 4th argument of `addGrid(smartGrid, options, useAsDefaultGrid, componentReference)` | `addGrid()` keeps the options and the default-grid role; the services it used to copy into the grid model (`uiActionService`, `uiActionDescriptorService`, `serviceToUse`, `viewContextService`) are the grid's own DI job now. |
+| `override getSmartXxxQL()` (e.g. the two `throw new Error` overrides in a `FilterPageService`) | The eight abstract getters are gone from `SmartComponentApiClient`. |
+| `this.getSmartGridsQL()` and friends | If a component really wants its own widgets, it declares the view query itself: `@ViewChildren(SmartGridComponent) grids!: QueryList<SmartGridComponent>` — same reach as the removed getter had. |
+| `handleDataChangeSubscriptions()` | Gone. A form publishes its own value-change keys when it constructs. |
+
+Removed from the public API in the same step, in case a host imported them directly:
+`SmartComponentLayoutUtility` and its `EmbeddedSlotInfo` interface (the whole file — its
+collectors walked the layout tree for widgets, which nothing does now), and the `[parent]`
+inputs of `<smart-map>` / `<smart-diagram>` (they were bound to `parentSmartComponent` and read
+by nothing; both widgets resolve the client themselves). `initActions()` also runs less often:
+only when the model or its action list changes, no longer after every layout render, grid view
+init and filter model change — a host override that relied on one of those extra calls has to
+key off `dataChanged` instead.
+
+The [codemod](#migrating-a-host-the-codemod) deletes the first two rows and the last one, and
+lists the rest — `addForm()`, the 4th `addGrid()` argument, the getter overrides — with their
+line numbers, because each of those is a small decision rather than a substitution.
+
+#### What stays
+
+- `SmartService` — a view-less client. Its `@ViewChildren` never populated anyway; they are
+  simply gone now.
+- `initActions()` — still the hook a host overrides to build its own action list. The base
+  implementation only asks for a render; toolbars pull their actions themselves.
+- `setUpDefaultTree()` / `createTreeService()`, `addGrid()`, `submitForms()`,
+  `getInvalidFields()`, `uiActionModels` (now a getter over the model's actions).
+
+#### `uiActionModels` is read-only now — assigning to it no longer compiles
+
+It became a getter over the `actionModels` computed, so a host that *replaced* the list in
+place gets `TS2540: Cannot assign to 'uiActionModels' because it is a read-only property`.
+Measured in **p014 and p043**, `document-storage-editor.component.ts`:
+
+```ts
+// before — no longer compiles
+this.uiActionModels = this.uiActionModels.filter((a) => a.uiAction.code !== 'CANCEL');
+
+// after — filter into a field of your own and bind it
+protected readonly visibleActions = signal<UiActionModel[]>([]);
+// …
+this.visibleActions.set(this.uiActionModels.filter((a) => a.uiAction.code !== 'CANCEL'));
+```
+
+```html
+<smart-ui-action-toolbar [uiActionModels]="visibleActions()"></smart-ui-action-toolbar>
+```
+
+A plain field works just as well; what matters is that the **array reference changes**, which
+is what tells the toolbar to re-render. See also the entry-freeze note in the Phase 3.7
+section.
+
+#### Behavioural deltas, accepted
+
+- **Wider reach.** A widget in a host's *own* sub-component now participates, where a view
+  query could not see it (measured on p014/p043: 5 toolbars and 3–4 forms per host). A form
+  takes part only if it displays the client's component model, which is what the forms the
+  queries used to find have in common; a form that renders something else of its own (a
+  search box, a field editor) does not.
+- Two widgets sharing one identifier both reload; the old map kept only the last.
+- `getInvalidFields()` collects in subscription order rather than view order — visible only
+  in the order of the names in the validation dialog.
+- A toolbar entry is tracked by a synthesized key (action code + ordinal among entries with
+  the same code), so a button's DOM node — with its focus and ripple — follows its action
+  across reordering. Rendering is otherwise identical.
+
+#### `[smartComponentDetached]`
+
+The one brake on the automatic registration. Put it on an element whose subtree deliberately
+renders something other than the client's model; widgets below it resolve an empty slot and
+neither reload nor take part in submit/validation.
+
+```html
+<div smartComponentDetached>
+  <smart-grid [smartGrid]="ownGrid" [uuid]="ownUuid"></smart-grid>
+</div>
+```
+
+#### `SmartSubject` is deleted
+
+It was a no-op wrapper over `Subject`: `subscription.add(this.unsubscribe$.subscribe())`
+registers the teardown in the wrong direction, so after `destroy$.next()`, `.complete()` or
+`.unsubscribe()` subscribers still received values. Replace `new SmartSubject(destroy$)`
+with `new Subject()`; where a subscription really must die with a component, use
+`takeUntil(this._destroy$)` (which is what actually stopped delivery all along) or
+`takeUntilDestroyed()`. No host used it.
+
+### Toolbars resolve their own actions and own the execution context (Phase 3.5)
+
+One rule decides which actions a toolbar shows, and the toolbar — not each list entry —
+says who performs them. `WIDGETS.md`, *Toolbars*, is the short version; the decision record
+behind it is ADR-0006 in the `platform-angular2` working copy.
+
+> A toolbar renders the actions **addressed to its `id`** (`uiAction.toolbar == id`). The
+> list comes from an explicit `[uiActionModels]` binding if there is one, otherwise from the
+> screen component above it in the DOM. **Without an `id` it never pulls** — "unaddressed" is
+> not an address, so a toolbar with neither an id nor a binding shows nothing.
+
+`[uiActionModels]="uiActionModels"` therefore keeps meaning "put my page's unaddressed
+actions here" and needs no change.
+
+#### `UseUiAction` is deleted; `UseUiAction2` is now `UiActionExecutor`
+
+There is one executor interface. If a host class implements `UseUiAction` — a `submit` /
+`reSubscribeToChange` subject handshake — replace the two subjects with the two methods:
+
+```ts
+// before
+export class DelegateInboxDialogService implements UseUiAction {
+  submit: Subject<void> = new Subject();
+  reSubscribeToChange: Subject<void> = new Subject();
+  …
+}
+
+// after
+export class DelegateInboxDialogService implements UiActionExecutor {
+  submitForm(validate: boolean): void {
+    this.submit.next();   // keep the subject if a component subscribes to it
+  }
+  getInvalidFields(): SmartFormInvalidFields {
+    return { invalidFieldKeys: [], invalidFieldNames: [] };
+  }
+  …
+}
+```
+
+`Subject.next()` is synchronous, so a component that subscribed to `submit` has already run
+by the time `submitForm()` returns — which is exactly what the old handshake tried to
+express. Keep `reSubscribeToChange` only if something subscribes to it; the library no longer
+fires it.
+
+This also **fixes a silent hang**: the old branch `await`ed `submit.toPromise()`, which only
+settles when somebody `complete()`s the subject. Three of the five implementors never did, so
+a `submit`/`model` action on those services waited forever.
+
+#### `UiActionService.execute()` lost its first argument
+
+It was always `uiActionModel.uiAction`:
+
+```ts
+- this.uiActionService.execute(uiActionModel.uiAction, uiActionModel);
++ this.uiActionService.execute(uiActionModel);
+```
+
+#### The execution context moved from the entry to the toolbar
+
+| what | bind on the toolbar | entry field (still honoured) |
+|---|---|---|
+| who performs the action | `[executor]` | `serviceToUse` — **deprecated** |
+| which widget it runs against | `[widgetId]` | `widgetId` — **deprecated**, wins if set |
+| which row inside it | `[nodeId]` | `nodeId` — **deprecated**, wins if set |
+| extra params for every action | `[actionParams]` | (clone the `UiAction` — no longer necessary) |
+
+`[executor]` defaults to the screen component the toolbar sits under, which is what almost
+every entry named. Bind it only when the actions belong to another API — a tree service, a
+filter editor, a dialog service of your own:
+
+```html
+<smart-ui-action-toolbar [uiActionModels]="actions" [executor]="myService"></smart-ui-action-toolbar>
+```
+
+`[actionParams]` replaces cloning a `UiAction` per row just to inject a model:
+
+```html
+<smart-ui-action-toolbar
+  [uiActionModels]="rowActions"
+  [widgetId]="gridId"
+  [nodeId]="row.id"
+  [actionParams]="{ model: row }"
+></smart-ui-action-toolbar>
+```
+
+#### Removed from the public API
+
+| Removed | Replacement |
+|---|---|
+| `UseUiAction` | `UiActionExecutor` (see above) |
+| the third `SmartTable` constructor parameter and `getServiceToUse()` | nothing — the executor no longer travels through the table (0 host call sites) |
+| `SmartformComponent.getToolbars()` | nothing collects toolbars any more; each one resolves its own actions |
+| `ISmartFilterEditorService.get/setComplexToolbars()` and the `submit` / `reSubscribeToChange` members | as above |
+| `FileEditorToolbarComponent` | a plain `<smart-ui-action-toolbar>` with `[actionParams]` |
+| `SmartGridComponent.setupToolbar()` / `.toolbar` / `.headerToolbar` | the id is a binding; there is nothing to reach into |
+
+#### Behavioural deltas, accepted
+
+- A widget renders a toolbar exactly when its model carries a `toolbarId`, with no type list.
+  A `toolbarId` on a type whose template has no place for a toolbar (`RECORDING_UPLOADER`)
+  now logs a warning instead of being silently dropped.
+- Only the actions a toolbar actually shows are scheduled. Since 3.4 a toolbar armed every
+  scheduled action of the view, so one action could fire from several toolbars at once.
+- A grid row's actions are no longer cloned per row; the row model travels as
+  `[actionParams]`. The multi-file editor's per-file toolbars appear when their own list
+  resolves rather than when a hidden sibling's did, and the tree's `doAction` clones instead
+  of mutating the caller's `UiAction`.
+
+### The form widget's rendering decisions (Phase 3.6)
+
+Nothing here needs a code change in a host — there is no API to adapt to. What
+changes is what the widget puts on the page, so read this before you compare
+screenshots.
+
+#### Every widget carried a spare empty wrapper; it is gone
+
+The `COMPONENT` branch's wrapper had no type guard, so
+`<div class="widgetContainer"><div class="widgetContent"><ng-template
+#customComponent>` rendered after **every** widget of every type. Measured on the
+playground: 14 widgets, 28 `.widgetContainer` — one spare, empty, per widget.
+
+The library's own CSS puts no box properties on `.widgetContainer`, so most pages
+will look identical. **Yours may not**, if you style that class with anything that
+occupies space. Both in-house hosts do, on one page:
+
+```css
+/* p014 + p043, dossier-publication.component.css */
+:host ::ng-deep .widgetContainer { margin-bottom: 0.5rem !important; }
+```
+
+There, every widget loses half a rem of trailing space. Grep your stylesheets for
+`.widgetContainer` and check the pages the matching selectors reach. Rules that
+need content still match what they always matched — an empty wrapper never
+satisfied `.label.widgetContainer` or `.widgetContainer:has(…)`.
+
+#### `MATRIX` and `YOUTUBE_PLAYER` now obey `isVisible` and get their `cssClass`
+
+Those two branches sat outside the `@if (isVisible)` guard and outside the
+`<div [ngClass]="cssClass" class="container">` every other type lives in, so
+`isVisible: false` did not hide them and `cssClass` never reached them. Both are
+inside now. If a backend view relies on a matrix rendering while marked invisible,
+it will stop rendering.
+
+#### A container keeps its invisible children
+
+A `CONTAINER` widget's `ngOnInit` used to overwrite `widgetInstance.valueList`
+with the visible subset, destroying the invisible children in the model the
+backend sent. The visible subset is derived per check now, so the model stays
+whole and a later `applyConstraints()` that flips a child's `isVisible` brings it
+back — which it could not before. The DOM is unchanged: the same children render.
+
+Side effect worth knowing: the model walks that recurse into a container's
+`valueList` (`applyComponentConstraints`, `copyValueFromFormToWidgetBeans`,
+`translateWidgets`) now see the invisible children too. Their form controls always
+existed — `createFormControls` runs over the whole model before any widget renders
+— so this only makes the widget beans agree with the controls.
+
+#### A YouTube shorts link resolves
+
+`parseYoutubeUrl` threw away its own `replace('/shorts/', '/watch?v=')`, so a
+shorts link produced no player. It plays now.
+
+#### Removed from the public API
+
+| Removed | Replacement |
+|---|---|
+| `SmartformwidgetComponent` | nothing — no host imported the class; `<smartform>` still renders it. 7.3 splits it into per-type components |
+| `SmartWidgetSettings` (its only member was `static useUtc`) | nothing — **delete the assignment** |
+
+3.6 moved the `useUtc` static into `SmartNgClientConfig.useUtcDates`; **3.8 then removed the
+field altogether**, together with the moment adapter it fed. If you set
+`SmartWidgetSettings.useUtc = true` before bootstrap, delete that line and read
+[Dates §4](#4-smartngclientconfiguseutcdates-is-removed) — the timezone contract is fixed now,
+and the flag defaulted to `false` everywhere anyway.
+
+#### What deliberately did not change
+
+A required field is marked in both label positions, by two different mechanisms:
+a shown label (`showLabel: true`) is the widget's own `<h4>` and carries a literal
+` *`; a `mat-label` sits inside a `mat-form-field`, which renders
+`.mat-mdc-form-field-required-marker` from the control's own validators. That is
+why `getWidgetLabel` ties its asterisk to `showLabel` — dropping the condition
+would mark the floating label twice.
+
+### Change detection: frozen action entries, no zone.js (Phase 3.7)
+
+7.0 runs without zone.js. Every component of the library is `OnPush` — nothing is checked
+just because something, somewhere, ticked — and the library says when its own state changed.
+Two consequences reach a host.
+
+#### A `UiActionModel` is frozen: build an entry, never edit one
+
+Every field is `readonly`, and `[uiActionModels]` takes `readonly UiActionModel[]`.
+
+```ts
+// before — compiles on 6.x, and on 7.0 changes nothing on screen
+entry.cssClass = 'active-nav-action';
+
+// after
+this.actions = this.actions.map((a) =>
+  a.uiAction.code === code ? { ...a, cssClass: 'active-nav-action' } : a
+);
+```
+
+Measured across the 12 hosts in scope (2026-07-28): **72 sites in 7 hosts**, all of them
+`cssClass` — p009-angular alone has 38, p014 and p043 12 each. The codemod prints every one
+of them with its line number; it cannot rewrite them, because only you know which array the
+entry belongs to.
+
+The compile error and the fix are the same thing. Writing into an entry that a toolbar is
+already rendering never reached the screen under zone.js either — it worked only because
+some other event happened to tick the application. Rebuilding the array is what actually
+re-renders.
+
+**The gap this does not close.** `this.actions[0] = { ...this.actions[0], cssClass: 'x' }`
+compiles: `actions` is your field, and the freeze only covers the entries. It keeps the same
+array reference, so the toolbar does not re-render. Reassign the array — or, if you hold it
+in a `signal`, `update()` it.
+
+**A component's own toolbar entries come from its `actionModels` signal.** The 6.x pattern
+`this.uiActionModels.forEach((a) => (a.cssClass = 'eji-button'))` in `initActions` becomes an
+override of that signal, which bound, pulled and layout-embedded toolbars all read:
+
+```ts
+// the helper runs while this.actionModels is still the base class's signal
+function withCssClass(component: SmartComponent<any>, cssClass: string) {
+  const source = component.actionModels;
+  return computed(() => source().map((a) => ({ ...a, cssClass })));
+}
+
+override readonly actionModels = withCssClass(this, 'eji-button');
+```
+
+Reading `this.actionModels` directly in its own initializer is `TS2729`; passing `this` to a
+function is what captures the base signal (p009-angular, `src/app/utils/action-css-class.ts`).
+A host field of its own named `actionModels` now collides with the base signal
+(`TS2416` + `TS4114`): rename it.
+
+When the mapping reads the component's data (mark the entry of `data.currentPage`), read
+`component.modelSignal()` inside the `computed` as well: `data` is a plain field, so without it
+the class does not follow a data change that leaves the action list alone (p034,
+`src/app/utils/action-models.ts`).
+
+The descriptor a toolbar resolves is no longer written back into the entry either. Nothing
+outside the toolbar read it; if you did, resolve it yourself through
+`UiActionDescriptorService.getActionDescriptor(uiAction)` — which is
+[synchronous in 7.0](#getactiondescriptor-is-synchronous-phase-39).
+
+#### Client-side translation is gone
+
+`SmartTranslateService`, `viewContext.translateService` and the `translateServiceChanged`
+subject are removed, together with `originalLabel` / `originalPlaceholder` on the widget
+interfaces, and the `translateService` field of `SmartForm`, `SmartGrid` and `SmartFilter`. The
+backend localizes server-side, and in p014/p043 the three references were unused imports.
+
+**A host that sends translation keys still needs translating.** p009-angular keeps ngx-translate
+keys in its client-built forms, its client action descriptors and its titles; deleting the
+calls would put raw keys on screen. It now translates in the host: the widget labels,
+placeholders, validator messages and item labels when a form is built, and the descriptor map
+on every `onLangChange`, with `bootstrap.start()` waiting for the language to load. **Grid
+column headers and filter labels have no host-side replacement**: they show what the backend
+sends, so localize them on the backend. A page that read `this.translate` without assigning it
+got `undefined` already on 6.x (the base class never set it), so check what a title showed
+before calling a now-translated one a regression.
+
+What the frontend authors itself is now configuration:
+
+```ts
+provideSmartNgClient({
+  errorDialog: { title: 'Hiba', message: 'Váratlan hiba történt.', buttonLabel: 'Rendben' },
+});
+```
+
+`SmartViewContextService.getSmartViewContextApiErrorByCode()` is no longer `async`.
+
+**`SmartComponent` no longer has a `translate` member**, and a host that injected
+ngx-translate's `TranslateService` under that name as `override translate: TranslateService`
+now gets `TS4113` on every such constructor (app-formmate had 22). Do not just delete
+`override`: it was also what made the parameter a property, so without an access modifier
+`this.translate` disappears. Write `public translate: TranslateService` — and keep `override`
+on subclasses of your own pages, which now override *your* base class instead of the library's.
+
+#### If your host still bootstraps with zone.js
+
+Nothing forces you to drop it — the library works either way, because it no longer depends
+on an application-wide tick. The playground runs `provideZonelessChangeDetection()` with no
+`zone.js` polyfill, and that is the configuration 7.0 is tested in.
+
+If you do go zoneless, the same rule applies to your own components: state written from a
+subscription, a promise or a timer needs a signal or a `markForCheck()`; state written from a
+template event or an input does not.
+
+### Dates: moment → date-fns, and the timezone contract (Phase 3.8)
+
+**This section needs action at install time.** The reasoning is ADR-0008 in the
+`platform-angular2` working copy; the contract itself is stated in §4 below.
+
+#### 1. Swap the peer dependency
+
+`@angular/material-moment-adapter` is out of the library's `peerDependencies`;
+`@angular/material-date-fns-adapter` and `date-fns` are in. `date-fns` is listed explicitly
+rather than left transitive, because the library imports `date-fns/locale` itself.
+
+```bash
+npm uninstall @angular/material-moment-adapter moment
+npm install @angular/material-date-fns-adapter@^22.0.0 date-fns@^4
+```
+
+If your own code imports moment for something unrelated, keep it — nothing here forces its
+removal, only the adapter's.
+
+**But check *how* it imports moment.** `import * as moment from 'moment'` stops being callable
+under `moduleResolution: "bundler"`, which the Angular 20 hop turns on: moment is an
+`export =` module, and a namespace import of one is not a callable value. The symptom is
+**`TS2349: This expression is not callable`** on every `moment(...)` call, and it arrives at the
+Angular 20 hop rather than at this step. Two ways out:
+
+- `esModuleInterop: true` plus `import moment from 'moment'` — correct, but it changes how every
+  CommonJS import in the app resolves, which is a wide blast radius for one file.
+- Replace the calls. Worth checking first how much moment is actually doing: in p014 the three
+  surviving calls were `moment(new Date()).toDate()` (i.e. `new Date()`) and two moments compared
+  with `<=` (`Date` compares through `valueOf()` identically). All three became plain `Date`s, and
+  **nothing under `src/` imported moment any more** — so the `npm uninstall … moment` above was
+  right for that host after all, just for a reason nobody predicted.
+
+#### 2. Leave your `MAT_DATE_LOCALE` provider alone
+
+If you have this line — p014 and p043 both do — **keep it as it is**:
+
+```ts
+{ provide: MAT_DATE_LOCALE, useValue: 'hu-HU' },
+```
+
+The strict reading of the date-fns adapter would require a `Locale` **object** here, and a bare
+string would throw inside date-fns the first time a user opened a date field. The library's
+`SmartDateFnsAdapter` accepts both: it resolves `'hu'` / `'hu-HU'` / `'en'` / `'en-US'`
+(case-insensitively) to a date-fns locale, passes a real `Locale` object through untouched, and
+falls back to Hungarian with a `console.warn` for anything else.
+
+So: **hosts on Hungarian or English need no change.** For any other language, provide a real
+date-fns locale:
+
+```ts
+import { de } from 'date-fns/locale';
+…
+{ provide: MAT_DATE_LOCALE, useValue: de },
+```
+
+`SmartNgClientConfig.dateLocale` is unchanged — still a `string`, still defaulting to `'hu-HU'`.
+
+#### 3. If you override `MAT_DATE_FORMATS`, your format strings will throw — and you probably want to delete the override
+
+Measured across 12 hosts on 2026-07-28: three of them (**p014**, **p043**, **p009-angular**)
+provide their own formats next to the locale, and two more (`app-vlab`, `app-tournament`) have the
+same line commented out:
+
+```ts
+{ provide: MAT_DATE_FORMATS, useValue: MY_FORMATS },
+```
+
+with
+
+```ts
+export const MY_FORMATS = {
+  parse:   { dateInput: 'YYYY.MM.DD' },
+  display: { dateInput: 'YYYY.MM.DD', monthYearLabel: 'YYYY',
+             dateA11yLabel: 'LL', monthYearA11yLabel: 'YYYY' },
+};
+```
+
+Those are **moment tokens**. date-fns treats `YYYY`, `DD`, `YY` and `D` as *protected* and throws a
+`RangeError` on them, and its `LL` means something else entirely (stand-alone month, not a
+localized long date). So this override **crashes at runtime, on the first screen with a date
+field** — the same failure shape as the string locale above, and just as invisible to the compiler.
+
+**The fix is almost certainly deletion.** That `MY_FORMATS` exists to render `YYYY.MM.DD`, which is
+exactly what the library's own `SMART_DATE_FORMATS` now produces (`2026.07.28.`). Drop the
+provider and the constant and you get the format you wanted, plus the more forgiving parsing.
+
+If you genuinely need a different format, translate the tokens rather than copying them:
+
+| moment | date-fns |
+|---|---|
+| `YYYY` | `yyyy` |
+| `DD` | `dd` |
+| `LL` | `PP` (or spell it out: `yyyy. MMMM d.`) |
+| `MMM YYYY` | `yyyy. LLL` |
+
+Note that the library's `parse.dateInput` is an **array** — `DateFnsAdapter._parse` tries each entry
+in turn (and ISO-8601 first), so you can list several accepted spellings instead of one.
+
+#### 4. `SmartNgClientConfig.useUtcDates` is removed
+
+Delete it if you set it. No known host does. It existed for a client-configurable timezone that
+was abandoned as a requirement; the contract is now fixed and explicit:
+
+> **The browser's zone on screen. Zulu (`…Z`) on the wire. The server converts.**
+
+This is unchanged behaviour in practice — `useUtcDates` defaulted to `false`, and the moment
+adapter with `useUtc: false` behaves exactly like a plain `Date`.
+
+#### 5. What a date widget's value now *is*
+
+Form control values from the date pickers are plain **`Date`** objects, where they were
+`Moment` objects. The values reach your backend through a `UiActionRequest` param, so the wire
+format is `JSON.stringify` of that value — and `Date.toJSON()` emits the same ISO-8601 UTC string
+`Moment.toJSON()` did. **Nothing changes on the wire.** Only host code that read a value out of a
+form control and called a moment method on it (`.format()`, `.add()`, `.startOf()`) needs
+rewriting; the platform APIs never exposed a `Moment` in a signature.
+
+#### 6. The one visible difference
+
+Date inputs render **`2026.07.28.`** where 6.x rendered `2026.7.28.` — the documented `YYYY.MM.DD`
+convention. The old rendering was not a decision: `MAT_MOMENT_DATE_FORMATS` used moment's `'l'`,
+which strips the zero padding off the Hungarian `L`. Typed input is **more** forgiving than 6.x,
+not less: `2026.07.28.`, `2026.07.28`, `2026.7.28.`, `2026.7.28` and ISO-8601 are all accepted.
+
+The month picker is unchanged (`07/2026`), and grid/table date columns were never affected —
+`SmartDatePipe` and friends extend Angular's own `DatePipe` and never used moment.
+
+**Verified on a running host** (p014, 2026-07-29, live backend, `Europe/Budapest`). Picking
+2026-07-15 in a `Kezdődátum` field gave, end to end:
+
+| | |
+|---|---|
+| input | `2026.07.15.` |
+| widget value | `instanceof Date` — not a moment, not a luxon `DateTime` |
+| `JSON.stringify` of that value | `"2026-07-14T22:00:00.000Z"` |
+| `getHours()` | `0` |
+
+That third row is the whole contract in one line: the value's `toJSON()` **is** the wire format
+(see §4), and it is zulu, while the screen and `getHours()` stay local — 15 July 00:00 CEST is
+14 July 22:00 UTC. A grid column on the same host rendered `2026.04.20 0:03`, confirming the
+untouched pipe path.
+
+### HTTP: the library no longer forces the XHR backend (Phase 3.8)
+
+`provideSmartNgClient()` used to pass `withXhr()` to its internal `provideHttpClient()` call,
+overriding the Angular 22 default on your behalf. It no longer does — the application runs on the
+framework default **fetch** backend.
+
+For almost every host this is invisible. The one behavioural difference that matters: **the fetch
+backend does not support upload progress.** A request with `reportProgress: true` and a body
+throws `NG2824` instead of emitting `HttpUploadProgress` events.
+
+Measured 2026-07-28 across 12 hosts: **`reportProgress: true` and `observe: 'events'` appear
+nowhere** outside the generated API services' unused parameters. So this is a theoretical risk for
+the current host set, not a live one. If *your* code does ask for upload progress, pass the
+feature back in:
+
+```ts
+import { withXhr } from '@angular/common/http';
+
+provideSmartNgClient({ httpFeatures: [withXhr()] })
+```
+
+The upside is that the "**do not call `provideHttpClient()` twice**" trap this guide warned about
+is gone rather than merely documented: a second call now re-provides the same backend the library
+already uses. The library's interceptors were never at risk from it — they are `multi` providers.
+
+### `getActionDescriptor()` is synchronous (Phase 3.9)
+
+`UiActionDescriptorService.getActionDescriptor(uiAction)` returns a `UiActionDescriptor`.
+It used to return a `Promise<UiActionDescriptor>`, and it was `async` for exactly one
+reason: the client-side translation layer that [Phase 3.7](#client-side-translation-is-gone)
+retired. Nothing it reads has been asynchronous since, so every caller was awaiting a value
+that was already there.
+
+**If you only `await` the call, you are already fine.** `await` on a non-promise is legal
+TypeScript, so this compiles and behaves identically before and after. The codemod drops the
+`await` anyway, so the code stops claiming an asynchrony that is not there:
+
+```ts
+const descriptor = await this.uiActionDescriptor.getActionDescriptor(uiAction);   // 6.x
+const descriptor = this.uiActionDescriptor.getActionDescriptor(uiAction);         // 7.0
+```
+
+Two shapes genuinely break. Measured 2026-07-28 across the 12 hosts in scope: **5 hosts,
+7 sites** — and none of them in a host's own `getActionDescriptor**s**()` map helper, which
+is an unrelated API and is left alone.
+
+**1. A subclass that overrides it** — `TS2416`, because `Promise<UiActionDescriptor>` is not
+assignable to `UiActionDescriptor`. Found in three hosts, as a byte-identical
+`MdmUiActionDescriptorService`. **The codemod rewrites this one.**
+
+```ts
+// 6.x
+override async getActionDescriptor(uiAction: UiAction): Promise<UiActionDescriptor> {
+  let d: UiActionDescriptor = await super.getActionDescriptor(basicUiAction);
+  …
+}
+
+// 7.0
+override getActionDescriptor(uiAction: UiAction): UiActionDescriptor {
+  let d: UiActionDescriptor = super.getActionDescriptor(basicUiAction);
+  …
+}
+```
+
+This is also the service you hand to a toolbar through `[uiActionDescriptorService]`, so a
+host with a custom one hits this at compile time rather than on screen.
+
+**2. `.then(…)` on the result** — `TS2339`, because a descriptor has no `.then`. Found in
+two hosts, four sites. **The codemod reports this one and does not rewrite it**: turning a
+callback into straight-line code means moving its body, which is a judgment call. The fix is
+mechanical anyway — assign, then inline:
+
+```ts
+// 6.x
+constructForm() {
+  this.actionDescriptorService.getActionDescriptor(this.uiAction).then((d) => {
+    this.buttonTitle = d.title;
+    this.buttonColor = d.color;
+  });
+  …
+}
+
+// 7.0
+constructForm() {
+  const d = this.actionDescriptorService.getActionDescriptor(this.uiAction);
+  this.buttonTitle = d.title;
+  this.buttonColor = d.color;
+  …
+}
+```
+
+If the callback was the reason a field lived in a `signal` — because the value arrived after
+the first render — it no longer needs to. The library made that same simplification in its
+own three action dialogs and its snack bar.
+
+**What went synchronous with it, inside the library:** the toolbar's descriptor resolution,
+`SmartGridComponent`'s header construction, and `SmartTreeGenericService.cacheActionDesciptors()`
+and **`syncTree()`**. `syncTree()` now returns `void`, which is what
+`SmartTreeServiceInterface` always declared; a host that calls it and discards the result —
+the only shape measured — needs no change, and a host that `await`s it still compiles.
+
+#### The same cleanup, elsewhere: `SmartdialogService.closeDialog()` returns `void`
+
+A sweep for the same shape found eight more library functions declared `async` with nothing
+asynchronous in them. Only one of them is on a surface a host touches:
+**`SmartdialogService.closeDialog(stopPropagate?)` returns `void`** instead of
+`Promise<void>`.
+
+**Nothing to do.** Both measured hosts that extend `SmartdialogService` override this method
+as `override async closeDialog(): Promise<void>`, and that **still compiles**: TypeScript
+accepts any return type where the base declares `void`. `await this.closeDialog()` keeps
+compiling too. This is the difference from `getActionDescriptor` above — that one returns a
+*value*, which is why the same override shape fails there with `TS2416` and not here.
+
+You may of course drop the `async` from your own override; nothing requires it.
+
+### Upload actions now wait for the server, and report their failures (Phase 3.9)
+
+**This one changes behaviour, on purpose.** `SmartViewContextService.performUploadAction()`
+and `performUploadMultipleAction()` used to start the upload and resolve immediately,
+without waiting for it and without passing on its failure. Every other action in the family
+(`performAction`, `performWidgetAction`, `performWidgetMainAction`, `dataChanged`) always
+waited; the two upload ones were an omission.
+
+Two things follow, and both are visible in a running app:
+
+1. **An upload action now blocks until the server has answered.** Before, the action was
+   "done" the moment the request went out — so `UiActionService` showed its success snackbar
+   over an upload that was still in flight, and anything the action was sequenced before ran
+   against a view the server had not updated yet. Now the snackbar appears when the upload
+   really has succeeded. On a large file that is a longer wait than 6.x showed you.
+
+2. **A failed upload now reaches your error handling.** The rejection used to be dropped —
+   it became an unhandled promise rejection, `UiActionService`'s `catch` never ran, and the
+   user was told the upload had worked. It now propagates, which means
+   `setActionErrorHandler()` (or the default error dialog) will fire on upload failures it
+   never fired on before. **If your host reports "new" upload errors after upgrading, they
+   are not new** — they were happening silently.
+
+Multi-file uploads also go out **one batch at a time** now. The batches were already being
+computed from the descriptor's `maxSize` and `maxBatchSize`, but they were then all sent at
+once, which put the whole set on the server simultaneously and defeated the split. If your
+backend measured upload concurrency, this is why it drops.
+
+Nothing to change in host code.
+
+### New in 7.0: a grid row can render a backend layout (#29717)
+
+A card-mode grid row that carries `layoutDescriptor.componentLayouts['GRID_ROW_LAYOUT']`
+renders that layout instead of the card component the host registered under
+`'<GRID_ID>Card'`. Both branches stay: a row without the descriptor behaves exactly as
+before, and this needs no host change.
+
+Two consequences worth knowing if you style or extend it:
+
+- The rendered layout's root element gets the `gridCardLayout` class, applied by the card to
+  its own child rather than pushed into the `style.classesToAdd` of the object the backend
+  sent. Nothing mutates the server model.
+- **The row's actions reach the layout's toolbars by a pull, not a walk.** The card provides
+  a `SmartActionHost` for its row subtree and writes the row's action list into it; a toolbar
+  inside the layout resolves that host before falling back to the page client. If you build
+  a component that owns such a subtree, do the same — `WIDGETS.md`, *Toolbars*.
+
+This shipped in 7.0.0 rather than as a 6.0.3x patch because it is built on the inverted
+widget contract that 7.0 introduces.
+
+### Table detail rows: rendered on demand, `example-*` classes renamed (7.0.10)
+
+The Material table used to define its expandable detail row the way the Angular Material
+example does: a second `matRowDef` rendered under **every** data row, kept at zero height
+with `tr.example-detail-row { height: 0 }` and an `@angular/animations` trigger. Any host
+rule that gave table cells vertical padding, or rows a height, made those empty rows visible
+— the p043 report — and every table carried twice its rows in the DOM.
+
+Now the detail row exists only in an expandable table (`SmartTable.expandable`), and only
+under the row that is expanded. There is nothing a host stylesheet can inflate. Expanding
+and collapsing animate through the native `animate.enter` / `animate.leave` of Angular 20.2+
+(a `grid-template-rows: 0fr ↔ 1fr` keyframe, as `mat-expansion-panel` does it), so the table
+no longer uses `@angular/animations` at all.
+
+The classes lost their `example-` prefix, taken over from the Material sample:
+
+| 6.x | 7.0.10 |
+|---|---|
+| `example-element-row` | `smart-table-row` |
+| `example-expanded-row` | `smart-table-row-expanded` |
+| `example-detail-row` | `smart-table-detail-row` |
+| `example-element-detail` | `smart-table-detail` |
+
+`.example-element-diagram`, `-symbol`, `-description` and `-description-attribution` — the
+sample's own styles, referenced by nothing — are gone.
+
+What to do in a host:
+
+- Rename the classes in any stylesheet that targets them. The usual suspects are a hover
+  rule on `tr.example-element-row:not(.example-expanded-row)` and a
+  `:host ::ng-deep tr.example-detail-row { display: table-row !important }` in a page that
+  expands rows; the latter can simply be deleted, the row is rendered when it is needed.
+- A data row now carries its own bottom border. Before, the always-present detail row drew
+  it, and the data row's border was turned off to avoid a double line. Nothing changes on
+  screen unless you drew your own row separators to compensate.
+
+### Writing your own widget
+
+`WIDGETS.md`, next to this file, is the protocol: how a widget finds its screen component
+through DI and registers itself, when to opt out with `[smartComponentDetached]`, what has to
+be a signal now that there is no zone, how a toolbar resolves its actions, and the three
+traps that have actually bitten (imperatively-fed inputs cannot be signal inputs; `@for`
+tracking over backend objects; clear-then-apply styling).
+
+In 6.x this was not possible at all — `SmartComponentApiClient` collected its children with
+eight `@ViewChildren` over eight concrete widget classes.
+
+### Imperatively created components are given their inputs properly
+
+`ComponentFactoryService` creates the components the library instantiates by hand — grid
+cards, expanded rows, table cell components, the expandable section's content, the form's
+`COMPONENT` widget, the filter editor's field editors — and most of those classes come from a
+host. It used to write their inputs by assigning the field. Two things follow, and both are
+fixed:
+
+- **A declared input is now written with `ref.setInput()`**, i.e. the same way a template
+  binding writes it. So a **signal input** works (assignment used to overwrite the input
+  function with the value, and the component's next `this.x()` threw `x is not a function`),
+  an **aliased** input is addressable under either name, and **`ngOnChanges` runs**.
+- **Falsy values arrive.** The old guard was `if (value)`, so `false`, `0` and `''` never
+  reached the component. Only `undefined` is skipped now, which keeps meaning "not passed".
+
+If your component takes something from the library this way and the key is **not** a declared
+input, the field is still assigned — nothing breaks — but you get one `console.warn` per
+component type and key. Declaring it with `@Input()` (or as a signal input) is the fix.
+
+**Check your falsy defaults.** If a host component relied on the old guard — expecting to
+keep its own default when the library passed `false` or `''` — it now receives the value.
+This is the only part of 7.0 where a bugfix can change what you see on screen without any
+code of yours changing.
+
+### Model sync: the client's models travel with every call (7.1.0)
+
+Whether an action carried the page model used to be a per-action decision of the backend
+(`UiAction.submit` / `model` / `composite`) plus one hidden rule (an action with no params sent
+it anyway), and the model travelled under three ad-hoc `params` keys (`model`, `clientPageModel`,
+`compositeModel`) that only one endpoint wrote into the backend view automatically. The bug that
+forced the change: an action on an embedded view sent only its own model, the handler changed the
+container's model, the container's whole component model came back, and whatever the user had
+typed into the container since the last round-trip was gone.
+
+From 7.1.0 the client sends, with **every** action, widget action, upload and grid selection
+call, the data of **every open view that changed since it was last synced** — slot-hosted and
+dialog views alike — in a new `UiActionRequest.modelSync.models` map keyed by view uuid. The
+backend writes each one into the matching view **before the handler runs and before it takes the
+base of its change push**, so a handler always sees what is on screen and the client's own values
+are never echoed back. A view equal to its last synced copy is left out; a view without a copy is
+always sent.
+
+**Backend minimum, and the server switch.** The platform build that ships
+`UiActionRequest.modelSync` (platform ADR-0011 on the server side), **with model sync switched
+on**: `view.model-sync.enabled=true` in the host's `application.properties`. The switch defaults
+to `false`, and in that mode the server behaves exactly as before model sync existed: nothing is
+written into the views before the handler, and a request that carries `modelSync` is **rejected**
+with an error naming the property, not ignored. A 7.1.0 client sends the envelope with every
+call, so against a server with the switch off every call fails loudly; against an older platform
+the field is silently ignored and every handler that read `params.model` sees nothing. **Order:
+upgrade the backend, set the flag, then upgrade the client.** Server code can read the mode as
+`viewApi.isModelSyncEnabled()`.
+
+**A 6.x client against a backend with the switch on** is rejected too: with
+`view.model-sync.enabled=true` every request that can carry `modelSync` — an action, a widget or
+upload action, a tree action, a grid selection change — must carry it, and one without it (an
+old client, or host code that builds a `UiActionRequest` by hand and calls the view context
+service directly) gets an error saying so. A call that cannot carry it (loading a view, a
+message result, expanding a tree node, a map interaction) is neither synced nor refused. The old `params.model` / `clientPageModel` / `compositeModel`
+keys are never read as a sync source; they are only *filled* by the backend, see below. So the
+switch and the client upgrade go together per host: flip the flag in the same deploy that ships
+the 7.1.0 client. Internal Java callers with nothing to sync send an empty `new ModelSync()`.
+
+#### What changed on the client
+
+- `UiAction.model` and `UiAction.composite` are **deprecated no-ops** for a view's own actions.
+  `submit` keeps one meaning: validate before sending, the embedded views' forms included. For an
+  executor that is not a view (a tree, the filter editor) `model` still flushes its form and its
+  model still rides on `params.model` as before, because it has no view to sync.
+- Forms are flushed into their data (`submitForm(false)`) on every open view before a call, so an
+  unsaved field value is part of what is compared and sent. **Only the user's edits are
+  flushed**: the form remembers, per control, the value it last exchanged with the data (built
+  or refreshed from it, or written into it), and a control still equal to that writes nothing.
+  This is what keeps an untouched `false` or `0` from turning into `''` on a round trip (the
+  control is now built with `value ?? ''`, and a value written back takes the type the field has
+  in the data: `'true'` → `true`, `'12'` → `12`, `''` → `null`), and a backend push from
+  reaching the data only to be overwritten by the control's stale value on the next call. The
+  same rule the other way: a data field the backend changed reaches its control even when the
+  user edited it (the backend wins on a field it changed), a field it did not change keeps what
+  the user typed. `SmartFormService.resetExchangedValues()` starts over when a form is rebuilt.
+  The form's own dirty flag is not involved: it lives until the form is rebuilt and says nothing
+  about what the data holds.
+- A push of some `data.*` paths marks only those paths as synced; whatever else the view holds
+  keeps its standing, so a value written into the data outside a form while a call was in flight
+  is still sent by the next one. A whole-model push and the initial load mark all of it.
+- Calls run concurrently, and an envelope built earlier may complete later: its copies are never
+  written over the copies a later envelope or push already settled. The server-side ordering of
+  rapid per-field actions stays out of scope (ADR-0010).
+- A dialog the backend closed (`ViewState.TO_CLOSE`) no longer fires a `DEFAULT_CLOSE` action of
+  its own on top of the response that closed it; only the user's own close does.
+- The per-field actions a widget's `valueChangeMode` fires are ordinary actions and inherit the
+  sync; they no longer set `model: true`, and still carry `params.item`.
+
+#### Removed from the public API
+
+| Gone | What to do |
+|---|---|
+| `SmartComponentApiClient.sendModelOnWidgetAction` | Delete the assignment. Every widget action carries the changed models now. Loud: `this.sendModelOnWidgetAction = true` no longer compiles. |
+| `SmartComponentApiClient.addModelToWidgetParams()` / `addModelToWidgetAction()` | Delete. The grid service builds its own envelope. |
+| `SmartViewContextService.getCompositeModel()` | Delete. The backend gets every changed view. |
+| `SmartViewContextService.submitEmbeddedForms()` | `validateEmbeddedForms(containerUuid)` — validation only; the flush is part of every call. |
+| `SmartViewContextService.dataChanged()` | Delete. It was never wired on the client (`handleValueChanges` had no caller); a field change is a uiAction. |
+
+New on `SmartViewContextService`: `joinModelSync(uuid, participant)` / `leaveModelSync(uuid,
+participant)` (the client does this on its own uuid; leaving only takes effect for the participant
+that is registered, so a component destroyed after its successor joined under the same uuid does
+not take the successor with it), `markModelSynced(uuid, keys?)` (the client calls it whenever the
+backend's model reached it: without keys the whole data, with keys the pushed `data` paths), and `withModelSync(carrier, call)` for a host that issues its own backend call on a request
+that can carry the envelope (a `UiActionRequest`, a `GridSelectionChange`): it puts the envelope
+on the carrier, runs the call with it and settles the copies on success, and hands back the raw
+`ViewContextChange` — what to do with the response stays with the caller. The grid and tree
+services are the in-tree examples; `beginModelSync()` / `completeModelSync()` underneath are
+public too.
+
+#### The Java side of the host: three kinds of handler
+
+The backend **backfills** the old `params` keys from the synced model on every request (with the
+switch on, every request carries `modelSync`), so no handler has to change on the day the client
+is upgraded. Two kinds must be
+looked at anyway, and one of them breaks without a compiler error. Run
+`node tools/model-sync-audit/cli.mjs ../<host>` — it lists every read of the request model with
+one of these categories and a reason ([its README](../../tools/model-sync-audit/README.md)):
+
+| | The handler | What to do |
+|---|---|---|
+| **A** | reads `params.model` (`extractClientModel(request)`, `actionRequestHelper(request).get(UiActions.MODEL, …)`) and only passes it to `setModel(viewUuid, …)` | Delete both statements. The sync already wrote the client's model into the view. |
+| **B** | reads it for something else: saves it, validates it, forwards it, mutates it before setting it back | Nothing required. `getModel(viewUuid)` is the honest read now; `extractClientModel` is `@Deprecated`. A grid row action's `params.model` is still the clicked row and is never synced. |
+| **C** | reads the view's model too (`getModel(viewUuid)`, `view.getModel()`) and uses the two together — a diff, a merge, "what changed" | **Breaks silently.** After the sync `getModel` *is* the client's model, so the comparison compares a thing with itself. The server-side read must become `viewApi.isModelSyncEnabled() ? getPreviousModel(viewUuid) : getModel(viewUuid)`: the model as the server knew it before this call, request-scoped (`viewApi.getPreviousModel(uuid, Class)` outside a `PageApiImpl`). The off branch is the old code. |
+
+A handler that must work in both server modes — a shared module deployed to hosts with the
+switch off as well as on — branches inline on `viewApi.isModelSyncEnabled()` and keeps its old
+code verbatim in the off branch: an A site becomes
+`if (!viewApi.isModelSyncEnabled()) { setModel(viewUuid, extractClientModel(request)); }`, a
+client read `viewApi.isModelSyncEnabled() ? getModel(viewUuid) : extractClientModel(request)`, a
+C site's server read the ternary above. No wrapper helper on purpose: once every host runs with
+the switch on, the off branches are deleted line by line and what remains is the plain new code.
+The platform's own handlers are written this way. `getPreviousModel` with the switch off returns
+`getModel` and logs an ERROR: that code assumes a mode the server is not running in.
+
+Two traps the audit cannot see:
+
+- A handler that forwards the *request* to a callback which reads `params.model` (the platform's
+  password editor does this) depends on `extractClientModel` writing the typed instance back into
+  the params. Keep `extractClientModel` there, or hand the model over explicitly.
+- A handler that reads `compositeModel` by hand gets it backfilled only when its action still
+  has `composite=true`. Read the children's models from `viewApi` instead; the flag goes away
+  once no host reads the key.
+
+The measured spread, over the 56 host repositories that were audited when this shipped: 1061 read
+sites, 301 A, 671 B, 77 C.
+
+### New in 7.2: HTML widget, row layouts, hydrated toolbars (#30388)
+
+Additive, with **one behaviour change** and one removed field. The reference is
+`HTML-WIDGET.md`, shipped in the package next to this file.
+
+- **`SmartFormWidgetType.HTML`**: server-sent html whose client placeholders (`{{…}}`) the client
+  resolves against the model, with toolbars hydrated into its toolbar slots
+  (`<smart-ui-action-toolbar data-sb4-toolbar="…">`) and action triggers (`data-sb4-action`) on
+  any element. The `DIV` widget is untouched. A host that never sends the widget sees no change.
+  The widget can bring its own style sheet (`HtmlProperties.css`), which the client adds to the
+  document head once per distinct text; a host with a nonce-based `style-src` provides
+  Angular's `CSP_NONCE`. A style sheet can animate new html coming in and, through the
+  `sb4-html-leaving` class the client puts on the widget or cell before it replaces the html,
+  going out.
+  Inside a `{{#section}}` a placeholder reads the surrounding scope only when it says so,
+  `{{../title}}`: one step per entering section, never above the widget's root.
+- **Icon slots (in the tree, released after 7.2.4)**: an element in the html marked with
+  `data-sb4-icon` hydrates into a
+  `smart-icon` — the same component a button or a cell uses. The marker addresses a name
+  (`data-sb4-icon="mail"`, coloured by `data-sb4-icon-color`, a theme or host class name), an
+  `ImageResource` (a placeholder that resolves to one, or the json `Tag.icon(resource)` writes
+  in), or a key of the template's icon dictionary (`data-sb4-icon-key`,
+  `HtmlProperties.icons`), which sends a finite type-to-icon mapping once with the template
+  rather than once per row. An address that resolves to nothing renders no icon and says
+  nothing; an unknown dictionary key warns. Nothing changes for a host that sends no icon slot.
+- **Row layouts**: a cards grid can carry its card layouts once per grid
+  (`GridViewDescriptor.rowLayouts`, picked per row by `GridRow.rowLayout`) instead of once per
+  row. The per-row `layoutDescriptor.GRID_ROW_LAYOUT` still works and wins over them; a
+  host-registered `'<GRID_ID>Card'` component still renders the rows that get no layout.
+- **Clicking a card rendered from a layout — 7.2.0 changed it, 7.2.1 takes the change back.**
+  7.2.0 made a click select the row and moved the default row action to the double click. That
+  broke `mod-contact`'s contact list, and a cards grid naming no `selectionMode` lost its click
+  altogether. **From 7.2.1 a card behaves as in 7.1.x again unless the server says otherwise**: a
+  click fires the row's first applicable default action, and nothing is selected by click while
+  the click belongs to the default action. A host that put a root trigger on its cards for 7.2.0
+  can keep it; it is no longer needed.
+- **`GridViewDescriptor.defaultRowActionTrigger` (7.2.1, `click` | `doubleClick`)** makes the
+  gesture data, so a cards grid is programmed like a table: `selectionMode` decides whether rows
+  are selectable, the trigger decides what fires the default row action. With `doubleClick` a
+  click selects the card and a double click fires the default action, as on a `ROW_SELECT` table.
+  With an explicit trigger several applicable default actions open a menu at the pointer, filtered
+  to what the row offers. Without a value a card keeps the click and a table the double click; in
+  7.2 a table fires on double click whatever the value is (7.3 honours an explicit `click`, see
+  below). The second click of a double click is not a
+  click of its own on a card: it neither fires the default action again nor toggles the selection
+  back, and further clicks are dropped while the default action runs. Needs a platform that knows
+  the field; an older client ignores it.
+- **The double-click menu of a table works again.** A grid row offering several of the grid's
+  `defaultRowActions` opens a menu at the pointer on double click. The position override behind it
+  had been written for an older Material signature and threw on open, so until 7.2.1 such a double
+  click did nothing.
+- **`SmartGrid.layoutComponent` is removed.** The card gets the layout class through the
+  `SMART_ROW_LAYOUT_COMPONENT` token that `provideSmartNgClient()` provides, so a cards grid a
+  host builds with `addGrid()` renders backend layouts too. Delete the field if a host grid model
+  sets it; nothing else changes.
+- A toolbar no longer lets a `dblclick` on its buttons through to the element around it (it
+  already kept the `click`).
+- The toolbar's re-entry guard is per action now: while one action runs, another button of the
+  same toolbar can be fired. It is also released when the action fails.
+- **Trusted Types**: the HTML widget writes backend-authored html as it is, as the `DIV` widget
+  always has. A host that enforces Trusted Types must allow that write.
+- **Table cells**: `GridColumnMeta.contentType` now reaches the table. A column that names none
+  (or `html`) renders exactly as before, sanitized; `text` escapes the value. A column with
+  `htmlProperties` renders a column template — the HTML widget's dialect, resolved per row, with
+  toolbar slots and triggers offering the row's actions. A row action addressed to
+  `UiActions.NO_TOOLBAR` no longer shows in the row menu; in a table with column templates no row
+  action addressed to a toolbar does.
+
+### New in 7.3: object navigation and editing screens (#23616)
+
+Additive for a host that uses the components as they are, with **visible style changes in every
+host**; a host that calls `TreeService.selectNode2` or extends `Table` has source changes (see
+"Source changes" at the end of this section). Needs the matching platform (`TreeSelectionRequest`,
+`ViewContext.sequence`); release the two together. With an older platform the edits a tree
+selection carried are not sent again and late responses are always applied.
+
+- **Theme token defaults.** The first `ThemeService` (every host has one through
+  `SmartViewContextService`) puts a `<style id="sb4-theme-defaults">` first in `<head>`: light
+  values of the library's tokens on `:root`, dark values under `.theme-dark`. Tokens a host sets
+  on `body` or `:root` win; tokens set on `html { }` do not, so move them to `body`. The defaults
+  cover 14 tokens (`--color-surface(-alt)`, `--color-text(-muted)`, `--color-border`,
+  `--primary / secondary / accent / warn / success / warning / info-color`,
+  `--primary-text-color`, `--tree-active-color`). The optional tokens the library also reads
+  (`--tree-active-background`, `--grid-open-row-background`, `--grid-open-row-bar`,
+  `--primary-light-color` and the other old names below) get no default and fall back where they
+  are read, for example `--tree-active-background` to `--accent-color`. A token the host never
+  defined now has a value, for example `--tree-active-color: #ffffff`. A host with a
+  nonce-based `style-src` provides Angular's `CSP_NONCE`, which the element then carries.
+- **Dark defaults** stand under `.theme-dark` only (with `color-scheme: dark`), so they apply
+  only when the host offers a theme named `dark`. A host that sets its light tokens on a plain
+  `body` hides them and ships its dark theme with the full token set.
+- **Components read the theme tokens.** The menus, action buttons, tables, the mobile table and
+  the grid take their colours from `--color-surface`, `--color-surface-alt`, `--color-text`,
+  `--color-text-muted`, `--color-border`, `--primary-color` and `--primary-text-color` instead of
+  fixed values. A host without these tokens sees the defaults above, which are close to, but not
+  exactly, the old colours (menu text `black` → `#132033`, disabled `#aaa` → `#68778e`, table
+  hover `whitesmoke` → `#f4f6fb`). The old names `--primary-light-color` (selected table row),
+  `--disabled` (disabled row), `--light-gray` (grid edit icon), `--mat-sys-primary` (selected
+  card outline) and `--primary-color-text` (activated view button) are still honoured before the
+  new ones. The grid overlay uses relative colour syntax (`rgb(from …)`, Chrome 119 / Safari
+  16.4 / Firefox 128), inside Angular 22's browser floor.
+- **Row states.** `GridRow.rowState` is rendered as the row class `sm-grid-row-<state>`
+  (`new`, `modified`, `deleted`, `moved`, `contains-change`, or an application code in lower
+  case) on table, mobile-table and card rows, with default styles: new green italic, modified
+  accent bold, deleted muted with struck-through cell text (`.smart-table-cell-text`), moved
+  italic, contains-change the accent colour only. A card only takes the colour: a deleted card is
+  muted, nothing is struck through. A selected row keeps its normal text colour. Any grid whose
+  server already fills `rowState` shows them.
+- **Row state column.** `GridViewDescriptor.rowStateDisplay` (`GridRowStateDisplay`) picks how a
+  table and a mobile table show the states: `STYLE` (the default when absent) the row classes
+  above, `COLUMN` a first column of state icons without the row classes, `BOTH` the two
+  together. The column shows an icon for the platform states (an application state has none),
+  with the tooltip and accessible name from `rowStateLabels` (by state code); the column itself is
+  named by `rowStateColumnLabel` and has no header text. It is not a descriptor column: not
+  editable, not in the column chooser. The platform fills both labels in the session's locale.
+  A cards grid has no column and keeps the row classes whatever the value.
+- **Mark of the open row.** A grid whose `GridViewDescriptor.markOpenRow` is true gives the row
+  of `GridPage.openRowId` the class `sm-grid-row-open` (table and mobile table): a light accent
+  tint and a bar at the row's start, restyled by `--grid-open-row-background` and
+  `--grid-open-row-bar`. A default row action, from a double click, a click or the row menu, moves
+  the mark at once; a grid page requested before the action's answer keeps the new mark, the first
+  one requested after it brings the server's `openRowId`.
+- **`defaultRowActionTrigger: click` on a table.** A table now honours an explicit `click`: a click
+  on a row with an applicable default action fires it (several open the menu at the pointer), does
+  not select the row, and a double click does nothing more. A click on a button, link or input in
+  the row stays the control's own. Without a value or with `doubleClick` nothing changes. Table
+  rows are tracked by their id, so a reloaded row keeps its elements.
+- **Tree grid controls.** The header of a TREE_GRID shows expand all / expand level / collapse
+  level / collapse all as small icon buttons, disabled when there is nothing to do. The server
+  picks and orders them with `GridViewDescriptor.treeGridControls` (`TreeGridControl`): absent or
+  null shows all four, `[]` none (before: two mini-fab buttons).
+- **Trees.**
+  - A tree reload keeps the node objects of the nodes it still has and writes the new data
+    into them. Rows survive a reload, a click that started before it still lands, and
+    `smartTreeModelChanged` fires once per reload (before: twice, first empty).
+  - A node keeps the icon the backend sends; a node without one gets `Folders` if the host
+    registered it, Material `folder` otherwise (before: always `Folders`).
+  - A node action with its own `descriptor.title` is labelled by it.
+  - The caption shows the short description as a tooltip.
+  - Without a `[treeStyle]` a row is indented 15px per level and the selected row gets
+    `sm-tree-node-selected` (`--tree-active-background`, else `--accent-color` /
+    `--tree-active-color`); its caption and short description take the colour with
+    `color: inherit`, so a host rule on every element (`* { color: … }`) does not reach them.
+    With a `treeStyle` nothing changes.
+  - Server classes `sm-tree-branch-new|modified|deleted|foreign|own-other-view-context` have
+    default styles.
+- **Tree selection syncs the models.** Selecting a tree node sends the client's changed models
+  like an action does (`TreeSelectionRequest.modelSync`). Needs the matching platform:
+  an older one ignores the body and the edits it carried are not sent again.
+- **Tree widgets in a server layout** provision their own tree service from the widget
+  identifier when the screen's default tree is a different one or there is none, so a generic
+  page can show a tree and a layout can hold several.
+- **Late responses.** The server raises `ViewContext.sequence` on every save of the view
+  context; the response of an action or of a tree selection whose view context is not newer
+  than the one the client holds no longer overwrites it, its changes are still applied. Needs
+  the matching platform: an older platform sends no sequence and its responses are always
+  applied. Such a response first waits for the view-context updates the client still has in
+  flight, and their answers count in the comparison (they are applied as before, without the
+  guard). A response that is not applied still closes the views it marks `TO_CLOSE`.
+- **Views entering a slot.** When one response closes an embedded view and opens another in
+  the same slot, the two are exchanged in one step: the old component stays (inert, cut off
+  from the server) until the new one has its model, at most 3 s. Every view opened into a slot
+  of a server layout likewise stays hidden until its model arrives, so the layout beside it
+  changes once. Showing such a view fires one `window` `resize` event, so content that measured
+  itself while hidden (textarea autosize, scrolling toolbars) measures again.
+- **Empty slots.** An embedded slot of a layout that shows no view carries `sm-slot-empty`; an
+  empty `sm-nav-pane` takes no width, so the list beside it has the full width.
+- **Focus after a pane closes.** When the view of an `sm-nav-pane` closes and the focus went
+  with it, the focus moves to the open row (`sm-grid-row-open`) of the `sm-nav-list` beside the
+  pane, else to the row that was open while the pane showed the view, else to the list.
+- **Navigation frame styles.** Default layout for the server classes `sm-nav-view`,
+  `sm-nav-pane`, `sm-nav-list`, `sm-nav-header`, `sm-nav-caption`, `sm-nav-section(-title)`,
+  `sm-nav-tree`, `sm-nav-slot`, `sm-nav-crumbs`, `sm-crumb-ahead`, `sm-crumb-current`; a host may
+  restyle them by the same names. `sm-nav-header` puts the caption of a pane view and the toolbar
+  with the pane's close on one line. Inside `.sm-nav-list` a grid toolbar without a button is
+  hidden and the grid has no top padding; the search page container has a 0.5rem gap there.
+- **Icon buttons** get an `aria-label`: the action's title, else its tooltip. A button that shows
+  its title is named by it and gets none.
+- **Row actions in a table's action column** stand side by side; the toolbar no longer wraps
+  in the narrow column (row actions the server shows as icons).
+- **Prerendered pages.** A page shown after browser prerendering keeps its view context uuid
+  (sessionStorage written during prerendering is dropped; the client restores it from the request
+  header), so a tree on it loads its nodes.
+- **Search page title**: `.search-page-title` is 1.35rem / 600 / no margin on every search
+  page, a deliberate global change.
+- **`--primary-color` fallback.** Where the menus and the activated view button fall back
+  without the token, the value is `#384372` instead of `#1976d2`; the tree grid header buttons
+  are 28px squares.
+- New public API: `GridViewDescriptor.treeGridControls`, enum `TreeGridControl`,
+  `SmartTableInterface.treeGridControls`, `SmartIconService.hasCustomIcon()`,
+  `ViewContext.sequence`, `ViewContextData.sequence`, `SmartTreeComponent.trackByIdentifier`,
+  `SmartGridComponent.calcRowClasses()`; `GridViewDescriptor.rowStateDisplay`, `rowStateLabels`,
+  `rowStateColumnLabel`, `markOpenRow`, enum `GridRowStateDisplay`, `GridPage.openRowId`;
+  `SmartTableInterface.defaultActionOnClick`, `markOpenRow`, `openRowId`, `rowStateDisplay`,
+  `rowStateLabels`, `rowStateColumnLabel`, `onRowAction`; `UiActionToolbarComponent.actionFired`;
+  `EmbeddedSlotProperties` (`singleView`: the server closes the view standing in the slot before
+  it opens the next; generated for completeness, the client does not read it).
+- **Source changes** for a host that calls these members or extends the classes:
+  - `TreeService.selectNode2(viewUuid, treeId, nodeId, treeSelectionRequest?, observe?, …)`: the
+    optional `TreeSelectionRequest` stands before `observe` in every overload, and the call sends
+    a JSON body. A call that passed `observe` in the fourth place does not compile; insert
+    `undefined` or the request.
+  - `Table` (the base of the table components): `handleOnRowClick(element)` became
+    `handleOnRowClick(event: MouseEvent, element)`; the getters `expandTreeGridLevel` and
+    `closeTreeGridLevel` are gone (the controls come from `treeGridControls`); the rows and the
+    header render `displayedColumns` instead of `smartTable.tableHeaders`, and the expanded
+    detail row spans `displayedColumns.length`. New members: `trackRow`, `rowStateColumn`,
+    `onRowActionFired`. A host template copied from the library's must follow.
+  - `SmartTreeComponent.treeControl`'s children accessor returns an `Observable` of the children,
+    not the array. `SmarttreeGenericService` writes a reload into the node objects a host holds
+    (same objects, new data) and sets `treeFromBackend` to the merged nodes.
+
+### New in 7.3.2: keybindings (#19122)
+
+Additive: a host without a keymap gets one binding, Escape closes a dialog that offers
+`DEFAULT_CLOSE`. Needs the matching platform (`Keybinding`, `View.keybindings`,
+`ComponentModel.keybindings`); release the two together.
+
+- **The keymap.** Properties files on the server, `CODE=chord[,chord]` binds every action of
+  that code, `viewName.CODE=chord[,chord]` only in that view and wins over `CODE`; an empty
+  `viewName.CODE=` disables the chord in that view. The host lists its own file before the
+  platform's, the first file with the key wins:
+  `spring.keybindings.basename=keybindings-<app>,keybindings-platform`. The platform's file binds
+  Escape to `DEFAULT_CLOSE`, `CANCEL` and `CLOSE_SEARCH_PAGE`, which close the view on every
+  platform page offering them; without the property only that file is read.
+- **Chord grammar.** Modifiers, then one key, joined by `+`: `Mod+Shift+S`. `Mod` is Cmd on a Mac
+  and Ctrl elsewhere, so one chord serves both; `Ctrl`, `Alt`, `Shift`, `Meta` are the literal
+  keys. The server writes every chord canonically (modifier order `Mod`, `Ctrl`, `Alt`, `Shift`,
+  `Meta`, letters upper case), so the order and case in the file do not matter. The key is the
+  browser's `KeyboardEvent.key` name (`Escape`, `Enter`, `ArrowUp`, `F2`, `Delete`), the space
+  bar is `Space`. A letter or digit also matches by its physical key when a modifier changes the
+  character (Option+N on a Mac). Chords the browser keeps for itself (`Mod`/`Ctrl` with `W`,
+  `T`, `N`, `Q`, `R`, `Tab`, and `F5`) and unparsable ones are dropped with an ERROR log.
+- **Bindings in code.** A page binds its own actions on the view, typically in `initModel`:
+  ```java
+  view.addKeybindingsItem(new Keybinding()
+      .chord(KeyChord.of(KeyboardKeys.MOD, KeyboardKeys.SHIFT, KeyboardKeys.ARROW_UP))
+      .uiActionCode(MOVE_UP)
+      .uiActionIdentifier(rowId)); // optional: without it every MOVE_UP action is bound
+  ```
+  Per action the code level wins over `viewName.CODE`, which wins over `CODE`; a code-level entry
+  replaces the keymap of its action, they are not merged. Only the code level can name an
+  identifier. When two actions of a view share a chord, the more specific source keeps it, then
+  the earlier action, with a WARN log. The server resolves all this into
+  `ComponentModel.keybindings`; a keymap entry of an action the view does not offer yields
+  nothing.
+- **Which view gets the key.** One document listener serves every view. The key goes to the view
+  holding the focus, the innermost one when views are nested; when nothing has the focus, to the
+  view that had it last (the focus is lost when a pushed layout re-renders the field), else the
+  top-most dialog, else the current page. If that view has no enabled binding for the chord, the key
+  bubbles to the enclosing views, but never out of a dialog: the page behind it does not react
+  while a dialog is open. A NORMAL view opened by the user's action takes the focus, a view
+  restored on reload does not.
+- **What does not fire.** Unmodified typing in an editable element (text inputs, textareas,
+  selects, contenteditable): letters, digits, editing and caret keys, and `Enter` in a multi-line
+  field stay the element's; `Escape`, the function keys, chords with Ctrl, Alt or Cmd, and `Enter`
+  in a single-line input reach the bindings. A disabled or not offered action does not fire: the
+  key bubbles on and reaches the browser when nothing takes it. Auto-repeated keys, a key a panel
+  already handled (`defaultPrevented`) and a key pressed in an overlay of no view (an open select
+  or menu panel) fire nothing. An unmodified `Enter` or `Space` on a focused button, link or
+  ARIA-interactive control stays with that control (the browser activates it), and the `Enter`
+  that confirms an IME composition fires nothing. A fired chord is `preventDefault`ed.
+- **Tooltip and accessibility.** A toolbar button shows its chords in its tooltip, formatted for
+  the platform (`⌘⇧S` on a Mac, `Ctrl+Shift+S` elsewhere), after the server tooltip or alone; the
+  tooltip also opens on keyboard focus. The button names them in `aria-keyshortcuts`.
+- **Two host rules.** Do not bind `Enter` on a view whose form uses `SmartForm.submitOnEnter`:
+  both would run. With `dialogDisableClose: false` MatDialog closes the dialog on Escape itself,
+  as before; the `DEFAULT_CLOSE=Escape` binding is what closes it under the default `true`.
+- **Focus survives a push.** When a push re-renders the field being edited, the view focuses it
+  again: the field with the same widget key (`data-testid`) at the same position within the view,
+  with the caret or selection of a native input or textarea and of a Quill editor. Nothing
+  happens when the field left the layout or the focus moved elsewhere meanwhile (a dialog, a click).
+- **Pending edits are saved first.** A fired action (a key, a toolbar click, an HTML trigger)
+  waits until the view's widgets have saved what was typed into them — today the filter editor,
+  which saves its fields on blur — so a query bound to `Enter` runs with the value just typed. If
+  that save fails, the action is not sent.
+- **Messages.** A message with a single option focuses it and sends it on Escape. Otherwise the
+  first `confirm`-typed option gets the initial focus (Enter presses it) and Escape sends the first
+  `cancel`-typed option. A `reject` option is never chosen by a key, and untyped options (a YES/NO
+  without types) get neither: Escape does nothing, the focus stays on the first button.
+- **Out of scope.** Row actions (grid, table, card rows) and actions inside widgets have no
+  keybindings; only the view's own actions do.
+- **New in the public API:** model `Keybinding`, `View.keybindings`,
+  `ComponentModel.keybindings`; Java `KeyChord`, `KeyboardKeys`, `KeybindingSettingApi`.
+
+### New in 7.3.5: a stored layout names its HTML template by key (#30388)
+
+Additive, and needs the matching platform. Nothing changes for a layout that names no key.
+
+- **`HtmlProperties.templateKey`.** An HTML widget of a stored layout (an
+  `ObjectLayoutDescriptor`) names the template its html and style sheet come from:
+  `h.templateKey("CONTACT_CARD")` in code, `html card { template: CONTACT_CARD }` in the layout
+  DSL. The key stays in the widget and wins over a stored html.
+- **`resolvedCopy(ctx, viewName, layout)`** (`PageApiImpl`, `ObjectLayouts`) is how a stored
+  layout goes onto a view: a deep copy with the keys loaded and the server placeholders resolved.
+  The platform's own paths use it (`ObjectLayoutDescriptorUtilApi.initLayoutDescriptor`, the MDM
+  entry editor, object navigation). **A host that puts `descriptor.getLayouts()` or the layout of
+  `getObjectDisplay` onto a view itself has to call it** before it stores a key in such a layout.
+- **A widget whose key was never loaded renders nothing** and logs one console warning naming
+  the key.
+- **Behaviour changes on the server.** `ObjectLayoutDescriptorUtilApi.initLayoutDescriptor` now
+  puts a copy of the descriptor's layout on the view, not the descriptor's own instance, and
+  fails on an html with a server placeholder (`${alias:/…}`) it has no context for — pass the
+  context with the new `initLayoutDescriptor(view, descriptor, ctx)`. `NavigationNodeLayoutInternalApi
+  .createBodyLayoutWithFieldEdges` takes the view name as its first argument.
+  `PageApiImpl.gridBuilder(...)` hands the template resolver to the `GridBuilder`, so
+  `htmlColumn(c -> c.template(ctx, KEY))` works.
+- **New in the public API:** `HtmlProperties.templateKey`; Java `HtmlWidgetBuilder.templateKey`,
+  `ObjectLayouts.resolvedCopy` / `templateKeys` / `unloadedTemplateKeys`, the `viewName` variants
+  of `resolveHtml`, `DataSheetPageApi.CONTEXT_DATA_SHEET`. See HTML-WIDGET.md, *Template-kulcs egy
+  tárolt layoutban*.
+
+### Bugfixes shipped with 7.0
+
+- (7.3.2) A view dialog no longer disappears on the browser's back button. MatDialog's default
+  `closeOnNavigation` disposed every dialog on a Location change without any action, so the
+  backend kept the views open and a reload brought them back; view dialogs now open with it off.
+- `SmartformwidgetComponent.ngAfterViewInit` no longer crashes with
+  `Cannot read properties of undefined (reading 'valueChanges')` when the form
+  contains a `MONTH_PICKER` widget (it wrongly subscribed to the non-existent
+  `<key>-time` control; only `DATE_TIME_PICKER` has one).
+- A widget nested in a CONTAINER receives `blurSophisticatedValueChange`; the recursion never
+  passed it down, so a BLUR-mode child would have thrown on blur.
+- `SmartformComponent` reaches widgets nested in a CONTAINER when it changes them in place
+  (values, constraints, the touched state after a failed submit). The view query it used
+  could not see them.
+- `UiActionDescriptorService` no longer shares one dialog object between actions. Any action
+  whose descriptor had no `dialog` of its own was given the service's single placeholder — the
+  same object every time — and had its title and button caption written into it, so resolving
+  one action renamed the dialog every other one was holding. The service is
+  `providedIn: 'root'`, so this outlasted the view.
+
+  What you saw on screen, measured on both versions:
+
+  | The action | 6.x, when the dialog opened | 7.0 |
+  |---|---|---|
+  | described by the backend, no dialog of its own | **another action's code** | its own code |
+  | described by nothing at all | **another action's code**, or empty | empty |
+  | registered client-side, no dialog of its own | its own code | unchanged |
+
+  The middle column is not a typo. An action the backend describes is resolved twice in the
+  normal flow — once when the toolbar renders it, again when the dialog it opens resolves it
+  for itself — and the first resolution wrote a dialog onto the action's own descriptor, so the
+  second one skipped the step that fills in the title. What the dialog then showed was whatever
+  code had last passed through the shared object. An **already open** dialog could change too,
+  since its title is re-read on every change-detection pass.
+
+  An action nothing describes still gets an untitled placeholder dialog: its *button* carries
+  the code, the dialog does not. That is unchanged and deliberate — such an action is a gap in
+  the host's descriptor map, and this is the honest rendering of it.
+
+  A resolved descriptor is now the caller's own object throughout, which also means
+  `getActionDescriptor()` no longer writes a placeholder dialog and a `SNACKBAR` feedbackType
+  into the `descriptor` the backend put on the action itself.