cabloy 5.1.60 → 5.1.62

package/cabloy-docs/frontend/a-openapi-under-the-hood.md

@@ -0,0 +1,248 @@
+# OpenAPI Runtime Under the Hood
+
+This guide explains the lower-level runtime of `a-openapi` in Zova through the current public Cabloy Basic source.
+
+Use this page when you want to understand:
+
+- how `$sdk` becomes available on beans
+- what `ModelSdk` and `SysSdk` each own
+- how bootstrap and permissions loading work
+- how request/query/filter/body/row/paged schema surfaces are derived
+- why `a-openapi` is a lower-level shared runtime substrate for resource, model, and table consumers
+
+## Why this page exists
+
+Several existing docs already explain usage and positioning around the server-data ladder:
+
+- [Server Data](/frontend/server-data)
+- [SDK Guide](/frontend/sdk-guide)
+- [OpenAPI SDK Guide](/frontend/openapi-sdk-guide)
+- [API Schema Guide](/frontend/api-schema-guide)
+
+What those pages do not isolate directly is the source-first runtime path inside `a-openapi` itself.
+
+That is the gap this page fills.
+
+## The shortest accurate mental model
+
+A practical mental model is:
+
+1. `a-openapi` injects `$sdk` onto beans through its module monkey
+2. `$sdk` resolves a locale-scoped `ModelSdk`
+3. `ModelSdk` exposes bootstrap, permissions, sdk, schema, Zod, and default-value helpers
+4. `SysSdk` owns the lower cache/fetch layer for bootstrap/docs/schemas
+5. `schema.ts` extracts request/query/filter/body/row/paged schema surfaces and applies scene-aware property selection
+6. downstream resource/model/table consumers reuse those lower-level surfaces rather than rebuilding them independently
+
+That means `a-openapi` is not only about generated SDK usage. It is also the lower-level schema/runtime bridge beneath the higher-level frontend runtime.
+
+## Source-confirmed reading path
+
+When reading this topic, use this order:
+
+1. `zova/src/suite-vendor/a-zova/modules/a-openapi/src/monkey.ts`
+2. `zova/src/suite-vendor/a-zova/modules/a-openapi/src/model/sdk.ts`
+3. `zova/src/suite-vendor/a-zova/modules/a-openapi/src/bean/sys.sdk.ts`
+4. `zova/src/suite-vendor/a-zova/modules/a-openapi/src/lib/schema.ts`
+5. `zova/src/suite-vendor/a-zova/modules/a-openapi/src/types/rest.ts`
+6. optional supporting files:
+   - `zova/src/suite-vendor/a-zova/modules/a-openapi/src/types/sdk.ts`
+   - `zova/src/suite-vendor/a-zova/modules/a-openapi/src/config/config.ts`
+
+That order moves from bean-level injection, to the locale-scoped model surface, to the lower fetch/cache layer, to the schema extraction layer, and finally to the schema/type contract.
+
+## `$sdk` injection and locale-scoped runtime
+
+The injection layer lives in:
+
+```text
+zova/src/suite-vendor/a-zova/modules/a-openapi/src/monkey.ts
+```
+
+The key source-confirmed behavior is:
+
+- `beanInit(...)` defines `$sdk` on bean instances
+- `$sdk` points to a ref-like current `ModelSdk`
+- `moduleLoaded(...)` loads the SDK model for the current locale
+- locale changes trigger `_loadSdk()` again
+
+That means `$sdk` is not a static global object.
+
+It is a runtime-injected, locale-scoped model surface.
+
+## `ModelSdk` responsibilities
+
+The selector-backed model lives in:
+
+```text
+zova/src/suite-vendor/a-zova/modules/a-openapi/src/model/sdk.ts
+```
+
+The current source confirms that `ModelSdk` is:
+
+- `@Model({ enableSelector: true })`
+- selector-backed by locale
+- responsible for:
+  - `getBootstrap(resource)`
+  - `getPermissions(resource)`
+  - `getSdk(api, method)`
+  - `getSchema(schemaName)`
+  - `getZodSchema(schemaName)`
+  - `getSchemaDefaultValue(schemaName)`
+  - `createApiSchemas(api, method)`
+  - `loadSchemaProperties(schema, schemaScene)`
+  - `schemaToZodSchema(schema)`
+
+A practical reading rule is:
+
+- `ModelSdk` is the higher model-facing façade over lower OpenAPI runtime state
+- it is the surface most downstream consumers actually reuse
+
+## `SysSdk` responsibilities
+
+The lower runtime owner lives in:
+
+```text
+zova/src/suite-vendor/a-zova/modules/a-openapi/src/bean/sys.sdk.ts
+```
+
+Its main jobs are:
+
+- store loaded bootstraps
+- store loaded schemas
+- store loaded operation SDK entries by API and method
+- fetch bootstrap data
+- fetch operation-level OpenAPI docs
+- cache schemas and operation objects in reactive stores
+- reload caches during SSR HMR reload paths
+
+This is the lower-level owner beneath `ModelSdk`.
+
+A practical rule is:
+
+- `ModelSdk` is the model-facing surface
+- `SysSdk` is the lower cache/fetch owner
+
+## Bootstrap and permissions loading
+
+The bootstrap path is defined in `ModelSdk.getBootstrap(resource)`.
+
+The source confirms that:
+
+- bootstrap data is loaded first
+- permissions are then loaded through `getPermissions(resource)`
+- on the server, permissions are autoloaded as part of the bootstrap path
+- on the client, permission queries are refetched when needed
+
+That means bootstrap and permissions are part of the same lower-level OpenAPI/runtime ladder, not unrelated utilities.
+
+## `getSdk(...)` and schema preloading
+
+The operation-level SDK path is centered on:
+
+- `ModelSdk.getSdk(api, apiMethod)`
+- `SysSdk.loadSdk(...)`
+
+The source confirms that:
+
+- one operation-level SDK entry is keyed by API path and request method
+- schema docs are fetched through the lower OpenAPI fetch path
+- component schemas referenced by the operation document are cached into `SysSdk.schemas`
+- operation metadata is cached into `SysSdk.sdks`
+
+That means `getSdk(...)` is not only a fetch helper. It is also a preloading point for the schema runtime that later powers query/body/row/filter access.
+
+## `createApiSchemas(...)` and derived schema surfaces
+
+The high-value consumer-facing helper is:
+
+- `createApiSchemas(api, method)`
+
+The source confirms that it exposes these derived surfaces:
+
+- `query`
+- `filter`
+- `requestBody`
+- `responseBody`
+- `paged`
+- `row`
+
+This is the most practical lower-level bridge from raw OpenAPI docs into the higher-level resource, form, and table runtimes.
+
+A practical reading rule is:
+
+- downstream consumers should reuse these derived schema surfaces
+- they should not rebuild request/query/body/row extraction rules independently
+
+## `schema.ts` and scene-aware property loading
+
+The canonical schema extraction layer lives in:
+
+```text
+zova/src/suite-vendor/a-zova/modules/a-openapi/src/lib/schema.ts
+```
+
+This file owns the main lower-level helpers for:
+
+- request body schema extraction
+- response body schema extraction
+- request query schema extraction
+- filter-schema extraction
+- scene-aware property loading
+- JSON-schema-to-Zod conversion
+
+The most important scene-aware rule is in `loadSchemaProperties(...)`:
+
+- property metadata can be extended by `rest.*`
+- scene-specific overlays such as `table`, `form`, `form-view`, `form-create`, and `filter` are applied
+- field ordering is resolved through `rest.order`
+
+That means `a-openapi` is not only a transport/schema lookup layer.
+
+It is also the lower-level metadata shaping layer for schema-driven UI behavior.
+
+## Current consumers that prove the contract
+
+The clearest current consumers of `a-openapi` runtime are:
+
+- `rest-resource/src/model/resource.ts`
+- list and entry page shells that reuse `ModelResource`
+- table/form runtimes that consume schema surfaces derived from `createApiSchemas(...)` and `loadSchemaProperties(...)`
+
+This is enough to show that `a-openapi` should be understood as shared runtime substrate rather than one isolated SDK helper.
+
+## What this page does not re-explain
+
+This page does **not** fully re-explain:
+
+- how to configure or generate OpenAPI SDK output -> see [OpenAPI SDK Guide](/frontend/openapi-sdk-guide)
+- the broader server-data abstraction ladder -> see [Server Data](/frontend/server-data)
+- how `$apiSchema` is positioned conceptually -> see [API Schema Guide](/frontend/api-schema-guide)
+- downstream resource-owner or table runtime behavior -> see the relevant resource/table deep dives
+
+Its job is only to explain the lower-level `a-openapi` runtime and source path.
+
+## Where to read next
+
+Use these next steps depending on your question:
+
+- if you want the broader server-data ladder, read [Server Data](/frontend/server-data)
+- if you want OpenAPI generation/config usage, read [OpenAPI SDK Guide](/frontend/openapi-sdk-guide)
+- if you want schema-driven UI positioning, read [API Schema Guide](/frontend/api-schema-guide)
+- if you want the resource-owner consumer side, read [ModelResource Internals Deep Dive](/frontend/model-resource-internals-deep-dive)
+- if you want the table/resource consumer side, read [Zova Table Under the Hood](/frontend/zova-table-under-the-hood) and the resource deep dives
+
+## Final takeaway
+
+The most accurate way to read `a-openapi` is not as one generated-client helper.
+
+Read it as the lower-level schema/runtime bridge that:
+
+- injects `$sdk`
+- scopes SDK/runtime state by locale
+- loads bootstrap, permissions, operation docs, and component schemas
+- derives request/query/filter/body/row/paged schema surfaces
+- applies scene-aware schema-property shaping
+- supports higher-level resource, form, and table consumers
+
+That is the source-confirmed role of `a-openapi` in the current Cabloy Basic frontend architecture.

package/cabloy-docs/frontend/a-router-guide.md

@@ -0,0 +1,307 @@
+# A-Router Guide
+
+This guide explains the router runtime boundary in Zova through the current public Cabloy Basic source:
+
+```text
+zova/src/suite-vendor/a-zova/modules/a-router
+```
+
+Use this page when you want to understand:
+
+- what `a-router` is responsible for
+- what `a-router` is **not** responsible for
+- how module route records become operational router records
+- how system startup and app startup cooperate around routing
+- where `$route`, `$params`, and `$query` reach page controllers
+- where `a-router` stops and router-view host behavior begins
+
+## Why this page exists
+
+The existing router docs already explain several important layers:
+
+- [Page Route Guide](/frontend/page-route-guide) explains the public route-record surface
+- [Navigation Guards Guide](/frontend/navigation-guards-guide) explains route policy hooks
+- [Page Params Guide](/frontend/page-params-guide) and [Page Query Guide](/frontend/page-query-guide) explain typed route-state authoring
+- [Zova Router Under the Hood](/frontend/zova-router-under-the-hood) explains the broader runtime cooperation
+- [Router View Hosts Guide](/frontend/router-view-hosts-guide) explains how routed pages are hosted after route resolution
+
+What those pages do not isolate directly is the module boundary of `a-router` itself.
+
+That is the gap this page fills.
+
+In the current Basic source, `a-router` is not only a thin wrapper around Vue Router and not only a route-record registry. It is the runtime package that connects module route registration, router creation, startup readiness, guard flow, controller route-state injection, and the handoff into routed hosts.
+
+## The shortest accurate mental model
+
+A practical mental model is:
+
+1. modules declare route records through `routes.ts`
+2. `a-router` registers those records into the shared router during system startup
+3. `a-router` merges config routes, expands module-relative paths, synthesizes aliases, and wraps routes with layout structure when needed
+4. `a-router` makes the main router operational during app startup
+5. `a-router` guard flow lazy-loads modules and normalizes alias or fallback behavior during navigation
+6. `a-router` pushes `$route`, `$routeMatched`, `$params`, and `$query` onto page controllers
+7. the resolved routed output then enters a router-view host for page-instance ownership and keep-alive behavior
+
+That is why `a-router` is a real Zova architectural boundary rather than only a route-table utility.
+
+## What `a-router` is
+
+In the current Basic source, `a-router` is mainly these seven things:
+
+- a **module integration surface** through generated metadata
+- a **shared system router owner** through `SysRouter`
+- a **module-route registration bridge** through `monkeySys.ts`
+- an **app lifecycle and router readiness bridge** through `monkey.ts`
+- a **guard service** through `ServiceRouterGuards`
+- a **page-controller route-state injection layer** through `monkey.ts`
+- a **routed-host handoff boundary** through `routerViewBase.tsx`
+
+Those roles make `a-router` the package that turns route declarations into operational routed frontend behavior.
+
+## What `a-router` is not
+
+It is equally important to avoid over-assigning responsibilities to `a-router`.
+
+`a-router` does **not** itself own:
+
+- the authoring explanation for route records and their public meaning
+- the full typed params/query authoring story
+- the business-facing explanation for navigation policy and auth design
+- the detailed semantics of `routerViewEmpty`, `routerViewTabs`, or `routerViewStack`
+- the tabs or stack workspace models
+- the layout component implementations themselves
+
+Those responsibilities belong to other routing, host, and layout docs.
+
+So when you read `a-router`, read it as the runtime package that operationalizes routing, not as the page-authoring guide and not as the routed-host guide.
+
+## The core source-reading path
+
+When reading `a-router`, use this order:
+
+1. `zova/src/suite-vendor/a-zova/modules/a-router/src/.metadata/index.ts`
+2. `zova/src/suite-vendor/a-zova/modules/a-router/src/bean/sys.router.ts`
+3. `zova/src/suite-vendor/a-zova/modules/a-router/src/monkeySys.ts`
+4. `zova/src/suite-vendor/a-zova/modules/a-router/src/monkey.ts`
+5. `zova/src/suite-vendor/a-zova/modules/a-router/src/service/routerGuards.ts`
+6. `zova/src/suite-vendor/a-zova/modules/a-router/src/bean/bean.router.ts`
+7. `zova/src/suite-vendor/a-zova/modules/a-router/src/types/router.ts`
+8. `zova/src/suite-vendor/a-zova/modules/a-router/src/lib/routerViewBase.tsx`
+
+That order moves from integration surface, to system router ownership, to startup hooks, to navigation flow, to app-level router-view coordination, to type contract, and finally to the routed-host handoff boundary.
+
+## What each source file clarifies
+
+### `src/.metadata/index.ts`
+
+This is the generated integration map for the module.
+
+It shows that `a-router` contributes:
+
+- model export and typing for page data
+- router sys bean registration
+- router bean registration
+- router guard service registration
+- the `routerViewEmpty` component export
+- config, monkey, and scope integration
+
+This file is the best single map of how `a-router` enters the larger Zova bean, config, and component records.
+
+### `src/bean/sys.router.ts`
+
+This is the shared router owner.
+
+Its main jobs are:
+
+- create the router instance and choose history mode
+- load config routes by path and name
+- load legacy routes if present
+- register module routes into real router records
+- expand module-relative route paths and names
+- merge config-route overrides
+- synthesize alias routes when needed
+- wrap routed pages with layout routes when `meta.layout` requires it
+- expose helpers such as `getPagePath(...)`, `resolveName(...)`, and `ensureRoute(...)`
+
+This is the file that most clearly shows how a module-local route record becomes operational router structure.
+
+### `src/monkeySys.ts`
+
+This file is the system-startup route registration bridge.
+
+Its most important job is:
+
+- when a module is loading and contributes `resource.routes`, call `sysRouter._registerRoutes(module)`
+
+That matters because route registration belongs to system startup rather than being delayed until page code happens to execute.
+
+This file also exposes application-level helpers such as:
+
+- `$gotoPage(...)`
+- `$gotoHome(...)`
+- `$gotoLogin(...)`
+- `$getCurrentPagePath()`
+
+So `monkeySys.ts` is not only about route registration. It also helps define the application-facing router convenience surface.
+
+### `src/monkey.ts`
+
+This file is the app lifecycle and controller route-state bridge.
+
+Its main jobs are:
+
+- create or retrieve the main router bean
+- attach guard setup through the router-guards event flow
+- make the router operational during `appReady()`
+- inject `$router`, `$routerView`, `$pageRoute`, and `$currentRoute` onto bean instances
+- prepare controller route context
+- push `$route` and `$routeMatched` onto page controllers
+- parse typed `$params` and `$query` from page schemas and preserve stable client references
+- handle SSR/client redirect-related error behavior
+
+This is the key source file if your question is: “where do page controllers actually receive route-aware state?”
+
+## `src/service/routerGuards.ts`
+
+This file is the navigation guard runtime layer.
+
+Its main jobs are:
+
+- run `beforeEach(...)` checks
+- lazy-load modules during navigation when needed
+- normalize alias redirect behavior
+- retry route resolution after module loading when appropriate
+- handle 404/module-load preparation checks
+- emit back/forward notifications after navigation
+
+This file is the best place to read when the route exists conceptually but is not yet fully operational at navigation time.
+
+## `src/bean/bean.router.ts`
+
+This file is the app-level router bean and router-view coordination surface.
+
+Its main jobs are:
+
+- create the main app router from `SysRouter`
+- expose router APIs through the bean surface
+- register and deregister active router-view hosts
+- forward back-route and forward-route notifications to hosts
+- forward `setPageMeta(...)` updates to hosts
+
+This is the layer that connects the router runtime to routed-host controllers.
+
+## `src/types/router.ts`
+
+This file is the public type contract for the router package.
+
+It shows the extended route meta and app/bean/controller-facing router surface, including:
+
+- `RouteMeta.layout`
+- `RouteMeta.requiresAuth`
+- `RouteMeta.locale`
+- `RouteMeta.componentKeyMode`
+- `RouteMeta.componentKey`
+- `RouteMeta.tabKey`
+- `RouteMeta.keepAlive`
+- app helpers such as `$gotoPage(...)`
+- bean-level `$router`, `$routerView`, `$pageRoute`, and `$currentRoute`
+- page-controller `$route` and `$routeMatched`
+
+This is the best file to read when you want to verify what the router package promises to the rest of the application.
+
+## `src/lib/routerViewBase.tsx`
+
+This file is the handoff boundary from router runtime into routed-host behavior.
+
+What matters here is not the full host model, but the boundary itself:
+
+- `a-router` has already resolved the routed page path
+- the routed output now enters a router-view host
+- that host wraps `RouterView`, computes host-facing route meta, manages `KeepAlive`, and injects the current page route into the routed vnode
+
+This is the point where router runtime responsibility gives way to routed-host responsibility.
+
+For the detailed host layer, continue with [Router View Hosts Guide](/frontend/router-view-hosts-guide).
+
+## System startup vs app startup
+
+A practical distinction in `a-router` is:
+
+- **system startup** registers module routes into the shared router structure
+- **app startup** makes the operational router ready for the running application instance
+
+In source terms:
+
+- `monkeySys.ts` handles module route registration
+- `monkey.ts` handles app readiness and page-controller route-state injection
+
+This split matters because it explains why route-table wiring and first-screen navigation readiness are related but not identical responsibilities.
+
+## How layout enters the router runtime
+
+One of the most important source-confirmed details in `SysRouter._registerRoute(...)` is that layout is not only a visual afterthought.
+
+When layout is enabled:
+
+- `a-router` wraps the routed page in a parent route
+- the parent route uses the resolved layout component
+- the original page route becomes the child route
+
+That means layout choice becomes runtime route structure inside `a-router`, not only a later rendering preference.
+
+## How page controllers receive route-aware state
+
+A key Zova-specific behavior in `a-router` is that route-aware page state becomes part of the page-controller surface.
+
+In `monkey.ts`, page controllers receive:
+
+- `$route`
+- `$routeMatched`
+- `$params`
+- `$query`
+
+The important point is that this is not only a thin `useRoute()` translation.
+
+The route state is pushed through the controller lifecycle and, for `$params` and `$query`, parsed from the page-schema records that belong to the module resource.
+
+That is one reason the routing model stays tightly integrated with the rest of Zova’s controller-oriented architecture.
+
+## Where `a-router` stops and router-view hosts begin
+
+A useful boundary rule is:
+
+- `a-router` owns route registration, layout wrapping, startup readiness, guard flow, and page-controller route-state injection
+- router-view hosts own routed page instance hosting, `tabKey`, `componentKey`, `keepAlive`, and empty/tabs/stack host behavior
+
+So if your next question is:
+
+- “how does the route become operational?” stay in `a-router`
+- “which host owns the routed page instance now?” continue to [Router View Hosts Guide](/frontend/router-view-hosts-guide)
+- “should this host behave like tabs or stack?” continue with [Router Tabs vs Stack](/frontend/router-tabs-vs-stack)
+
+## Read together with
+
+Use this page together with:
+
+- [Page Route Guide](/frontend/page-route-guide)
+- [Zova Router Under the Hood](/frontend/zova-router-under-the-hood)
+- [Page Params Guide](/frontend/page-params-guide)
+- [Page Query Guide](/frontend/page-query-guide)
+- [Navigation Guards Guide](/frontend/navigation-guards-guide)
+- [Router View Hosts Guide](/frontend/router-view-hosts-guide)
+- [Zova Source Reading Map](/frontend/zova-source-reading-map)
+
+## Final takeaway
+
+The most accurate way to read `a-router` is not as a generic Vue Router wrapper and not as the owner of every routing-related concern.
+
+Read it as the Zova router runtime package that:
+
+- registers module routes
+- creates and normalizes operational router structure
+- makes the router ready during app startup
+- injects route-aware state into page controllers
+- hands routed output into router-view hosts
+
+That is the source-confirmed role of `a-router` in the current Basic frontend architecture.

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

@@ -10,10 +10,10 @@ That means frontend code does not need to scatter raw request details everywhere
 
 ## Create an API service
 
-Example: create an API service named `menu` in module `demo-student`.
+Example: create an API service named `menu` in module `training-student`.
 
 ```bash
-npm run zova :create:bean api menu -- --module=demo-student
+npm run zova :create:bean api menu -- --module=training-student
 ```
 
 ## API definition
@@ -39,6 +39,8 @@ This shows the intended layering clearly:
 - `$fetch` handles the lower-level request
 - the API service exposes a business-oriented method such as `retrieveMenus()`
 
+If the lower-level request path itself needs transport middleware such as headers, JWT handling, mock fallback, SSR short-circuiting, or response normalization, see [Fetch Interceptor Guide](/frontend/fetch-interceptor-guide).
+
 API is also one of the core module-scope resource categories; see [Module Scope](/frontend/module-scope).
 
 ## Using the API through module scope
@@ -61,9 +63,9 @@ Representative pattern:
 
 ```typescript
 @UseScope()
-$$scopeDemoStudent: ScopeModuleDemoStudent;
+$$scopeTrainingStudent: ScopeModuleTrainingStudent;
 
-const menus = await this.$$scopeDemoStudent.api.menu.retrieveMenus();
+const menus = await this.$$scopeTrainingStudent.api.menu.retrieveMenus();
 ```
 
 ## Built-in `$api` access

package/cabloy-docs/frontend/api-schema-guide.md

@@ -35,6 +35,7 @@ Use this page together with:
 - [OpenAPI SDK Guide](/frontend/openapi-sdk-guide)
 - [Backend OpenAPI to Frontend SDK](/fullstack/openapi-to-sdk)
 - [SDK Guide](/frontend/sdk-guide)
+- [A-OpenAPI Under the Hood](/frontend/a-openapi-under-the-hood)
 
 ## Implementation checks for schema-driven UI changes
 

package/cabloy-docs/frontend/app-startup-guide.md

@@ -68,7 +68,7 @@ A module can provide its own main lifecycle entrypoints.
 Representative creation command:
 
 ```bash
-npm run zova :init:main demo-student
+npm run zova :init:main training-student
 ```
 
 Representative pattern:
@@ -87,7 +87,7 @@ A module can also provide broader app hook behavior through a monkey entry.
 Representative creation command:
 
 ```bash
-npm run zova :init:monkey demo-student
+npm run zova :init:monkey training-student
 ```
 
 Representative pattern:
@@ -164,8 +164,11 @@ A practical reading sequence is:
 
 1. [System Startup Guide](/frontend/system-startup-guide)
 2. this page for router/guard readiness
-3. [Page Route Guide](/frontend/page-route-guide)
-4. [Navigation Guards Guide](/frontend/navigation-guards-guide)
+3. [Zova App Guide](/frontend/zova-app-guide)
+4. [Page Route Guide](/frontend/page-route-guide)
+5. [Navigation Guards Guide](/frontend/navigation-guards-guide)
+
+If you want the thin root app-host layer that sits inside the running frontend app, read [Zova App Guide](/frontend/zova-app-guide). That guide focuses on `a-app` as the root controller/behavior host rather than on startup hook timings.
 
 ## Relationship to environment/config selection
 

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

@@ -215,6 +215,8 @@ This is useful when one scene needs multiple scaffold shapes for distinct fronte
 
 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.
 
+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).
+
 ### `metadataCustom`
 
 Use this only when the scene needs additional generated output beyond the standard metadata passes.
@@ -288,7 +290,7 @@ Keep these two tasks separate.
 Example:
 
 ```bash
-npm run zova :create:bean model menu -- --module=demo-student
+npm run zova :create:bean model menu -- --module=training-student
 ```
 
 This uses an already-defined scene.