cabloy 5.1.174 → 5.1.175

package/.cabloy-version

@@ -1 +1 @@
-5.1.174
+5.1.175

package/.claude/skills/cabloy-frontend-scaffold/SKILL.md

@@ -183,6 +183,7 @@ Check whether the feature needs:
 - SSR hydration-equivalence review: classify state as SSR-required or intentionally deferred; keep server HTML and the hydration-time client render equivalent; defer private, cookie-unavailable, or browser-only query/load/render branches to an explicit post-hydration, admission, mounted, or interaction boundary
 - distinguish `$useStateData(...)` query ownership from readiness waits: `disableSuspenseOnInit` only skips its init-time suspense kick and does not prevent query creation or fetches; choose `$QueryEnsureLoaded(...)` or freshness helpers only at the later boundary that needs them
 - verify that render-driving UI reads model/query-owned reactive state (`query.data` or a model-derived surface); keep awaited `refetch()` results local to one-shot interaction/orchestration and never as a parallel ongoing controller/render state copy
+- refetch error-boundary ownership: when an interaction boundary such as `ZButton onPerform` should own generic query-refetch failure, return or await `query.refetch({ throwOnError: true })`; when local/domain-specific UI owns recovery, retain `result.error`, `query.error`, or a local catch instead; `bypassPersister` controls per-fetch persistence only and can be combined with either deliberate error route
 - reverse fullstack handoff when newly added frontend resources will later be consumed by backend metadata or backend tooling
 
 If the frontend change introduces resources such as a custom form-field renderer, table-cell renderer, or other generated metadata that backend `ZovaRender.field(...)` / `ZovaRender.cell(...)` will consume, do not treat the task as frontend-only cleanup.
@@ -203,6 +204,7 @@ Check whether the feature needs:
 - generic component conversion
 - style/theme/icon updates
 - wrapper usage review
+- async interaction ownership: for a button-only action, return or await the complete action through `ZButton onPerform`, choose one error presentation owner rather than combining its generic alert with local query/error UI, and do not mirror the same lifecycle with button-local `loading` / `disabled` state; retain explicit state only for independently initiated or broader shared work
 - async-loading or controllerRef implications
 
 ### Verification
@@ -216,6 +218,7 @@ Check whether the feature needs:
 - SSR or route-path verification
 - hydration-time initial-render equivalence when SSR, private state, browser-only state, or async model state changes
 - edition-specific flavor, SSR site baseline, and project-asset verification
+- interaction failure-path verification when `ZButton onPerform` owns a query action: a failed refetch reaches exactly the intended `onError`, generic alert, or local error UI, and button loading resets
 
 ### SSR theme review reminder
 
@@ -251,6 +254,7 @@ Especially relevant pages include:
 - `repo-docs/frontend/route-alias-guide.md`
 - `repo-docs/frontend/navigation-guards-guide.md`
 - `repo-docs/frontend/component-guide.md`
+- `repo-docs/frontend/behavior-guide.md` for `ZButton` / Behavior action loading and error-boundary ownership
 - `repo-docs/frontend/form-layout-guide.md` for schema-driven field placement, Grid/flow selection, groups, tabs, or embedded filter actions
 - `repo-docs/frontend/component-props-guide.md`
 - `repo-docs/frontend/component-v-model-guide.md`

package/CHANGELOG.md

@@ -1,5 +1,23 @@
 # Changelog
 
+## 5.1.175
+
+### Features
+
+- Add `$routedDialog` support for route-driven dialogs.
+- Remove the `a-boundary` component.
+- Update core functionality and related integrations.
+
+### Bug Fixes
+
+- Fix end-to-end test failures.
+
+### Improvements
+
+- Refactor `ZButton`.
+- Update table cell force-delete actions and related test coverage.
+- Document controller load boundaries, column layouts, resource pickers, routed dialogs, error handling, and `ZButton` usage.
+
 ## 5.1.174
 
 ### Improvements

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "cabloy",
-  "version": "5.1.174",
+  "version": "5.1.175",
   "gitHead": "2c5c19284bab738e492856189acb6fad74b8a7b7",
   "description": "A Node.js fullstack framework",
   "keywords": [
@@ -76,7 +76,7 @@
   },
   "devDependencies": {
     "@cabloy/dotenv": "^1.2.8",
-    "@cabloy/lint": "^5.1.33",
+    "@cabloy/lint": "^5.1.35",
     "@cabloy/process-helper": "^3.1.3",
     "@playwright/test": "^1.62.1",
     "@types/fs-extra": "^11.0.4",

package/repo-docs/.vitepress/config.mjs

@@ -503,6 +503,7 @@ export default defineConfig({
             { text: 'A-Router Guide', link: '/frontend/a-router-guide' },
             { text: 'Zova Router Under the Hood', link: '/frontend/zova-router-under-the-hood' },
             { text: 'Router View Hosts Guide', link: '/frontend/router-view-hosts-guide' },
+            { text: 'Routed Dialog Guide', link: '/frontend/routed-dialog-guide' },
             { text: 'Router Tabs Introduction', link: '/frontend/router-tabs-introduction' },
             { text: 'Router Tabs Overview', link: '/frontend/router-tabs-overview' },
             { text: 'Router Tabs Mechanism', link: '/frontend/router-tabs-mechanism' },
@@ -529,7 +530,12 @@ export default defineConfig({
           text: 'Components & UI',
           items: [
             { text: 'Component Guide', link: '/frontend/component-guide' },
+            {
+              text: 'Controller Load Boundary Guide',
+              link: '/frontend/controller-boundary-guide',
+            },
             { text: 'Form Guide', link: '/frontend/form-guide' },
+            { text: 'Resource Picker Guide', link: '/frontend/resource-picker-guide' },
             { text: 'Form Layout Guide', link: '/frontend/form-layout-guide' },
             { text: 'Image Guide', link: '/frontend/image-guide' },
             { text: 'File Guide', link: '/frontend/file-guide' },
@@ -555,6 +561,7 @@ export default defineConfig({
               link: '/frontend/permission-formscene-action-visibility-guide',
             },
             { text: 'Table Guide', link: '/frontend/table-guide' },
+            { text: 'Column Configuration Guide', link: '/frontend/column-configuration-guide' },
             { text: 'TableCell Authoring Cookbook', link: '/frontend/table-cell-cookbook' },
             {
               text: 'Table + Resource CRUD Cookbook',

package/repo-docs/frontend/a-model-under-the-hood.md

@@ -225,6 +225,17 @@ This option is not a force-new-request primitive. The model wrapper preserves Ta
 
 The current implementation transports the marker through the installed TanStack Query observer's internal fetch-options forwarding. `bypassPersister` is therefore a Zova model option, not a native public TanStack `RefetchOptions` field; the model wrapper keeps that internal detail out of the normal authoring surface.
 
+`QueryRefetchOptions` extends TanStack `RefetchOptions` with only `bypassPersister`. The wrapper removes that Zova-specific option and forwards the remaining native options, including `throwOnError`. When one interaction needs both policies, combine them explicitly:
+
+```ts
+await query.refetch({
+  bypassPersister: true,
+  throwOnError: true,
+});
+```
+
+The options remain independent: `bypassPersister` selects the persistence path for this fetch, while `throwOnError` controls whether a fetch failure rejects the awaited interaction. Neither changes query ownership, cancellation, or in-flight deduplication semantics. For choosing between an action-level failure boundary and local query-error UI, see [`$useStateData` Best Practices](/frontend/use-state-data-best-practices#choose-the-refetch-error-boundary).
+
 ## State helper families as one runtime family
 
 The state helper layer lives mainly in:

package/repo-docs/frontend/behavior-guide.md

@@ -337,6 +337,79 @@ Representative usage:
 
 This is a clean example of attaching a behavior to a native element through a generated `bs-*` attribute.
 
+### Perform a standalone asynchronous button action
+
+Cabloy Basic's `ZButton` attaches the `basic-button:perform` behavior to its native button. `BehaviorPerform` owns the button-local lifecycle for an action passed through `onPerform`:
+
+- loading presentation and `aria-busy`
+- temporary disabled state and duplicate-click suppression
+- the ordinary action-error alert, unless `onError` handles the error
+- cleanup in `finally` after the action completes or fails
+
+Pass the complete interaction promise through `onPerform`. For a button-only action, do not mirror the same invocation with controller-local busy state or `loading` / `disabled` props:
+
+```tsx
+// Correct: BehaviorPerform awaits the complete save action.
+<ZButton onPerform={() => this.save()}>{this.scope.locale.Save()}</ZButton>
+
+// Correct: the loading boundary includes every step of this interaction.
+<ZButton
+  onPerform={async () => {
+    await this.save();
+    await this.$router.push(nextPath);
+  }}
+>
+  {this.scope.locale.Save()}
+</ZButton>
+```
+
+Returning the complete promise is not enough when an API reports its failure as a result value. When a `ZButton` owns the generic error path for a query refetch, await a refetch that rejects on failure:
+
+```tsx
+<ZButton
+  onPerform={async () => {
+    await query.refetch({ throwOnError: true });
+  }}
+>
+  {this.scope.locale.Refresh()}
+</ZButton>
+```
+
+The rejection reaches `BehaviorPerform`, which calls `onError` or its default action-error alert and then clears loading in `finally`. `bypassPersister` controls persistence behavior only; it does not make `refetch()` reject. Catch the failure locally only when that layer intentionally owns recovery or error presentation. For the query-state ownership decision and avoiding duplicate local and generic feedback, see [`$useStateData` Best Practices](/frontend/use-state-data-best-practices#choose-the-refetch-error-boundary).
+
+Do not detach asynchronous work from the callback. In the following shape, the callback returns `void`, so the behavior clears its button-local loading state before `save()` finishes and cannot handle its rejection:
+
+```tsx
+// Incorrect: the save promise is outside BehaviorPerform's boundary.
+<ZButton
+  onPerform={() => {
+    void this.save();
+  }}
+>
+  {this.scope.locale.Save()}
+</ZButton>
+```
+
+`loading` and `disabled` remain valid when they represent pending work owned outside this button's `onPerform`, such as an operation started by another control or a native-form/Enter-key submission path. In that case, the button must reflect a broader shared lifecycle:
+
+```tsx
+<ZButton
+  type="submit"
+  loading={this.formRef.formState.isSubmitting}
+  disabled={this.formRef.formState.isSubmitting}
+  onClick={event => {
+    event.preventDefault();
+  }}
+  onPerform={() => this.submitFromButton()}
+>
+  {this.scope.locale.Save()}
+</ZButton>
+```
+
+A genuine `ZForm` submission still owns form-wide validation, submission state, and form error handling even when one visible trigger is a `ZButton`. Use form state when another submit path can bypass the button; otherwise let `BehaviorPerform` be the sole owner of the button-local lifecycle.
+
+The source contract is implemented by `basic-button`'s `ControllerButton` and `BehaviorPerform`. For form ownership and submission paths, see the [Form Guide](/frontend/form-guide).
+
 ### Form-field behavior composition
 
 The form-field controller composes behaviors from two sources:

package/repo-docs/frontend/column-configuration-guide.md

@@ -0,0 +1,254 @@
+# Column Configuration Guide
+
+Column Configuration lets authenticated users save a personal table layout on a resource list page. They can change the visibility, width, and order of eligible columns; the layout is restored when they revisit the same page.
+
+This guide covers Column Configuration on standard resource list pages in both Cabloy Basic and Cabloy Start. It complements the [Table Guide](/frontend/table-guide), which explains the general `ZTable`, schema-metadata, and `tableCell` authoring surfaces. This page focuses on user layouts and their persistence.
+
+## What Column Configuration does
+
+After opening **Column Configuration** from the toolbar, a user can:
+
+| Capability             | Description                                                                         |
+| ---------------------- | ----------------------------------------------------------------------------------- |
+| Show or hide columns   | Only columns eligible in the current table schema can be changed                    |
+| Set a numeric width    | The width must be an integer from `1` through `2000`                                |
+| Use automatic width    | Set the width to `auto` and let the table handle it from content and runtime layout |
+| Reorder columns        | Reorder only within the same fixed region                                           |
+| Save a personal layout | Save it for the current authenticated user and page path                            |
+| Reset the layout       | Remove the personal layout and restore current schema defaults                      |
+
+Column Configuration does not change backend DTOs, database fields, API permissions, or the schema itself. It is a personal presentation preference over already authorized data; it must not be used as an authorization or data-isolation mechanism.
+
+### Fixed regions define the reorder boundary
+
+A schema can pin a column to the `left`, `center`, or `right` region. The Move Up and Move Down controls in Column Configuration work only within the same region:
+
+- A left-fixed column can move only among left-fixed columns.
+- A center column can move only among center columns.
+- A right-fixed column can move only among right-fixed columns.
+
+A user cannot change a column's fixed region through Column Configuration. The row-selection column is also a runtime-generated column and is never saved in a personal layout.
+
+## User workflow
+
+1. Sign in and open a resource list page.
+2. Click the settings icon for **Column Configuration** in the bulk toolbar.
+3. In the dialog, as needed:
+   - select or clear a column to control its visibility;
+   - enter a numeric width or choose automatic width;
+   - use the Move Up and Move Down controls to reorder columns in the same fixed region.
+4. Click **Save** to persist the personal layout and refresh the current table.
+5. To return to defaults, click **Reset**, then click **Save**.
+
+Unauthenticated users cannot load, save, or reset personal column layouts. Even when the toolbar action uses `permission: { public: true }`, that setting controls whether the action is discoverable; it does not allow anonymous reads or writes of personal layouts.
+
+## Basic and Start integration
+
+Both editions share the same layout contract and persistence model. Page-block names, action resource keys, and UI components are edition-specific.
+
+| Edition      | Toolbar block                 | Column-configuration action      | UI layer               |
+| ------------ | ----------------------------- | -------------------------------- | ---------------------- |
+| Cabloy Basic | `basic-page:blockToolbarBulk` | `basic-table:actionColumnConfig` | DaisyUI + Tailwind CSS |
+| Cabloy Start | `start-page:blockToolbarBulk` | `start-table:actionColumnConfig` | Vuetify                |
+
+Current CRUD generator templates add the edition-specific Column Configuration action. Add the action explicitly when authoring a custom or existing resource page.
+
+### Cabloy Basic
+
+```ts
+ZovaRender.block('basic-page:blockToolbarBulk', {
+  actions: [
+    ZovaRender.tableActionBulk('basic-table:actionColumnConfig', {
+      permission: { public: true },
+      placement: 'end',
+    }),
+  ],
+});
+```
+
+Place this action in a standard resource list page hosted by `basic-page:blockPage`, together with `basic-page:blockTable`.
+
+### Cabloy Start
+
+```ts
+ZovaRender.block('start-page:blockToolbarBulk', {
+  actions: [
+    ZovaRender.tableActionBulk('start-table:actionColumnConfig', {
+      permission: { public: true },
+      placement: 'end',
+    }),
+  ],
+});
+```
+
+Place this action in a standard resource list page hosted by `start-page:blockPage`, together with `start-page:blockTable`.
+
+> [!TIP]
+> Do not copy Basic `basic-*` action or block names into a Start page, or the reverse. The editions share the layout protocol but register different page and table resources.
+
+## Schema defaults and personal layouts
+
+Column Configuration has two layers: the schema defines the default table columns, and a personal layout overrides visibility, width, and order within permitted boundaries.
+
+### 1. Define default columns in the schema
+
+Use `ZovaRender.order(...)`, `ZovaRender.visible(...)`, and `ZovaRender.column(...)` on row-DTO or entity fields:
+
+```ts
+@Api.field(
+  v.title($locale('StudentName')),
+  ZovaRender.order(1),
+  ZovaRender.column({
+    align: 'left',
+    width: 240,
+    fixed: 'left',
+    enableSorting: true,
+    sortDescFirst: true,
+  }),
+  v.string(),
+)
+name: string;
+```
+
+The three metadata categories have distinct responsibilities:
+
+| Metadata                    | Responsibility                                                                                                 |
+| --------------------------- | -------------------------------------------------------------------------------------------------------------- |
+| `ZovaRender.visible(false)` | Sets schema/scene visibility. A hidden field does not become a configurable table column.                      |
+| `ZovaRender.order(...)`     | Defines the schema default order. It is normally clearer than setting `order` inside `ZovaRender.column(...)`. |
+| `ZovaRender.column(...)`    | Defines physical-column capabilities: `align`, `width`, `fixed`, and sorting capabilities.                     |
+| `ZovaRender.cell(...)`      | Selects a cell-render resource; it does not persist a layout.                                                  |
+
+The `width` and `fixed` values in `ZovaRender.column(...)` are schema defaults. `fixed` also defines the region in which a user may reorder the column. For a standard resource list page, the backend row schema is the contract truth for column metadata; do not maintain a parallel frontend list of default columns.
+
+### 2. Personal layouts override only permitted parts
+
+A saved personal layout can change:
+
+- whether an eligible table-schema column is visible;
+- its numeric or automatic width;
+- its order within the same `left`, `center`, or `right` region.
+
+The schema remains authoritative:
+
+- A schema-hidden field cannot be restored by a personal layout.
+- A personal layout cannot change the schema-defined fixed region.
+- An old column that is absent from the current schema is not rendered.
+- The row-selection column is not included in the personal layout.
+
+## How layouts are saved and restored
+
+A standard resource page uses the current route `path` as its `layoutKey`. A layout profile is scoped as follows:
+
+```text
+current authenticated user + current page route path
+```
+
+Consequently, one user can save different layouts for different resource pages, and different users do not overwrite one another's layout on the same page.
+
+The `a-layoutprofile` frontend model handles `load`, `save`, and `reset`. A standard `blockPage` first loads the current profile and passes it into the table. After a save or reset succeeds, the page refreshes table metadata so that visibility, order, width, and pinned-column state take effect immediately.
+
+A simplified layout profile has this form:
+
+```json
+{
+  "version": 1,
+  "schemaFingerprint": "optional-fingerprint",
+  "columns": [
+    { "key": "name", "visible": true, "width": 240 },
+    { "key": "mobile", "visible": false, "width": "auto" }
+  ]
+}
+```
+
+| Field               | Rule                                                |
+| ------------------- | --------------------------------------------------- |
+| `version`           | Must currently be `1`                               |
+| `schemaFingerprint` | Optional schema fingerprint, at most 255 characters |
+| `columns`           | At most 200 column entries                          |
+| `columns[].key`     | Schema column key, from 1 through 100 characters    |
+| `columns[].visible` | Boolean                                             |
+| `columns[].width`   | `auto` or an integer from `1` through `2000`        |
+
+The standard API requires an authenticated user: load, save, and reset all use the current user as the layout owner. Public SSR pre-hydration also does not read this private user state in advance, so a server-side render does not treat a user layout as established first-render truth.
+
+## Compatibility when the schema changes
+
+Before using a profile, the table reconciles it with the current schema instead of trusting its saved JSON directly:
+
+1. It discards empty keys, invalid widths, invalid visibility values, later duplicate entries, and other malformed profile entries.
+2. It discards old columns that no longer exist in the current schema.
+3. It regroups columns into the schema-defined left, center, and right fixed regions; a persisted order is retained only inside its original region.
+4. It appends new schema columns to their region, using the schema width or `auto` when the schema does not define a width.
+5. It excludes the runtime row-selection column.
+
+Therefore, users normally do not need to clean up an old profile manually after fields are added, removed, or repinned. To return entirely to the current schema default layout, use **Reset** in Column Configuration.
+
+## Standard resource-page runtime path
+
+This is the simplified flow when a standard resource page saves a column configuration:
+
+```text
+tableActionBulk in the DTO
+    ↓
+edition-specific blockToolbarBulk
+    ↓
+actionColumnConfig dialog
+    ↓
+blockPage (route.path → layoutKey)
+    ↓
+a-layoutprofile load / save / reset
+    ↓
+reconcileTableLayout(...)
+    ↓
+effective ZTable layout
+    ↓
+column visibility / order / width / pinned-column rendering
+```
+
+In that flow:
+
+- `blockPage` supplies a Column Configuration draft only after the table reference, table-column metadata, layout-profile model, and authenticated state are ready.
+- `actionColumnConfig` edits the draft and reconciles it again before saving.
+- `ZTable` derives column visibility, order, and numeric widths from its effective layout.
+- Pinned-column state still comes from the schema's `rest.fixed`, not from the profile.
+
+`training-student:student` is a complete Basic reference: its list DTO uses `basic-table:actionColumnConfig`, and its field schema defines defaults with `ZovaRender.visible(...)`, `ZovaRender.order(...)`, and `ZovaRender.column(...)`.
+
+## When using `ZTable` directly
+
+A direct `ZTable` consumer can pass a `layout`:
+
+```tsx
+<ZTable data={this.students} schema={this.schemaRow} layout={this.layout} />
+```
+
+The table still reconciles that layout with the current schema and applies visibility, order, width, and schema-defined fixed regions. However, direct `ZTable` use does not automatically provide a personal-profile loader, saver, resetter, or Column Configuration toolbar.
+
+When a page is not a standard resource list page, its owner must decide:
+
+1. where the layout comes from;
+2. how it is loaded, saved, and reset for the relevant user and page scope;
+3. how the page keeps its state consistent after a layout changes.
+
+For ordinary resource CRUD lists, prefer the existing `basic-page` or `start-page` blockPage/blockTable flow instead of rebuilding the persistence path.
+
+## Troubleshooting
+
+| Symptom                                                     | What to check                                                                                                                                                      |
+| ----------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| The toolbar has no Column Configuration button              | Confirm that the page has the action for the active edition, uses the correct `blockToolbarBulk`, and does not filter the action through toolbar permission rules. |
+| Clicking it does not open a dialog                          | Confirm that the page uses standard `blockPage` and `blockTable`, and that table metadata and authenticated state are ready.                                       |
+| The layout is not restored after save                       | Confirm that the same user visits the same route path, Save was clicked, and no frontend or API request failed.                                                    |
+| A new column does not follow the old profile's order        | This is expected: new columns are appended to their fixed region with current schema defaults.                                                                     |
+| A column cannot move to another side                        | This is the schema `fixed`-region constraint. Change the schema, not the user profile.                                                                             |
+| A hidden system field should appear in Column Configuration | Do not use a profile for this. Check whether the field uses `ZovaRender.visible(false)`.                                                                           |
+| A direct `ZTable` has no save behavior                      | The `layout` prop is only a layout input; its owner is responsible for persistence.                                                                                |
+
+## Related documentation
+
+- [Table Guide](/frontend/table-guide): table public APIs, schema column metadata, and `tableCell`.
+- [Table + Resource CRUD Cookbook](/frontend/table-resource-crud-cookbook): how a standard resource list combines filter, toolbar, table, and pager blocks.
+- [Resource List Page Deep Dive](/frontend/resource-list-page-deep-dive): the route-to-`blockPage`/`blockTable`/`ZTable` runtime path.
+- [Zova Table Under the Hood](/frontend/zova-table-under-the-hood): schema metadata, table metadata, and render runtime.
+- [Zova Table Source Reading Map](/frontend/zova-table-source-reading-map): source-reading order for deeper implementation analysis.

package/repo-docs/frontend/component-guide.md

@@ -80,36 +80,9 @@ This matters because the wrapper is not just a naming convenience. It is part of
 
 ## Controller load boundaries
 
-A component Controller, optional Style bean, and optional Render bean load in that order. While that asynchronous work is pending, Zova can render a loading boundary; an unhandled initialization failure renders an error boundary.
+A component or page Controller, optional Style bean, and optional Render bean load in that order. While that initialization chain is pending, Zova can render a loading fallback; an unhandled initialization failure can render an error fallback.
 
-```ts
-@Controller()
-class ControllerReport extends BeanControllerBase {
-  static $componentOptions: IComponentOptions = {
-    boundary: {
-      loading: { delay: 500 },
-      renderMode: 'inline',
-      retry: true,
-    },
-  };
-}
-```
-
-`retry` is disabled by default. Enable it only when creating a fresh Controller → Style → Render graph and running the Controller initialization again is safe. In particular, do not opt in for initialization that can repeat a non-idempotent external effect without its own idempotency or recovery contract.
-
-Error rendering keeps Controller ownership first. A Controller override may receive the retry action as its trailing argument; otherwise the application boundary renderer receives it:
-
-```ts
-protected renderError(error, renderMode, retry?) {
-  return null;
-}
-
-config.boundary.renderError(ctx, error, renderMode, retry?);
-```
-
-The callback is optional because retry may be disabled or unavailable. Existing error renderers that accept only `error` or `error, renderMode` remain valid. When a Controller provides its own error renderer, Zova does not wrap that output with an application retry control; the Controller decides whether to present the action.
-
-For SSR, a server-selected error fallback remains the client’s first hydration result. Retry becomes interactive only after the component has mounted, so the server HTML and hydration-time client output stay equivalent. A retry then creates a fresh client-side load graph; it does not rerun the failed Controller instance in place.
+This is a Controller-load boundary, not a generic render, event-handler, or post-initialization async-error boundary. For options, renderer precedence, retry safety, SSR hydration, and the Cabloy Basic / Cabloy Start presentation split, see [Controller Load Boundary Guide](/frontend/controller-boundary-guide).
 
 ## Reference the component instance