cabloy 5.1.61 → 5.1.62

package/cabloy-docs/frontend/model-resource-internals-deep-dive.md

@@ -0,0 +1,238 @@
+# ModelResource Internals Deep Dive
+
+This guide explains the internals of `ModelResource` in Zova through the current public Cabloy Basic source.
+
+Use this page when you want to understand:
+
+- how `ModelResource` bootstraps itself
+- how `resourceApi` is resolved
+- where permissions, schemas, and form-provider surfaces come from
+- how query, mutation, and form helpers are organized
+- how query-key prefixing and invalidation work
+- why `ModelResource` is the stable resource-owner boundary under both list and entry pages
+
+## Why this page exists
+
+This page is the third layer of a small source-reading chain around same-resource model facades:
+
+1. [Model Architecture](/frontend/model-architecture) for the broader role of Zova Model
+2. [Generated Contract Consumption: Entry Branch](/frontend/generated-contract-consumption-entry-branch) for the consumer-side handoff into the owner
+3. this page for the owner internals that make that handoff work
+
+Several existing docs already explain the meaning and usage of the resource owner well:
+
+- [Model Resource Owner Pattern](/frontend/model-resource-owner-pattern) explains the architecture and why the owner boundary exists
+- [Using `ModelResource` in Your Module](/frontend/model-resource-usage-guide) explains application-level usage patterns
+- [Resource Model Best Practices](/frontend/model-resource-best-practices) and [Resource Model Cookbook](/frontend/model-resource-cookbook) explain review and implementation guidance
+- [Rest Resource Under the Hood](/frontend/rest-resource-under-the-hood) explains the module/runtime bridge around the owner
+
+What those pages do not isolate directly is the one source-first path through `ModelResource` itself.
+
+That is the gap this page fills.
+
+## The shortest accurate mental model
+
+A practical mental model is:
+
+1. `ModelResource` is a selector-backed owner keyed by `resource`
+2. bootstrap resolves the final `resourceApi`
+3. the owner exposes computed surfaces for permissions, schema, and form provider
+4. query helpers wrap the shared model/query runtime for select/view/item-style fetches
+5. mutation helpers wrap the shared model/query runtime for create/update/delete behavior
+6. form helpers let pages choose schema/data/mutation behavior from `formMeta`
+7. query keys and invalidation are centralized as part of the owner contract
+
+That means `ModelResource` is not only a fetch helper. It is the stable resource semantics boundary for the frontend.
+
+## Source-confirmed reading path
+
+When reading this topic, use this order:
+
+1. `zova/src/suite-vendor/a-cabloy/modules/rest-resource/src/model/resource.ts`
+2. `zova/src/suite-vendor/a-zova/modules/a-openapi/src/model/sdk.ts`
+3. `zova/packages-zova/zova-core/src/core/sys/util.ts`
+4. `zova/src/suite-vendor/a-zova/modules/a-model/src/bean/bean.model/bean.model.useQuery.ts`
+5. `zova/src/suite-vendor/a-zova/modules/a-model/src/bean/bean.model/bean.model.query.ts`
+6. `zova/src/suite-vendor/a-zova/modules/a-model/src/bean/bean.model/bean.model.persister.ts`
+7. `zova/src/suite-vendor/a-cabloy/modules/rest-resource/src/page/resource/controller.tsx`
+8. `zova/src/suite-vendor/a-cabloy/modules/rest-resource/src/page/entry/controller.tsx`
+
+That order moves from the owner core, to the OpenAPI model it relies on, to path/config helpers, to query/persister behavior, and finally to the clearest current consumers.
+
+## Initialization and bootstrap
+
+The owner core lives in:
+
+```text
+zova/src/suite-vendor/a-cabloy/modules/rest-resource/src/model/resource.ts
+```
+
+The first source-confirmed facts are:
+
+- `@Model({ enableSelector: true })`
+- `__init__(resource)` requires a concrete `resource`
+- bootstrap happens before downstream consumers use the owner surfaces
+
+This matters because `ModelResource` is not one global singleton.
+
+It is a selector-backed owner whose runtime identity is the current resource name.
+
+## `resourceApi` resolution
+
+The bootstrap path uses:
+
+- `this.$sdk.getBootstrap(this.resource)`
+- `this.sys.util.parseResourceApi(resource, api)`
+
+The path/config helper lives in:
+
+```text
+zova/packages-zova/zova-core/src/core/sys/util.ts
+```
+
+This confirms the owner flow:
+
+- bootstrap data may override the final API path
+- otherwise the resource name is translated into a default controller/action API path
+
+That is why `resourceApi` should be treated as an owner-level resolved surface, not as one hard-coded string duplicated across pages.
+
+## Metadata surfaces exposed by the owner
+
+Inside `ModelResource`, the owner computes and exposes:
+
+- `permissions`
+- `formProvider`
+- `schemaView`
+- `schemaCreate`
+- `schemaUpdate`
+- `schemaFilter`
+- `schemaRow`
+- `schemaPages`
+
+These surfaces are derived from:
+
+- the bootstrap/runtime resource context
+- the OpenAPI SDK/schema helpers
+
+This is the clearest source-confirmed reason why both list pages and entry pages reuse the same owner: schema, permission, and provider surfaces belong to one resource boundary.
+
+## Query helper layer
+
+The query helpers are organized around:
+
+- `selectGeneral(actionPath?, query?)`
+- `select(query?)`
+- `queryItem(...)`
+- `view(id)`
+
+`select(query?)` is only a thin wrapper over `selectGeneral(undefined, query)`.
+
+The important source-confirmed detail is that the select key includes a hash of the query object:
+
+- `['select', actionPath ?? '', hashkey(query)]`
+
+That means query identity is deliberate and owner-controlled.
+
+This is the owner-side boundary for list/query fetches, not the page shell.
+
+## Mutation helper layer
+
+The mutation helpers are organized around:
+
+- `create()`
+- `mutationItem(...)`
+- `update(id)`
+- `delete(id)`
+
+The most important source-confirmed behavior is:
+
+- select queries are invalidated after successful mutations
+- item-root queries are invalidated for the specific row identity
+
+That means mutation helpers do not only perform network requests. They also own the default resource-level invalidation policy.
+
+## Form helper layer
+
+The form-facing helpers are:
+
+- `getFormSchema(formMeta)`
+- `getFormApiSchemas(formMeta)`
+- `getFormMutationSubmit(formMeta, id?)`
+- `getFormData(formMeta, id?)`
+- `getQueryDataDefaultValue(schemaName?)`
+
+This is the clearest source-confirmed bridge from resource owner to entry-page form runtime.
+
+A practical reading rule is:
+
+- list pages mainly consume `schemaFilter`, `schemaRow`, and `select(...)`
+- entry pages mainly consume `formMeta`-driven form helpers
+
+## Query-key prefixing and invalidation behavior
+
+The shared model/query behavior lives in:
+
+```text
+zova/src/suite-vendor/a-zova/modules/a-model/src/bean/bean.model/bean.model.useQuery.ts
+zova/src/suite-vendor/a-zova/modules/a-model/src/bean/bean.model/bean.model.query.ts
+zova/src/suite-vendor/a-zova/modules/a-model/src/bean/bean.model/bean.model.persister.ts
+```
+
+The important source-confirmed behavior is:
+
+- owner query keys are prefixed with bean full name
+- selector-backed models also prefix by selector
+- persister/query behavior therefore treats one resource owner as a distinct query namespace
+
+This is why `ModelResource` query identity is stable even when multiple resources or multiple selectors exist at once.
+
+## Current consumers that prove the contract
+
+The clearest current consumers are:
+
+- `rest-resource/src/page/resource/controller.tsx`
+- `rest-resource/src/page/entry/controller.tsx`
+
+These page shells prove that:
+
+- list pages consume the owner for top-level list/schema/runtime entry
+- entry pages consume the owner for form/provider/schema/runtime entry
+
+That is enough to verify that `ModelResource` is the shared owner beneath both branches.
+
+## What this guide does not re-explain
+
+This page does **not** fully re-explain:
+
+- why the resource owner pattern exists -> see [Model Resource Owner Pattern](/frontend/model-resource-owner-pattern)
+- application-level facade and usage guidance -> see [Using `ModelResource` in Your Module](/frontend/model-resource-usage-guide)
+- the full list-page runtime -> see [Resource List Page Deep Dive](/frontend/resource-list-page-deep-dive)
+- the full entry-page runtime -> see [Resource Entry Page Deep Dive](/frontend/resource-entry-page-deep-dive)
+
+Its job is only to explain the owner internals and their current consumer contract.
+
+## Where to read next
+
+Use these next steps depending on your question:
+
+- if you want to step back to the broader model role, return to [Model Architecture](/frontend/model-architecture)
+- if you want to step back to the consumer-side handoff, return to [Generated Contract Consumption: Entry Branch](/frontend/generated-contract-consumption-entry-branch)
+- if you want the list-page runtime branch, read [Resource List Page Deep Dive](/frontend/resource-list-page-deep-dive)
+- if you want the entry-page runtime branch, read [Resource Entry Page Deep Dive](/frontend/resource-entry-page-deep-dive)
+- if you want the owner-pattern explanation, read [Model Resource Owner Pattern](/frontend/model-resource-owner-pattern)
+- if you want application-level usage/facade rules, read [Using `ModelResource` in Your Module](/frontend/model-resource-usage-guide)
+
+## Final takeaway
+
+The most accurate way to read `ModelResource` is not as one generic CRUD helper.
+
+Read it as the selector-backed resource owner that:
+
+- bootstraps and resolves `resourceApi`
+- exposes schema, permission, and provider surfaces
+- owns query, mutation, and form helper boundaries
+- defines query-key and invalidation behavior
+- remains the stable resource semantics layer beneath both list pages and entry pages
+
+That is the source-confirmed role of `ModelResource` in the current Cabloy Basic frontend architecture.

package/cabloy-docs/frontend/model-resource-owner-pattern.md

@@ -8,12 +8,33 @@ It uses the current `rest-resource` model as the main source specimen:
 
 Read [Model Architecture](/frontend/model-architecture) and [Model State Guide](/frontend/model-state-guide) first if you want the broader Model runtime and helper surface.
 
+If your next question is how `ModelResource` itself works internally at the source level, continue with [ModelResource Internals Deep Dive](/frontend/model-resource-internals-deep-dive).
+
+If your next question is how the generic lower-level model runtime works beneath `ModelResource`, continue with [Model Runtime Under the Hood](/frontend/a-model-under-the-hood).
+
+If your next question is how the whole `rest-resource` module works at runtime beyond the model itself, continue with [Rest Resource Under the Hood](/frontend/rest-resource-under-the-hood).
+
+If your next question is which files to read next for that runtime, continue with [Rest Resource Source Reading Map](/frontend/rest-resource-source-reading-map).
+
 If your next question is how to apply this pattern in your own module, continue with [Using `ModelResource` in Your Module](/frontend/model-resource-usage-guide).
 
 If your next question is how to review or constrain that pattern in a larger codebase, continue with [Resource Model Best Practices and Anti-Patterns](/frontend/model-resource-best-practices).
 
 If your next question is which common extension shapes to implement first, continue with [Resource Model Cookbook](/frontend/model-resource-cookbook).
 
+> [!TIP]
+> **Resource docs path**
+>
+> 1. **[Model Resource Owner Pattern](/frontend/model-resource-owner-pattern)** — learn why `ModelResource` is a resource owner
+> 2. **[Rest Resource Under the Hood](/frontend/rest-resource-under-the-hood)** — learn how the module runtime pieces cooperate
+> 3. **[Rest Resource Source Reading Map](/frontend/rest-resource-source-reading-map)** — learn which files to read next
+> 4. **[Using `ModelResource` in Your Module](/frontend/model-resource-usage-guide)** — learn how to reuse the owner in application code
+> 5. **[Resource Model Best Practices](/frontend/model-resource-best-practices)** — learn the review guardrails
+> 6. **[Resource Model Cookbook](/frontend/model-resource-cookbook)** — learn the common implementation shapes
+>
+> **You are here:** step 1.
+> **Next recommended page:** [Rest Resource Under the Hood](/frontend/rest-resource-under-the-hood).
+
 ## Why this page exists
 
 Many examples of Zova Model start from a small feature model:
@@ -118,8 +139,7 @@ Because Zova Model prefixes query keys by bean identity and selector, the effect
 So logical keys such as:
 
 ```typescript
-['select', '', hashkey(query)]
-['item', id, 'view']
+['select', '', hashkey(query)][('item', id, 'view')];
 ```
 
 can safely exist for many resources without colliding.

package/cabloy-docs/frontend/model-resource-usage-guide.md

@@ -6,8 +6,24 @@ It is the practical follow-up to [Model Resource Owner Pattern](/frontend/model-
 
 For review guardrails and design checks after applying the pattern, continue with [Resource Model Best Practices and Anti-Patterns](/frontend/model-resource-best-practices).
 
+If you need the lower-level generic model runtime beneath this resource-owner usage layer, continue with [Model Runtime Under the Hood](/frontend/a-model-under-the-hood).
+
 For implementation templates covering common extension scenarios, continue with [Resource Model Cookbook](/frontend/model-resource-cookbook).
 
+> [!TIP]
+> **Resource docs path**
+>
+> 1. **[Model Resource Owner Pattern](/frontend/model-resource-owner-pattern)** — learn why `ModelResource` is a resource owner
+> 2. **[Rest Resource Under the Hood](/frontend/rest-resource-under-the-hood)** — learn how the module runtime pieces cooperate
+> 3. **[Rest Resource Source Reading Map](/frontend/rest-resource-source-reading-map)** — learn which files to read next
+> 4. **[Using `ModelResource` in Your Module](/frontend/model-resource-usage-guide)** — learn how to reuse the owner in application code
+> 5. **[Resource Model Best Practices](/frontend/model-resource-best-practices)** — learn the review guardrails
+> 6. **[Resource Model Cookbook](/frontend/model-resource-cookbook)** — learn the common implementation shapes
+>
+> **You are here:** step 4.
+> **Previous recommended pages:** [Model Resource Owner Pattern](/frontend/model-resource-owner-pattern), [Rest Resource Under the Hood](/frontend/rest-resource-under-the-hood), and [Rest Resource Source Reading Map](/frontend/rest-resource-source-reading-map).
+> **Next recommended pages:** [Resource Model Best Practices](/frontend/model-resource-best-practices), then [Resource Model Cookbook](/frontend/model-resource-cookbook).
+
 Use this page when the main question is not only “what does `ModelResource` do?”, but also:
 
 - when should I use it directly?
@@ -95,7 +111,7 @@ This is the right option when business semantics appear, but ownership should st
 A representative shape is:
 
 ```typescript
-const StudentResource = 'demo-student:student';
+const StudentResource = 'training-student:student';
 
 @Model()
 export class ModelStudent extends BeanModelBase {
@@ -109,7 +125,7 @@ export class ModelStudent extends BeanModelBase {
       id,
       action: 'summary',
       queryFn: async () => {
-        const res = await this.scope.api.demoStudent.summary({ params: { id } });
+        const res = await this.scope.api.trainingStudent.summary({ params: { id } });
         return res ?? null;
       },
       meta: {
@@ -123,7 +139,7 @@ export class ModelStudent extends BeanModelBase {
       id,
       action: 'deleteForce',
       mutationFn: async () => {
-        await this.scope.api.demoStudent.deleteForce({ params: { id } });
+        await this.scope.api.trainingStudent.deleteForce({ params: { id } });
       },
     });
   }
@@ -184,7 +200,7 @@ summary(id: TableIdentity) {
     id,
     action: 'summary',
     queryFn: async () => {
-      const res = await this.scope.api.demoStudent.summary({ params: { id } });
+      const res = await this.scope.api.trainingStudent.summary({ params: { id } });
       return res ?? null;
     },
   });
@@ -227,7 +243,7 @@ deleteForce(id: TableIdentity) {
     id,
     action: 'deleteForce',
     mutationFn: async () => {
-      await this.scope.api.demoStudent.deleteForce({ params: { id } });
+      await this.scope.api.trainingStudent.deleteForce({ params: { id } });
     },
   });
 }
@@ -315,4 +331,4 @@ The most important practical insight is simple:
 
 > use `ModelResource` directly when the generic owner already fits; add a thin facade only when the UI needs clearer business semantics.
 
-That approach keeps the programming model more uniform and reduces mental burden.
+That approach keeps the programming model more uniform and reduces mental burden.

package/cabloy-docs/frontend/model-state-guide.md

@@ -6,6 +6,10 @@ Read [Model Architecture](/frontend/model-architecture) first if you want the br
 
 If you specifically want the scalable resource-facade pattern, continue with [Model Resource Owner Pattern](/frontend/model-resource-owner-pattern).
 
+If you want the generic lower-level model runtime beneath these helper families, continue with [A-Model Under the Hood](/frontend/a-model-under-the-hood).
+
+If you want to understand how that owner pattern expands into the whole `rest-resource` module runtime, continue with [Rest Resource Under the Hood](/frontend/rest-resource-under-the-hood), then [Rest Resource Source Reading Map](/frontend/rest-resource-source-reading-map).
+
 If you want to apply that pattern in your own module with a more uniform two-usage model, continue with [Using `ModelResource` in Your Module](/frontend/model-resource-usage-guide).
 
 ## Why the model-state layer exists
@@ -26,10 +30,10 @@ Current `a-model` source supports a broader state family that includes:
 
 ## Create a model
 
-Example: create a model named `menu` in module `demo-student`.
+Example: create a model named `menu` in module `training-student`.
 
 ```bash
-npm run zova :create:bean model menu -- --module=demo-student
+npm run zova :create:bean model menu -- --module=training-student
 ```
 
 ## Basic model definition
@@ -206,7 +210,7 @@ One of the most important model-state behaviors is automatic key prefixing.
 When a model uses:
 
 ```typescript
-queryKey: ['list']
+queryKey: ['list'];
 ```
 
 that logical key is prefixed internally with model identity, and with selector when selector mode is enabled.
@@ -306,6 +310,8 @@ What this example shows:
 
 This is one of the best examples for understanding how Zova Model scales from simple data queries to reusable domain infrastructure.
 
+If your next question is not only about the model class but about how generic routes, page shells, schema-driven blocks, and downstream CRUD blocks cooperate around that owner, continue with [Rest Resource Under the Hood](/frontend/rest-resource-under-the-hood).
+
 #### Why `enableSelector` matters here
 
 This model is not meant to represent only one concrete resource forever.
@@ -321,8 +327,7 @@ At runtime, model query keys are therefore prefixed not only by the bean full na
 That means two consumers can both use logical keys such as:
 
 ```typescript
-['select', '', hashkey(query)]
-['item', id, 'view']
+['select', '', hashkey(query)][('item', id, 'view')];
 ```
 
 without colliding with each other, because the effective cache identity is separated by resource selector.
@@ -363,9 +368,7 @@ It separates three levels of identity:
 Representative shapes are:
 
 ```typescript
-['select', actionPath ?? '', hashkey(query)]
-['item', id]
-['item', id, action]
+['select', actionPath ?? '', hashkey(query)][('item', id)][('item', id, action)];
 ```
 
 This makes the invalidation strategy much clearer:
@@ -420,4 +423,4 @@ The most important usage insight is simple:
 
 > In Zova, model state is not only “fetch some data”. It is a unified model-owned runtime for query state, local state, persistence, invalidation, and SSR-aware reuse.
 
-Once that is clear, the helper family in `a-model` reads as one coherent system instead of several unrelated APIs.
+Once that is clear, the helper family in `a-model` reads as one coherent system instead of several unrelated APIs.

package/cabloy-docs/frontend/module-scope.md

@@ -40,11 +40,11 @@ These categories make module resources discoverable and consistently organized.
 Representative CLI entrypoints include:
 
 ```bash
-npm run zova :init:config demo-student
-npm run zova :init:constant demo-student
-npm run zova :init:locale demo-student
-npm run zova :init:error demo-student
-npm run zova :create:bean api test -- --module=demo-student
+npm run zova :init:config training-student
+npm run zova :init:constant training-student
+npm run zova :init:locale training-student
+npm run zova :init:error training-student
+npm run zova :create:bean api test -- --module=training-student
 ```
 
 This matters because scope is not just a read surface. It is the organized destination for resources generated or initialized through the standard Zova workflow.
@@ -119,14 +119,14 @@ Representative pattern:
 
 ```typescript
 @UseScope()
-$$scopeDemoStudent: ScopeModuleDemoStudent;
+$$scopeTrainingStudent: ScopeModuleTrainingStudent;
 ```
 
 A common follow-up access pattern is:
 
 ```typescript
-const res = await this.$$scopeDemoStudent.api.test.echo();
-console.log(this.$$scopeDemoStudent.locale.HelloWorld());
+const res = await this.$$scopeTrainingStudent.api.test.echo();
+console.log(this.$$scopeTrainingStudent.locale.HelloWorld());
 ```
 
 This allows one module to consume another module’s scoped resources explicitly without flattening everything into one shared global namespace.

package/cabloy-docs/frontend/modules-and-suites.md

@@ -129,7 +129,7 @@ Representative patterns include:
 
 ```json
 {
-  "name": "zova-module-demo-student",
+  "name": "zova-module-training-student",
   "zovaModule": {
     "dependencies": {
       "a-zova": "5.0.0"
@@ -160,6 +160,7 @@ This reinforces that modules are not merely folders. They are explicit package,
 
 Read this together with:
 
+- [Suites and Modules](/fullstack/suites-and-modules) for the cross-stack suite-first decision path in the monorepo
 - [IoC and Beans](/frontend/ioc-and-beans)
 - [Module Scope](/frontend/module-scope)
 - [Frontend Scripts](/frontend/scripts)

package/cabloy-docs/frontend/navigation-guards-guide.md

@@ -66,3 +66,10 @@ When changing auth-sensitive routing behavior, ask:
 4. should redirects happen at the routing-policy layer rather than being hardcoded into page logic?
 
 That produces cleaner and more framework-native navigation behavior.
+
+## Where to read next
+
+- If you want the broader route-record surface first, continue with [Page Route Guide](/frontend/page-route-guide).
+- If the guard decision depends on route metadata or task-level shell state, continue with [Page Meta Guide](/frontend/page-meta-guide).
+- If the guard behavior is really part of a larger SSR decision path, continue with [SSR Architecture Overview](/frontend/ssr-architecture-overview).
+- If you want the deeper routing runtime after the public policy surface is clear, descend into [Zova Router Under the Hood](/frontend/zova-router-under-the-hood).

package/cabloy-docs/frontend/openapi-sdk-guide.md

@@ -20,12 +20,16 @@ For the bridge view, also see [Backend OpenAPI to Frontend SDK](/fullstack/opena
 
 For the broader frontend contract-consumption ladder, also see [Server Data](/frontend/server-data), [API Schema Guide](/frontend/api-schema-guide), and [SDK Guide](/frontend/sdk-guide).
 
+If your next question is how the lower-level OpenAPI/schema runtime works under `$sdk`, continue with [A-OpenAPI Under the Hood](/frontend/a-openapi-under-the-hood).
+
+If your next question is how generated contract material becomes schema-driven frontend behavior or resource-owner consumption, continue with [API Schema Guide](/frontend/api-schema-guide) and [ModelResource Internals Deep Dive](/frontend/model-resource-internals-deep-dive).
+
 ## Initialize OpenAPI config
 
-Example: initialize OpenAPI config for module `demo-student`.
+Example: initialize OpenAPI config for module `training-student`.
 
 ```bash
-npm run zova :openapi:config demo-student
+npm run zova :openapi:config training-student
 ```
 
 ## Module-level config
@@ -53,10 +57,10 @@ Representative use case:
 
 ## Generate the SDK
 
-Example: generate OpenAPI-based frontend services for module `demo-student`.
+Example: generate OpenAPI-based frontend services for module `training-student`.
 
 ```bash
-npm run zova :openapi:generate demo-student
+npm run zova :openapi:generate training-student
 ```
 
 ## Build the rest-contract output
@@ -93,6 +97,10 @@ If the backend contract itself changes, first inspect or update the backend cont
 
 Then return to this page for the frontend regeneration step.
 
+If your next question is what that generated contract looks like when it is actually consumed in a practical frontend path, continue with [Generated Contract Consumption Specimen](/frontend/generated-contract-consumption-specimen).
+
+If you then want a proof-oriented or symptom-first companion for the consumer-side path, continue with [Generated Contract Consumption Verify Playbook](/frontend/generated-contract-consumption-verify-playbook) and [Generated Contract Consumption Debug Checklist](/frontend/generated-contract-consumption-debug-checklist).
+
 ## Implementation checks for SDK regeneration decisions
 
 When evaluating a request that depends on backend contracts, ask:

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

@@ -17,10 +17,10 @@ That combination is one of the clearest examples of Zova’s overall design phil
 
 ## Create a page
 
-Example: create a page named `counter` in module `demo-student`.
+Example: create a page named `counter` in module `training-student`.
 
 ```bash
-npm run zova :create:page counter -- --module=demo-student
+npm run zova :create:page counter -- --module=training-student
 ```
 
 ## Route path generation
@@ -29,9 +29,9 @@ Zova automatically derives the page path from the module and page names.
 
 Representative example:
 
-- module: `demo-student`
+- module: `training-student`
 - page: `counter`
-- generated page path: `/demo/student/counter`
+- generated page path: `/training/student/counter`
 
 This matters because the framework already has conventions for route structure. AI should reuse those conventions rather than inventing unrelated paths.
 
@@ -123,7 +123,7 @@ A typical first step is keeping the page controller responsible for state while
 #### Create the first render bean
 
 ```bash
-npm run zova :refactor:firstRender page/counter -- --module=demo-student
+npm run zova :refactor:firstRender page/counter -- --module=training-student
 ```
 
 Representative render bean shape:
@@ -146,7 +146,7 @@ class RenderPageCounter extends BeanRenderBase {
 #### Create the first style bean
 
 ```bash
-npm run zova :refactor:firstStyle page/counter -- --module=demo-student
+npm run zova :refactor:firstStyle page/counter -- --module=training-student
 ```
 
 Representative style bean shape:
@@ -177,19 +177,19 @@ Representative refactors include:
 #### Create another render bean
 
 ```bash
-npm run zova :refactor:anotherRender page/counter another -- --module=demo-student
+npm run zova :refactor:anotherRender page/counter another -- --module=training-student
 ```
 
 #### Create another style bean
 
 ```bash
-npm run zova :refactor:anotherStyle page/counter another -- --module=demo-student
+npm run zova :refactor:anotherStyle page/counter another -- --module=training-student
 ```
 
 #### Create a service bean for state management
 
 ```bash
-npm run zova :create:bean service page/counter/counter -- --module=demo-student
+npm run zova :create:bean service page/counter/counter -- --module=training-student
 ```
 
 Representative service bean shape: