cabloy 5.1.65 → 5.1.67

package/.claude/skills/cabloy-resource-field-update/SKILL.md

@@ -156,6 +156,12 @@ For enum-like numeric or string values, prefer an explicit constrained schema su
 
 - `z.union([z.literal(1), z.literal(2), z.literal(3)])`
 
+Ordering rule:
+
+- when that explicit zod schema is passed into `@Api.field(...)`, put it as the **last argument**
+- keep helper metadata such as `v.xxx(...)` and `ZovaRender.xxx(...)` before the zod schema
+- otherwise helpers written after the zod schema may stop taking effect
+
 Then check whether DTOs are already inferred through patterns such as:
 
 - `$Dto.create(...)`

package/CHANGELOG.md

@@ -1,5 +1,60 @@
 # Changelog
 
+## 5.1.67
+
+### Features
+
+- Add nested training record subjects.
+- Update application features and workflows.
+
+### Bug Fixes
+
+- Clarify `Api.field` Zod schema ordering.
+
+## 5.1.66
+
+### Features
+
+- Add the Vona master-detail scaffold workflow.
+- Add details action boilerplates.
+- Add a details view action.
+- Add dialog-based detail creation.
+- Add a detail edit dialog.
+- Enhance modal close controls.
+- Improve dialog viewport sizing.
+- Improve detail row handling.
+- Support DTO metadata replacement.
+
+### Bug Fixes
+
+- Validate canonical suite names across CLI commands.
+- Validate canonical module names across CLI commands.
+- Validate canonical master-detail module names.
+- Support `dtoClass` fields in DTO mutation.
+- Normalize relation table identity comparisons.
+
+### Improvements
+
+- Remove Zova CLI canonical helper shims.
+- Extract a generic file content patch helper.
+- Unify master-detail patch runners.
+- Extract master path helpers.
+- Extract locale and metadata helper flow.
+- Extract master DTO string builders.
+- Extract detail metadata patch helper.
+- Extract master model and service patch helpers.
+- Extract detail entity patch helpers.
+- Split master-detail detail mode helpers.
+- Extract master-detail DTO patch helpers.
+- Streamline master-detail scene and locale loops.
+- Simplify the master-detail DTO rendering flow.
+- Support detail render context in dialog forms.
+- Move the detail dialog form to the detail service.
+- Extract the details block form component.
+- Extract the details dialog form helper.
+- Align the `actionCreate` dialog style.
+- Use a `Set` for relation identity lookup.
+
 ## 5.1.65
 
 ### Features

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

@@ -132,7 +132,7 @@ const referenceGroups = [
   },
 ];
 
-const GA_MEASUREMENT_ID = process.env.GA_MEASUREMENT_ID;
+const GA_MEASUREMENT_ID = 'G-2NYR9RGRL4'; // process.env.GA_MEASUREMENT_ID;
 const gaHead = GA_MEASUREMENT_ID
   ? [
       [

package/cabloy-docs/backend/crud-workflow.md

@@ -100,6 +100,39 @@ A practical rule is:
 - refine the generated code when response contracts, DTO behavior, controller metadata, model behavior, or test flow need stronger domain-specific semantics
 - avoid replacing the generated thread wholesale unless the framework shape truly does not fit the use case
 
+## Aggregate detail scaffolding
+
+When the business shape is not a standalone CRUD resource but a master resource that owns a nested detail collection, use the master-detail generator instead of hand-wiring the relation and DTO thread.
+
+Example:
+
+```bash
+npm run vona :tools:masterDetail student -- --module=training-student --detailModule=training-record --detailResourceName=record --relationName=trainingRecords --fk=studentId --detailMode=aggregate
+```
+
+This command is intended to scaffold the aggregate-detail thread that the `training-student` / `training-record` specimen demonstrates:
+
+- master model `hasMany` relation
+- master service `include` lifecycle
+- master-side nested detail DTOs
+- built-in `basic-details` bulk/row actions
+- detail FK persistence and index wiring
+
+For `--module` and `--detailModule`, use canonical Vona module relative names such as `training-student` and `training-record`, not package names such as `vona-module-training-student`.
+
+### Two supported detail-module modes
+
+Use `--detailMode=aggregate` when the detail module should remain entity/model/meta-only and should not expose its own standalone controller/service resource surface.
+
+Use `--detailMode=standalone` when the detail module should participate in the master aggregate but also keep its own standalone resource surface.
+
+A practical rule is:
+
+- choose `aggregate` when the detail is owned and managed primarily inside the master workflow
+- choose `standalone` when the detail also needs independent resource entry/use cases
+
+The generator should be the default starting point for this pattern, and manual refinement should come afterward.
+
 ## Relationship to DTO inference and OpenAPI
 
 The generated thread is also part of the broader contract-emission path.

package/cabloy-docs/backend/master-detail-workflow.md

@@ -0,0 +1,149 @@
+# Master-Detail Workflow
+
+This guide explains how to scaffold a backend master-detail aggregate in the Cabloy monorepo.
+
+## Why this page matters
+
+Some business shapes are not best expressed as two unrelated CRUD resources.
+
+A common pattern is:
+
+- one master resource owns the aggregate lifecycle
+- one detail resource is edited as a nested collection under the master
+- the detail may or may not also expose its own standalone resource surface
+
+The `training-student` + `training-record` specimen in the current repo demonstrates this pattern.
+
+## Use the generator first
+
+When the requirement is “add details under a master resource,” prefer the master-detail generator before hand-wiring relation, DTO, and service changes.
+
+Example:
+
+```bash
+npm run vona :tools:masterDetail student -- --module=training-student --detailModule=training-record --detailResourceName=record --relationName=trainingRecords --fk=studentId --detailMode=aggregate
+```
+
+A practical reading of the arguments is:
+
+- `student`: master resource name
+- `--module=training-student`: master module
+- `--detailModule=training-record`: detail module
+- `--detailResourceName=record`: detail resource name inside the detail module
+- `--relationName=trainingRecords`: master-side `hasMany` relation name
+- `--fk=studentId`: detail-side FK field
+- `--detailMode=...`: whether the detail keeps a standalone resource surface
+
+## Module naming rule
+
+For `--module` and `--detailModule`, use the canonical Vona module relative name such as `training-student` or `training-record`.
+
+A practical rule is:
+
+- use the module relative name itself
+- do not pass the package name such as `vona-module-training-student`
+- do not append an extra suffix that changes the canonical module identity
+
+This matters because the CLI resolves modules by their canonical relative names.
+
+## What the generator scaffolds
+
+The generator is designed to create the aggregate-detail thread, including:
+
+1. master model relation wiring
+2. master service `include` lifecycle for create/view/update/delete
+3. master-side nested detail DTOs
+4. built-in `basic-details` UI metadata for row/bulk actions
+5. detail FK persistence field in the detail entity
+6. detail schema/index support for the FK
+
+This keeps the structural pattern consistent before domain-specific refinement starts.
+
+## Two supported detail-module modes
+
+### Aggregate mode
+
+Use:
+
+```bash
+--detailMode=aggregate
+```
+
+In this mode, the detail module remains:
+
+- entity/model/meta-based
+- owned by the master aggregate
+- without a standalone controller/service resource surface
+
+Choose this mode when the detail is primarily edited only through the master workflow.
+
+### Standalone mode
+
+Use:
+
+```bash
+--detailMode=standalone
+```
+
+In this mode, the detail module:
+
+- still participates in the master aggregate
+- keeps or creates its own standalone controller/service resource surface
+
+Choose this mode when the detail also needs independent entry points, workflows, or resource-level access outside the master editing flow.
+
+## Practical decision rule
+
+Use aggregate mode when:
+
+- the detail has no meaningful lifecycle outside the master
+- independent detail routes would add noise rather than value
+- the master should remain the clear aggregate root
+
+Use standalone mode when:
+
+- the detail also needs independent CRUD/use cases
+- external workflows need to query or mutate detail items directly
+- the detail has user-facing or integration-facing behavior beyond nested editing
+
+## Specimen mapping
+
+The current specimen maps like this:
+
+- master relation: `vona/src/suite/a-training/modules/training-student/src/model/student.ts`
+- master service include lifecycle: `vona/src/suite/a-training/modules/training-student/src/service/student.ts`
+- master nested DTOs: `vona/src/suite/a-training/modules/training-student/src/dto/studentCreate.tsx`, `studentUpdate.tsx`, `studentView.tsx`
+- detail row/bulk metadata: `vona/src/suite/a-training/modules/training-student/src/dto/detailRecordResItem.tsx`
+- detail FK field: `vona/src/suite/a-training/modules/training-record/src/entity/record.tsx`
+
+This is the reference shape the generator aims to standardize.
+
+## Recommended workflow
+
+1. run `:tools:masterDetail`
+2. inspect the generated relation, DTO, and service thread
+3. refine entity fields and validation rules for the domain
+4. refine detail columns/actions when the default `basic-details` behavior is not enough
+5. refresh and verify metadata/build outputs
+
+## Relationship to CRUD workflow
+
+Use [CRUD Workflow](/backend/crud-workflow) when the target is primarily a standalone resource.
+
+Use this page when the target is a master resource with a nested detail collection.
+
+The two workflows are complementary:
+
+- CRUD scaffolds standalone backend threads
+- master-detail scaffolds aggregate ownership plus nested detail editing
+
+## Verification checklist
+
+After generation:
+
+1. confirm the master model contains the `hasMany` relation
+2. confirm master service create/view/update/delete includes the detail relation
+3. confirm master create/update/view DTOs include nested detail DTO wiring
+4. confirm the detail entity contains the FK field
+5. confirm detail schema/index output includes the FK support
+6. if standalone mode was chosen, confirm the detail module still exposes its standalone resource surface

package/cabloy-docs/frontend/bean-scene-authoring.md

@@ -213,7 +213,7 @@ A practical rule is:
 
 This is useful when one scene needs multiple scaffold shapes for distinct frontend authoring paths.
 
-Representative built-in examples include the `command` scene, which exposes `commandBulk` and `commandRow` variants, and the `tableCell` scene, which exposes a `tableActionRow` variant in module metadata.
+Representative built-in examples include the `command` scene, which exposes `commandBulk`, `commandRow`, and `commandDetailsRow` variants, and the `tableCell` scene, which exposes `tableActionRow` and `detailsActionRow` variants in module metadata.
 
 For the built-in command scene’s runtime model, helper bases, metadata flow, and source-reading path, see [Command Scene Authoring](/frontend/command-scene-authoring).
 

package/cabloy-docs/frontend/cli.md

@@ -87,9 +87,20 @@ The built-in `command` scene is the clearest current example:
 npm run zova :create:bean command test -- --module=training-student
 npm run zova :create:bean command test -- --module=training-student --boilerplate=commandBulk
 npm run zova :create:bean command test -- --module=training-student --boilerplate=commandRow
+npm run zova :create:bean command test -- --module=training-student --boilerplate=commandDetailsRow
 ```
 
-Use the default template for the command shape without the bulk/row helper bases, `commandBulk` for resource-oriented bulk commands, and `commandRow` for row-oriented commands that need both `resource` and `id`.
+Use the default template for the command shape without helper bases, `commandBulk` for resource-oriented bulk commands, `commandRow` for table-row commands that need `resource` and `id`, and `commandDetailsRow` for detail-row commands that run against `ICommandDetailsRowOptionsBase`.
+
+The same naming rule also applies to `:create:component`. For example, the built-in component variants now include `detailsActionBulk`, alongside variants such as `formField`, `formActionRow`, `tableActionBulk`, `blockPage`, and `blockPageEntry`.
+
+Representative component example:
+
+```bash
+npm run zova :create:component actionCreate -- --module=training-student --boilerplate=detailsActionBulk
+```
+
+Use `detailsActionBulk` when you need a detail-page bulk action controller scaffold that registers into `IResourceDetailsActionBulkRecord` and receives `IJsxRenderContextDetails` through host injection.
 
 For the command-scene runtime model and source-reading path, see [Command Scene Authoring](/frontend/command-scene-authoring).
 

package/cabloy-docs/frontend/command-scene-authoring.md

@@ -284,7 +284,7 @@ Important pieces:
   - the result-type carrier used in the command option contract
 - `IDecoratorCommandOptions`
   - the base decorator options shape
-- `ICommandOptionsBase`, `ICommandBulkOptionsBase`, `ICommandRowOptionsBase`
+- `ICommandOptionsBase`, `ICommandBulkOptionsBase`, `ICommandRowOptionsBase`, `ICommandDetailsRowOptionsBase`
   - shared option contracts for common command patterns
 - `TypeCommandOptions<K>`
   - typed command reference shape
@@ -336,6 +336,7 @@ The `zovaModule.onions.command` metadata confirms:
 - default `boilerplate`
 - `boilerplateCommandBulk`
 - `boilerplateCommandRow`
+- `boilerplateCommandDetailsRow`
 
 The CLI command shape is currently exposed by:
 
@@ -373,6 +374,16 @@ Use the row variant when the command should resolve `resource` and `id` through
 npm run zova :create:bean command test -- --module=training-student --boilerplate=commandRow
 ```
 
+### `commandDetailsRow` boilerplate
+
+Use the details-row variant when the command should operate in the details-row action path and type its options through `ICommandDetailsRowOptionsBase`:
+
+```bash
+npm run zova :create:bean command test -- --module=training-student --boilerplate=commandDetailsRow
+```
+
+A representative built-in consumer is `basic-details/src/bean/command.delete.tsx`, which uses the details render context and row information from the current detail table cell.
+
 For the cross-scene lookup table, also see [Bean Scene Boilerplate Variants](/reference/bean-scene-boilerplates).
 
 ## Representative built-in examples

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

@@ -24,6 +24,16 @@ Example: create a component named `card` in module `training-student`.
 npm run zova :create:component card -- --module=training-student
 ```
 
+The component generator also supports named boilerplate variants through `--boilerplate=...`.
+
+A practical current example is a detail-page bulk action controller scaffold:
+
+```bash
+npm run zova :create:component actionCreate -- --module=training-student --boilerplate=detailsActionBulk
+```
+
+That variant generates a controller registered in `IResourceDetailsActionBulkRecord` and injects `IJsxRenderContextDetails` from the host details runtime.
+
 ## Controller definition
 
 Representative component controller shape:

package/cabloy-docs/frontend/permission-formscene-action-visibility-guide.md

@@ -195,6 +195,46 @@ And that bulk hint type does not have `formScene`.
 
 This is the clearest public type-level explanation for the current limitation.
 
+## 6A. Details actions have their own scene-aware visibility path
+
+The details-table action path uses a nearby but distinct contract.
+
+Relevant type-level surfaces are:
+
+- `a-openapi/src/types/detail/detailsActionRow.ts`
+- `a-openapi/src/types/detail/detailsActionBulk.ts`
+- `a-openapi/src/types/permissions.ts`
+
+The current source confirms:
+
+- `IResourceDetailsActionRowOptionsBase` uses `permission?: IPermissionHintDetailsActionRow`
+- `IResourceDetailsActionBulkOptionsBase` uses `permission?: IPermissionHintDetailsActionBulk`
+- both details permission-hint types support `formScene`
+
+That means the details action family is scene-aware in a different way from `tableActionBulk`.
+
+A practical current example from backend DTO metadata is:
+
+```tsx
+ZovaRender.detailsActionBulk('basic-details:actionCreate', {
+  permission: { formScene: ['create', 'edit'] },
+});
+```
+
+and:
+
+```tsx
+ZovaRender.detailsActionRow('basic-details:actionDelete', {
+  permission: { formScene: ['create', 'edit'] },
+});
+```
+
+So the correct distinction is:
+
+- `tableActionBulk` does not currently support `formScene`
+- `detailsActionBulk` does support `formScene`
+- `detailsActionRow` also supports `formScene`
+
 ## 7. Why bulk actions are different today
 
 Bulk actions are typed around bulk permission hints, not row/form-scene hints.
@@ -203,9 +243,9 @@ So in current Basic source, you should not claim that bulk actions support scene
 
 This is not only a docs distinction. It is a source-confirmed contract distinction.
 
-## 8. Comparison with table row actions
+## 8. Comparison with table row actions and details actions
 
-A useful comparison file is:
+A useful table-row comparison file is:
 
 ```text
 zova/src/suite/cabloy-basic/modules/basic-table/src/bean/tableCell.actionOperationsRow.tsx
@@ -213,10 +253,25 @@ zova/src/suite/cabloy-basic/modules/basic-table/src/bean/tableCell.actionOperati
 
 This table-row action surface uses permission checks, but it does not add the same local page-entry `formScene` prefilter path as `blockToolbarRow`.
 
-That makes the current entry-page toolbar flow more specific:
+A useful details comparison set is:
+
+```text
+zova/src/suite/cabloy-basic/modules/basic-details/src/component/blockToolbarBulk/controller.tsx
+zova/src/suite/cabloy-basic/modules/basic-details/src/bean/tableCell.actionOperationsRow.tsx
+zova/src/suite/cabloy-basic/modules/basic-details/src/lib/utils.ts
+```
+
+Those files show that the details action path also performs a scene-prefilter, but the authority is different:
+
+- `blockToolbarRow` reads `$$pageEntry.formMeta.formScene`
+- `basic-details` reads `$$details.formScene` or `$celScope.formMeta.formScene`
+- the shared helper in `basic-details/src/lib/utils.ts` performs the actual `formScene` match
+
+That makes the current frontend split more precise:
 
-- it is tied to entry-page runtime context
-- it is not the universal rule for every action surface in the frontend
+- entry-page row/form actions are scene-filtered by page-entry runtime context
+- details bulk and details row actions are scene-filtered by details runtime context
+- the two paths are similar in behavior, but they are not the same runtime surface
 
 ## 9. Boundary with page meta
 
@@ -233,10 +288,17 @@ So for action visibility, the local page-entry context is the authority.
 
 ## 10. Bulk-action limitation
 
-The current public Basic source supports this rule clearly:
+The current public Basic source supports this rule clearly for the table-action family:
 
 - row/form action hints can be scene-aware
-- bulk action hints are not scene-aware today
+- table bulk action hints are not scene-aware today
+
+But the details-action family is different:
+
+- details row action hints can be scene-aware
+- details bulk action hints can also be scene-aware
+
+So do not compress these two families into one blanket rule about “bulk actions”.
 
 If a contributor needs scene-aware bulk visibility, they should first verify whether the type and runtime contracts are being extended, rather than assuming the row-action rule applies automatically.
 

package/cabloy-docs/frontend/table-cell-cookbook.md

@@ -78,6 +78,14 @@ Create a row-action variant:
 npm run zova :create:bean tableCell actionOperationsRow -- --module=training-student --boilerplate=tableActionRow
 ```
 
+Create a details-row-action variant:
+
+```bash
+npm run zova :create:bean tableCell actionDelete -- --module=training-student --boilerplate=detailsActionRow
+```
+
+Use `tableActionRow` when one table cell should compose several table-row actions together. Use `detailsActionRow` when the render resource belongs to the details-row action contract under `IResourceDetailsActionRowRecord`.
+
 The default scaffold shape is intentionally small:
 
 ```tsx
@@ -352,6 +360,8 @@ This pattern is different from a normal single-action cell because the bean ofte
 
 That is why the `tableActionRow` boilerplate exists.
 
+By contrast, the newer `detailsActionRow` boilerplate is for one detail-row action resource at a time. Its scaffold declaration-merges into `IResourceDetailsActionRowRecord` and types the options through `IResourceDetailsActionRowOptionsBase`, so it fits the details-table action path instead of the standard table-operations composition path.
+
 Representative runtime shape:
 
 ```tsx

package/cabloy-docs/fullstack/backend-metadata-to-frontend-table-actions.md

@@ -300,6 +300,85 @@ This is the same contract idea at a different UI level:
 - backend or shared page metadata chooses the action resource identity
 - frontend runtime resolves that identity to a visible action implementation
 
+## Step 7A: Detail actions follow the same contract idea inside details blocks
+
+The same contract model also appears in resource details tables.
+
+A representative backend DTO shape is:
+
+```tsx
+@Dto({
+  blocks: [
+    ZovaRender.block('basic-details:blockDetails', {
+      blocks: [
+        ZovaRender.block('basic-details:blockToolbarBulk', {
+          actions: [
+            ZovaRender.detailsActionBulk('basic-details:actionCreate', {
+              permission: { formScene: ['create', 'edit'] },
+            }),
+          ],
+        }),
+        ZovaRender.block('basic-details:blockTable'),
+      ],
+    }),
+  ],
+})
+```
+
+And the row-action column inside that detail table can look like this:
+
+```tsx
+@Api.field(
+  v.title($locale('Operations')),
+  ZovaRender.order(1, 'max'),
+  ZovaRender.cell('basic-details:actionOperationsRow', {
+    actions: [
+      ZovaRender.detailsActionRow('basic-details:actionUpdate'),
+      ZovaRender.detailsActionRow('basic-details:actionDelete'),
+    ],
+  }),
+)
+_operationsRow?: unknown;
+```
+
+This shows a practical three-part scaffold relationship:
+
+1. `detailsActionBulk`
+   - creates a detail-level bulk action controller resource
+   - declaration-merges into `IResourceDetailsActionBulkRecord`
+   - is the right fit for actions such as add/create on the whole details block
+2. `detailsActionRow`
+   - creates one detail-row action cell resource
+   - declaration-merges into `IResourceDetailsActionRowRecord`
+   - is the right fit for update/delete style actions attached to one detail row
+3. `commandDetailsRow`
+   - creates the command bean used when a detail-row action should delegate its semantics to the command scene
+   - types options through `ICommandDetailsRowOptionsBase`
+   - is the right fit when the visible detail-row action should call `$performCommand(...)` instead of embedding all behavior directly in the cell bean
+
+A representative built-in flow in `basic-details` is:
+
+- `basic-details:actionCreate`
+  - a component/controller resource for `detailsActionBulk`
+- `basic-details:actionUpdate`
+  - a `tableCell` resource for `detailsActionRow`
+- `basic-details:actionDelete`
+  - a `tableCell` resource for `detailsActionRow`
+- `basic-details:delete`
+  - a command bean that matches the `commandDetailsRow` execution pattern
+
+A practical reading takeaway is:
+
+- **details bulk actions** usually coordinate the whole details block
+- **details row actions** usually own the visible row-level interaction
+- **details row commands** are the reusable semantic layer when one row action should execute through the command scene
+
+So even though the UI surface is a detail table instead of a top-level resource list, the architecture still follows the same rule:
+
+- backend metadata chooses resource identities
+- frontend resources implement the interaction
+- optional command beans keep the action semantics reusable and scene-aware
+
 ## Step 8: Where the forward chain enters for custom actions
 
 So far, everything could still be handled by built-in commands and built-in resources.
@@ -400,6 +479,7 @@ Typical examples:
 - switch one field to `basic-table:actionView`
 - add an operations row using existing update/delete actions
 - add a custom table-cell renderer that backend metadata points to
+- add a details block action chain with `detailsActionBulk` and `detailsActionRow` resources
 
 ### Mostly forward-chain work
 
@@ -458,8 +538,9 @@ If you want the shortest path to a correct table-action implementation, use this
 3. regenerate frontend API consumers when backend contract changes
 4. keep frontend model follow-up thin and semantic
 5. point backend row metadata to the intended built-in or custom table-action resources
-6. verify the resource-page block chain still feeds the right schema into `ZTable`
-7. verify the visible row action in Admin
+6. for details-table work, also align `detailsActionBulk`, `detailsActionRow`, and any `commandDetailsRow` delegation path
+7. verify the resource-page block chain still feeds the right schema into `ZTable`
+8. verify the visible row action in Admin
 
 ## Verification checklist
 

package/cabloy-docs/reference/bean-scene-boilerplates.md

@@ -44,13 +44,18 @@ These backend entries come from the current `vonaModule.onions` metadata in `a-a
 
 ### Current built-in scenes with variants
 
-| Scene       | Default metadata key | Named variant keys                                | Example command pattern                                                                              | Source module           |
-| ----------- | -------------------- | ------------------------------------------------- | ---------------------------------------------------------------------------------------------------- | ----------------------- |
-| `command`   | `boilerplate`        | `boilerplateCommandBulk`, `boilerplateCommandRow` | `npm run zova :create:bean command test -- --module=training-student --boilerplate=commandRow`       | `zova-module-a-command` |
-| `tableCell` | `boilerplate`        | `boilerplateTableActionRow`                       | `npm run zova :create:bean tableCell test -- --module=training-student --boilerplate=tableActionRow` | `zova-module-a-table`   |
+| Scene       | Default metadata key | Named variant keys                                                                | Example command pattern                                                                                | Source module           |
+| ----------- | -------------------- | --------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------ | ----------------------- |
+| `command`   | `boilerplate`        | `boilerplateCommandBulk`, `boilerplateCommandRow`, `boilerplateCommandDetailsRow` | `npm run zova :create:bean command test -- --module=training-student --boilerplate=commandDetailsRow`  | `zova-module-a-command` |
+| `tableCell` | `boilerplate`        | `boilerplateTableActionRow`, `boilerplateDetailsActionRow`                        | `npm run zova :create:bean tableCell test -- --module=training-student --boilerplate=detailsActionRow` | `zova-module-a-table`   |
 
 These frontend entries come from the current `zovaModule.onions` metadata in `a-command` and `a-table`.
 
+In practical terms:
+
+- `commandDetailsRow` is the built-in command-scene scaffold for detail-row command beans
+- `detailsActionRow` is the built-in `tableCell` scaffold for detail-row action cells under `IResourceDetailsActionRowRecord`
+
 For the built-in command scene’s runtime model and helper-base patterns, see [Command Scene Authoring](/frontend/command-scene-authoring).
 
 ## Guidance for AI-assisted development

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "cabloy",
-  "version": "5.1.65",
+  "version": "5.1.67",
   "gitHead": "2c5c19284bab738e492856189acb6fad74b8a7b7",
   "description": "A Node.js fullstack framework",
   "keywords": [

package/vona/packages-cli/cabloy-cli/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@cabloy/cli",
-  "version": "3.1.18",
+  "version": "3.1.23",
   "gitHead": "a79189b882c17af5911573896a781bbb0046d37d",
   "description": "@cabloy/cli",
   "keywords": [