cabloy 5.1.61 → 5.1.62

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
@@ -63,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

@@ -290,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.

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

@@ -25,7 +25,7 @@ The public decorator is:
 At the source level, the decorator is implemented as:
 
 ```typescript
-createBeanDecorator('behavior', 'new', true, options)
+createBeanDecorator('behavior', 'new', true, options);
 ```
 
 That matters because Behavior is authored as a **fresh-instance bean scene** with decorator options, while the runtime may reuse existing behavior instances across reloads when appropriate.
@@ -41,6 +41,9 @@ Typical use cases include:
 - prop transformation before the final render
 - UI wrappers that should stay composable instead of being copied into many components
 - module-level behavior selection through provider config
+- app-wide wrappers that should participate around the routed tree through the root app host
+
+For the root hosting point used by app-wide behavior composition, see [Zova App Guide](/frontend/zova-app-guide). For the end-to-end app-scope composition path around the routed tree, continue with [Root Behaviors Guide](/frontend/root-behaviors-guide).
 
 Do **not** reach for Behavior first when a plain helper or a normal component is enough.
 
@@ -54,11 +57,11 @@ A practical rule is:
 
 Use these three tools for different kinds of reuse.
 
-| Tool | Best fit | Typical responsibility |
-| --- | --- | --- |
-| Behavior | render-time interception or wrapping | adjust props, intercept refs, wrap a vnode, compose multiple render concerns |
-| Component | standalone UI unit | own a reusable UI contract and render structure directly |
-| Helper | framework-neutral utility | transform data, normalize values, or share logic that does not need bean lifecycle or render composition |
+| Tool      | Best fit                             | Typical responsibility                                                                                   |
+| --------- | ------------------------------------ | -------------------------------------------------------------------------------------------------------- |
+| Behavior  | render-time interception or wrapping | adjust props, intercept refs, wrap a vnode, compose multiple render concerns                             |
+| Component | standalone UI unit                   | own a reusable UI contract and render structure directly                                                 |
+| Helper    | framework-neutral utility            | transform data, normalize values, or share logic that does not need bean lifecycle or render composition |
 
 A practical decision map is:
 
@@ -115,12 +118,12 @@ Use `@Behavior()` to declare a behavior bean.
 Representative shape:
 
 ```typescript
-import { BeanBehaviorBase, Behavior } from 'zova-module-a-behavior'
+import { BeanBehaviorBase, Behavior } from 'zova-module-a-behavior';
 
 @Behavior()
 export class BehaviorFocus extends BeanBehaviorBase {
   protected render(props, next) {
-    return next(props)
+    return next(props);
   }
 }
 ```
@@ -152,7 +155,7 @@ This is one of the main reasons Behavior fits naturally into the Zova bean archi
 Representative shape:
 
 ```typescript
-$UseBehavior('a-behaviors:focus', { always: true })
+$UseBehavior('a-behaviors:focus', { always: true });
 ```
 
 The helper returns one behavior declaration item in object form. Broader normalization into onion items happens later in the runtime composer path.
@@ -164,7 +167,7 @@ The helper returns one behavior declaration item in object form. Broader normali
 Representative shape:
 
 ```typescript
-$UseBehaviorTag('input')
+$UseBehaviorTag('input');
 ```
 
 ### `ZBehavior`
@@ -194,7 +197,7 @@ At the type level, `IBehaviors` accepts these shapes:
 Representative forms:
 
 ```typescript
-'a-behaviors:focus'
+'a-behaviors:focus';
 ```
 
 ```typescript
@@ -202,10 +205,7 @@ Representative forms:
 ```
 
 ```typescript
-[
-  'a-behaviors:focus',
-  { 'home-login:formFieldLayoutLogin': {} },
-]
+['a-behaviors:focus', { 'home-login:formFieldLayoutLogin': {} }];
 ```
 
 At runtime, the composer normalizes these forms into onion items before the render chain is built.
@@ -370,7 +370,7 @@ Behavior metadata generation also exposes shorthand HTML/JSX attributes.
 For example, a behavior such as `a-behaviors:focus` generates an attribute like:
 
 ```tsx
-bs-behaviors-focus
+bs - behaviors - focus;
 ```
 
 The generation rule is defined by the behavior metadata generator and is based on the module name and bean name.

package/cabloy-docs/frontend/cli.md

@@ -10,10 +10,10 @@ For AI-assisted development, the CLI should be the default starting point whenev
 
 ## Example
 
-Create a `component` named `test` in module `demo-student`:
+Create a `component` named `test` in module `training-student`:
 
 ```bash
-npm run zova :create:component test -- --module=demo-student
+npm run zova :create:component test -- --module=training-student
 ```
 
 ## Command discovery pattern
@@ -84,9 +84,9 @@ A practical rule is:
 The built-in `command` scene is the clearest current example:
 
 ```bash
-npm run zova :create:bean command test -- --module=demo-student
-npm run zova :create:bean command test -- --module=demo-student --boilerplate=commandBulk
-npm run zova :create:bean command test -- --module=demo-student --boilerplate=commandRow
+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
 ```
 
 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`.

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

@@ -114,7 +114,12 @@ The default command boilerplate currently generates this shape:
 import type { IJsxRenderContextBase } from 'zova-module-a-openapi';
 
 import { BeanBase } from 'zova';
-import { Command, type ICommandExecute, type ICommandOptionsBase, type NextCommandExecute } from 'zova-module-a-command';
+import {
+  Command,
+  type ICommandExecute,
+  type ICommandOptionsBase,
+  type NextCommandExecute,
+} from 'zova-module-a-command';
 
 export type TypeCommandExampleResult = unknown;
 
@@ -122,7 +127,11 @@ export interface ICommandOptionsExample extends ICommandOptionsBase<TypeCommandE
 
 @Command<ICommandOptionsExample>()
 export class CommandExample extends BeanBase implements ICommandExecute {
-  execute(_options: ICommandOptionsExample, _renderContext: IJsxRenderContextBase, next: NextCommandExecute) {
+  execute(
+    _options: ICommandOptionsExample,
+    _renderContext: IJsxRenderContextBase,
+    next: NextCommandExecute,
+  ) {
     return next();
   }
 }
@@ -165,7 +174,7 @@ A representative call shape looks like this:
 
 ```typescript
 await this.$performCommand('basic-commands:create', {
-  resource: 'demo-student:student',
+  resource: 'training-student:student',
   replace: false,
 });
 ```
@@ -174,7 +183,7 @@ A row-oriented example looks like this:
 
 ```typescript
 await this.$performCommand('basic-commands:delete', {
-  resource: 'demo-student:student',
+  resource: 'training-student:student',
   id: row.id,
 });
 ```
@@ -345,7 +354,7 @@ npm run zova :create:bean sceneName beanName -- [--module=] [--boilerplate=]
 Use the default template when the command bean does not need `BeanCommandBulkBase` or `BeanCommandRowBase`:
 
 ```bash
-npm run zova :create:bean command test -- --module=demo-student
+npm run zova :create:bean command test -- --module=training-student
 ```
 
 ### `commandBulk` boilerplate
@@ -353,7 +362,7 @@ npm run zova :create:bean command test -- --module=demo-student
 Use the bulk variant when the command should resolve `resource` through `BeanCommandBulkBase`:
 
 ```bash
-npm run zova :create:bean command test -- --module=demo-student --boilerplate=commandBulk
+npm run zova :create:bean command test -- --module=training-student --boilerplate=commandBulk
 ```
 
 ### `commandRow` boilerplate
@@ -361,7 +370,7 @@ npm run zova :create:bean command test -- --module=demo-student --boilerplate=co
 Use the row variant when the command should resolve `resource` and `id` through `BeanCommandRowBase`:
 
 ```bash
-npm run zova :create:bean command test -- --module=demo-student --boilerplate=commandRow
+npm run zova :create:bean command test -- --module=training-student --boilerplate=commandRow
 ```
 
 For the cross-scene lookup table, also see [Bean Scene Boilerplate Variants](/reference/bean-scene-boilerplates).
@@ -492,4 +501,4 @@ When documenting or reviewing command-scene behavior, verify in this order:
 
    ```bash
    npm run docs:build
-   ```
+   ```

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

@@ -18,10 +18,10 @@ For the practical styling decision map around local `$style`, dedicated style be
 
 ## Create a component
 
-Example: create a component named `card` in module `demo-student`.
+Example: create a component named `card` in module `training-student`.
 
 ```bash
-npm run zova :create:component card -- --module=demo-student
+npm run zova :create:component card -- --module=training-student
 ```
 
 ## Controller definition
@@ -53,7 +53,7 @@ The `Z` prefix is useful because it makes framework components easy to identify
 Representative usage pattern:
 
 ```typescript
-import { ZCard } from 'zova-module-demo-student';
+import { ZCard } from 'zova-module-training-student';
 
 class RenderPageCounter {
   render() {
@@ -75,8 +75,8 @@ Instead of relying on template refs in the usual Vue style, Zova prefers direct
 Representative pattern:
 
 ```typescript
-import type { ControllerCard } from 'zova-module-demo-student';
-import { ZCard } from 'zova-module-demo-student';
+import type { ControllerCard } from 'zova-module-training-student';
+import { ZCard } from 'zova-module-training-student';
 
 class RenderPageCounter {
   cardRef: ControllerCard;

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

@@ -13,7 +13,7 @@ Zova uses a more unified approach centered on component props, which makes the p
 Example: add props support to component `card`.
 
 ```bash
-npm run zova :refactor:componentProps card -- --module=demo-student
+npm run zova :refactor:componentProps card -- --module=training-student
 ```
 
 ## Define props

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

@@ -13,7 +13,7 @@ That is important because the framework treats model binding as part of the cont
 Example: add `modelValue` to component `card`.
 
 ```bash
-npm run zova :refactor:componentModel card modelValue -- --module=demo-student
+npm run zova :refactor:componentModel card modelValue -- --module=training-student
 ```
 
 ## Representative generated shape
@@ -83,7 +83,7 @@ class ControllerOther {
 Representative generation command:
 
 ```bash
-npm run zova :refactor:componentModel card title -- --module=demo-student
+npm run zova :refactor:componentModel card title -- --module=training-student
 ```
 
 Representative usage pattern: