cabloy 5.1.60 → 5.1.61

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

@@ -1,11 +1,13 @@
 # Frontend Metadata Back to Backend
 
-This page documents the reverse direction of Cabloy’s fullstack collaboration loop: frontend-generated metadata that improves backend-side development and tooling.
+This page is the **reverse chain** deep dive for Cabloy’s bidirectional contract loop: frontend-generated metadata that improves backend-side development and tooling.
 
 ## Why this path matters
 
 The fullstack collaboration loop in Cabloy is not one-way.
 
+In the bidirectional [Contract Loop Playbook](/fullstack/contract-loop-playbook), this page covers the **reverse chain**.
+
 For the forward contract-bridge direction from backend OpenAPI to frontend consumption, also see [Backend OpenAPI to Frontend SDK](/fullstack/openapi-to-sdk).
 
 The backend does not only feed the frontend through OpenAPI. The frontend also generates information that can improve backend-side type hints and integration confidence.
@@ -44,6 +46,8 @@ A practical collaboration loop often looks like this:
 
 ## Edition awareness
 
+The reverse-chain mental model applies to both Cabloy Basic and Cabloy Start.
+
 This path is especially sensitive to edition differences because Basic and Start do not expose the same frontend module and UI shape.
 
 So when AI reasons about frontend-generated metadata, it should verify:
@@ -51,6 +55,7 @@ So when AI reasons about frontend-generated metadata, it should verify:
 - which repo is active
 - which flavor is active
 - which generated output belongs to that edition
+- which concrete build and sync commands belong to that edition
 
 ## Implementation checks for frontend-metadata changes
 
@@ -62,3 +67,41 @@ When changing frontend structural resources such as routes or components, ask:
 4. should the next action be generation and verification rather than only source edits?
 
 That keeps the reverse contract loop visible instead of accidental.
+
+## When backend consumes newly added frontend resources
+
+This reverse handoff matters most when you create or change frontend resources that backend-side workflows will later consume, such as:
+
+- custom form-field renderers
+- custom table-cell renderers
+- other generated frontend metadata that backend `ZovaRender.*(...)` references depend on
+
+In that case, do not stop after source edits alone. Use this representative sequence:
+
+1. regenerate frontend metadata when applicable
+2. build the relevant frontend flavor output so the shared REST/type surface is refreshed
+3. run `npm run deps:vona` so Vona re-syncs its local file dependencies
+4. if generated `.zova-rest` output already contains the expected new keys or types but backend-side consumers still look stale, rebuild `vona/node_modules` and reinstall dependencies
+
+For the current Cabloy Basic admin flow, the representative commands are:
+
+```bash
+npm run zova :tools:metadata <module-name>
+npm run build:zova:admin
+npm run deps:vona
+```
+
+If the same resource path must also be available for Web, add:
+
+```bash
+npm run build:zova:web
+npm run deps:vona
+```
+
+If Vona still cannot see the refreshed shared types after the normal sync flow, use this recovery path:
+
+```bash
+cd vona && rm -rf node_modules && pnpm install
+```
+
+The key rule is simple: if frontend-generated resources are later consumed by backend tooling or backend metadata, treat the work as a reverse fullstack handoff, not as frontend-only cleanup.

package/cabloy-docs/fullstack/introduction.md

@@ -89,7 +89,18 @@ Cabloy does not treat type sharing as backend-to-frontend only. The collaboratio
 
 This two-way contract loop reduces duplicate declarations and lets backend and frontend evolve from generated source truth instead of hand-maintained memory.
 
-For the two directions in more detail, see [Backend OpenAPI to Frontend SDK](/fullstack/openapi-to-sdk) and [Frontend Metadata Back to Backend](/fullstack/frontend-metadata-to-backend).
+Start with the canonical [Contract Loop Playbook](/fullstack/contract-loop-playbook), then use the directional deep dives [Backend OpenAPI to Frontend SDK](/fullstack/openapi-to-sdk) and [Frontend Metadata Back to Backend](/fullstack/frontend-metadata-to-backend).
+
+Use the playbook to distinguish four cases clearly:
+
+- forward chain
+- reverse chain
+- consumer drift
+- local dependency drift
+
+The contract-loop model is shared across Cabloy Basic and Cabloy Start. Detect the edition to choose concrete flavor commands and generated-output paths, not to redefine the workflow model.
+
+When the reverse direction involves newly added frontend resources that backend tooling or backend metadata will consume, treat that as an operational handoff rather than a conceptual one: refresh generated frontend output, run the relevant flavor build, run `npm run deps:vona`, and if Vona still sees stale shared types, rebuild `vona/node_modules` and reinstall dependencies.
 
 ## How the fullstack system stays connected
 

package/cabloy-docs/fullstack/openapi-to-sdk.md

@@ -1,10 +1,10 @@
 # Backend OpenAPI to Frontend SDK
 
-This page turns one of Cabloy’s most important fullstack collaboration paths into an explicit guide.
+This page is the **forward chain** deep dive for Cabloy’s bidirectional contract loop.
 
 ## Why this path matters
 
-Cabloy’s fullstack productivity depends heavily on a contract loop:
+In the bidirectional [Contract Loop Playbook](/fullstack/contract-loop-playbook), this page covers the **forward chain**:
 
 1. Vona emits backend API metadata through Swagger/OpenAPI
 2. Zova consumes that metadata to generate frontend SDKs and schema-aware helpers
@@ -12,7 +12,7 @@ Cabloy’s fullstack productivity depends heavily on a contract loop:
 
 This is one of the strongest AI-leverage paths in the repo because it reduces duplicated type work and keeps backend/frontend coordination closer to source truth.
 
-## The contract loop in practical terms
+## The forward chain in practical terms
 
 A useful split is:
 
@@ -20,7 +20,9 @@ A useful split is:
 - fullstack docs define the bridge from emitted contract to generated SDK
 - frontend docs define the consumption side of the generated contract
 
-That means this page is the fullstack contract-bridge page, not the backend authoring page and not the frontend usage page.
+That means this page is the forward-chain bridge page, not the backend authoring page and not the frontend usage page.
+
+If the changed source is actually a frontend-owned resource that backend consumers later depend on, switch to the reverse-chain guide: [Frontend Metadata Back to Backend](/fullstack/frontend-metadata-to-backend).
 
 ## Backend side: Vona emits the contract
 
@@ -70,23 +72,31 @@ cd zova && npm run build:rest:cabloyBasicAdmin
 cd zova && npm run build:rest:cabloyBasicWeb
 ```
 
-A practical contract-loop sequence is:
+A practical forward-chain sequence is:
 
 1. author or change the backend contract
 2. emit or inspect backend OpenAPI output
-3. configure frontend module ownership if needed
-4. generate module-level OpenAPI SDK output
-5. run the rest build for the active Basic flavor when needed
-6. consume the generated contract from frontend code instead of re-declaring it manually
+3. if the frontend generator reads from a local Swagger endpoint, start the backend service first so the endpoint is reachable — in this repo, `npm run dev` is the normal path and exposes Swagger at `http://localhost:7102/swagger/json?version=V31`
+4. configure frontend module ownership if needed
+5. generate module-level OpenAPI SDK output
+6. run the rest build for the active flavor when needed
+7. consume the generated contract from frontend code instead of re-declaring it manually
+8. keep frontend follow-up thin by wrapping generated consumers with semantic facades instead of re-declaring the contract
+9. when the custom API still belongs to an existing resource, reuse the existing resource-owner instead of creating a competing cache owner
 
 A practical responsibility split is:
 
 - project-level OpenAPI config decides where the backend Swagger/OpenAPI source comes from
 - module-level OpenAPI config decides which generated contract slice belongs to which frontend module
+- module-level ownership should be declared explicitly with `operations.match` or `operations.ignore`
+
+If both `operations.match` and `operations.ignore` are empty, frontend SDK generation should fail fast instead of generating a large unrelated contract surface for the module. That fail-fast behavior helps both developers and AI agents notice the missing ownership boundary immediately and repair the config before the wrong SDK slice is generated.
 
 A practical regeneration rule is:
 
 - if the backend contract changed, prefer regenerating the SDK/rest layer before hand-editing frontend request code
+- if `npm run zova :openapi:generate ...` fails because the local Swagger source is unavailable, first start the backend service and confirm `http://localhost:7102/swagger/json?version=V31` is reachable before treating generation as broken
+- if the generated consumer path is already correct, but frontend behavior still looks stale, stop patching generated files and diagnose consumer drift or local dependency drift instead
 
 ## Cabloy Start workflow
 

package/cabloy-docs/fullstack/tutorial-3-frontend-metadata-sharing.md

@@ -2,7 +2,7 @@
 
 <Badge type="info" text="Basic" />
 
-In this tutorial, one prompt lets AI show the reverse direction of Cabloy’s fullstack contract loop: backend field metadata can reference frontend render resources.
+In this tutorial, one prompt lets AI show the **reverse chain** of Cabloy’s fullstack contract loop: backend field metadata can reference frontend render resources.
 
 You start with the simplest path first: reuse the existing built-in rendering resources for the `level` field.
 
@@ -19,7 +19,7 @@ By the end of this tutorial, you will understand:
 Give AI a prompt like this:
 
 ```text
-Please add a level field to the Student resource. It should be a number field with these enum values:
+Please add a level field to the Student resource. It should be a required number field with these enum values:
 
 - 1: beginner
 - 2: intermediate

package/cabloy-docs/fullstack/tutorial-4-custom-level-renderers.md

@@ -4,6 +4,8 @@
 
 In this tutorial, one prompt lets AI upgrade the `level` field from built-in render resources to custom frontend renderers owned by the `demo-student` module.
 
+This is the **reverse chain** custom-resource handoff branch of the contract loop.
+
 ## Goal
 
 By the end of this tutorial, you will understand:
@@ -54,6 +56,7 @@ Usage notes:
 - use `:create:component` when you need a custom frontend component/controller surface
 - generation gives you the structural starting point, but this tutorial still expects manual refinement so the result matches the `demo-student` teaching implementation
 - after frontend resources exist, return to the backend entity and point `ZovaRender.field(...)` and `ZovaRender.cell(...)` at the custom module resources
+- once backend metadata starts consuming those new frontend resources, treat the next step as a reverse fullstack handoff rather than frontend-only cleanup: refresh generated output, rebuild the relevant flavor, and re-sync Vona dependencies
 
 ## Generated or affected files
 
@@ -96,22 +99,44 @@ That means the backend still defines the business field, validation, and metadat
 
 ## Verification
 
-1. make sure the local dev workflow is running:
+1. refresh the generated handoff surfaces before checking backend consumers:
+
+```bash
+npm run zova :tools:metadata demo-student
+npm run build:zova:admin
+npm run deps:vona
+```
+
+If the same renderer path must also be available for Web, also run:
+
+```bash
+npm run build:zova:web
+npm run deps:vona
+```
+
+If backend-side type consumers still cannot see the new shared renderer types even though generated `.zova-rest` output is already correct, rebuild `vona/node_modules` and reinstall dependencies:
+
+```bash
+cd vona && rm -rf node_modules && pnpm install
+```
+
+2. make sure the local dev workflow is running:
 
 ```bash
 npm run dev
 ```
 
-2. open `http://localhost:7102/admin/`
-3. enter the **Student** list page and verify that the `level` column now uses the custom table-cell presentation
-4. open a Student create, update, or view form and verify that the `level` field now uses the custom form-field behavior
-5. inspect `vona/src/module/demo-student/src/entity/student.tsx` and confirm that the backend metadata now points to `demo-student:formFieldLevel` and `demo-student:level`
+3. open `http://localhost:7102/admin/`
+4. enter the **Student** list page and verify that the `level` column now uses the custom table-cell presentation
+5. open a Student create, update, or view form and verify that the `level` field now uses the custom form-field behavior
+6. inspect `vona/src/module/demo-student/src/entity/student.tsx` and confirm that the backend metadata now points to `demo-student:formFieldLevel` and `demo-student:level`
 
 ## Read more
 
 - [Frontend Metadata Back to Backend](/fullstack/frontend-metadata-to-backend)
 - [Frontend CLI](/frontend/cli)
 - [Component Guide](/frontend/component-guide)
+- [Zova Form Under the Hood](/frontend/zova-form-under-the-hood)
 - [Bean Scene Boilerplate Variants](/reference/bean-scene-boilerplates)
 
 ## Next step

package/cabloy-docs/fullstack/tutorial-5-backend-contract-sharing.md

@@ -2,7 +2,7 @@
 
 <Badge type="info" text="Basic" />
 
-In this tutorial, one prompt lets AI show the forward direction of Cabloy’s fullstack contract loop: backend API contracts that generate and refresh the frontend consumption surface.
+In this tutorial, one prompt lets AI show the **forward chain** of Cabloy’s fullstack contract loop: backend API contracts that generate and refresh the frontend consumption surface.
 
 The teaching thread in this page is the pair of Student actions:
 
@@ -15,7 +15,8 @@ By the end of this tutorial, you will understand:
 
 - how a backend controller and DTO change becomes frontend generated API output
 - how backend row-action metadata can drive frontend table actions
-- how generated API, frontend model helpers, and row-action beans fit into one contract-sharing workflow
+- how generated API, thin frontend model helpers, and row-action beans fit into one forward-chain workflow
+- why custom resource endpoints that still belong to the same resource should reuse the existing resource-owner instead of creating a competing cache owner
 
 ## AI Prompt
 
@@ -26,8 +27,6 @@ Please add two custom actions to the Student list:
 
 - Summary: return or display a student summary for the selected row
 - Force Delete: permanently delete the selected student through a dedicated row action
-
-Make both actions work end to end, from the backend contract to the Student list page.
 ```
 
 ## Why this step matters
@@ -60,6 +59,8 @@ Usage notes:
 - use the backend controller and DTOs as the starting point
 - inspect the module OpenAPI config before generation
 - prefer regeneration over hand-written duplicate API layers when the module already owns an OpenAPI contract surface
+- keep frontend follow-up thin: treat the module model as a semantic facade over generated API consumers rather than a second contract-definition layer
+- if the custom endpoint still belongs to the existing resource, reuse the existing resource-owner for server-state ownership
 
 ## Generated or affected files
 
@@ -105,10 +106,11 @@ This tutorial is easiest to understand as one contract chain:
 3. `dto/studentSelectResItem.tsx` defines the row-action metadata that exposes those actions in the Student list page
 4. `cli/openapi.config.ts` tells the frontend module which backend operations it owns
 5. `src/api/demoStudent.ts` is the generated typed API surface created from that backend contract
-6. `src/model/student.ts` wraps the generated API in frontend business-facing helper methods
-7. `tableCell.actionSummary.tsx` and `tableCell.actionDeleteForce.tsx` turn those model methods into visible row actions
+6. `src/model/student.ts` wraps the generated API in a thin frontend semantic facade
+7. the model should reuse the existing resource-owner for server-state ownership when the new API still belongs to the Student resource
+8. `tableCell.actionSummary.tsx` and `tableCell.actionDeleteForce.tsx` turn those model methods into visible row actions
 
-That is the practical contract-sharing loop: backend controller and DTO truth flows into generated frontend API output, then into frontend model helpers, and finally into visible table actions.
+That is the practical forward chain: backend controller and DTO truth flows into generated frontend API output, then into thin frontend model helpers, and finally into visible table actions.
 
 ## Verification
 

package/cabloy-docs/fullstack/tutorial-6-one-contract-four-uses.md

@@ -4,6 +4,8 @@
 
 In this tutorial, one prompt lets AI close the series by showing Cabloy’s core fullstack idea: one field-oriented contract surface can drive several behaviors across backend and frontend.
 
+This capstone sits on top of both the forward chain and the reverse chain rather than replacing either one.
+
 This time the main teaching field is `mobile`, while `level` stays as the supporting example for table and form rendering.
 
 ## Goal

package/cabloy-docs/fullstack/tutorials-overview.md

@@ -61,16 +61,29 @@ Those pages explain the repo entrypoints and the CLI-first workflow model that t
 - [Tutorial 1: Create Your First Module](/fullstack/tutorial-1-first-module)
 - [Tutorial 2: Create Your First CRUD](/fullstack/tutorial-2-first-crud)
 
-### Phase 2: Share frontend rendering metadata through the backend contract
+### Phase 2: Reverse chain — share frontend rendering metadata through the backend contract
 
 - [Tutorial 3: Frontend Metadata Sharing](/fullstack/tutorial-3-frontend-metadata-sharing)
 - [Tutorial 4: Custom Form/Table Renderers for Level](/fullstack/tutorial-4-custom-level-renderers)
 
-### Phase 3: Share backend contracts forward into frontend consumption
+Important handoff note for this phase:
+
+- this phase teaches the **reverse chain** of the Cabloy contract loop
+- Tutorial 3 uses the built-in metadata branch
+- Tutorial 4 uses the custom resource handoff branch
+- once a frontend resource created in these tutorials is later consumed by backend metadata, do not stop at frontend source edits alone
+- refresh the generated frontend output, run the relevant flavor build, then run `npm run deps:vona`
+- if backend-side shared types still look stale after that normal sync flow, rebuild `vona/node_modules` and reinstall dependencies
+
+See [Contract Loop Playbook](/fullstack/contract-loop-playbook) and [Frontend Metadata Back to Backend](/fullstack/frontend-metadata-to-backend) for the full reverse-chain explanation.
+
+### Phase 3: Forward chain — share backend contracts into frontend consumption
 
 - [Tutorial 5: Backend Contract Sharing](/fullstack/tutorial-5-backend-contract-sharing)
 
-### Phase 4: Understand one contract surface through one field story
+This phase teaches the **forward chain** of the contract loop: backend contract truth changes first, generated frontend consumers are refreshed second, and frontend follow-up stays thin and resource-owner-aware.
+
+### Phase 4: One field story across multiple contract surfaces
 
 - [Tutorial 6: One Contract Surface, Four Uses](/fullstack/tutorial-6-one-contract-four-uses)
 

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

@@ -51,6 +51,8 @@ These backend entries come from the current `vonaModule.onions` metadata in `a-a
 
 These frontend entries come from the current `zovaModule.onions` metadata in `a-command` and `a-table`.
 
+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
 
 Do not assume every bean scene supports named variants.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "cabloy",
-  "version": "5.1.60",
+  "version": "5.1.61",
   "gitHead": "2c5c19284bab738e492856189acb6fad74b8a7b7",
   "description": "A Node.js fullstack framework",
   "keywords": [
@@ -22,6 +22,7 @@
   "type": "module",
   "scripts": {
     "init": "node scripts/init.ts",
+    "init:test-data": "node scripts/initTestData.ts",
     "upgrade": "node scripts/upgrade.ts",
     "upgrade:dry-run": "node scripts/upgrade.ts --dry-run",
     "vona": "node ./vona/packages-cli/cli/src/bin/vona.ts --projectPath=vona",

package/scripts/init.ts

@@ -247,22 +247,7 @@ function buildSsrCabloyBasicStartBatch(): void {
   }
 }
 
-// --- Step F: initTestData ---
-
-function initTestData(): void {
-  // eslint-disable-next-line
-  console.log('[init] Initializing test data via npm run test...');
-  try {
-    exec('npm run test');
-  } catch {
-    // eslint-disable-next-line
-    console.warn(
-      '[init] npm run test failed after init completed; Redis may be unavailable, skipping test data initialization',
-    );
-  }
-}
-
-// --- Step G: cleanupWorkspaceYaml ---
+// --- Step F: cleanupWorkspaceYaml ---
 
 function cleanupWorkspaceYaml(): void {
   const subProjects = ['vona', 'zova'];
@@ -283,7 +268,7 @@ function cleanupWorkspaceYaml(): void {
   }
 }
 
-// --- Step H: init:cabloy-docs ---
+// --- Step G: init:cabloy-docs ---
 
 function initCabloyDocs(): void {
   const pkgPath = resolve(CABLOY_DOCS_DIR, 'package.json');
@@ -306,6 +291,5 @@ initZova();
 initCabloyDocs();
 buildSsrCabloyBasicStartBatch();
 writeVersionMarker();
-initTestData();
 // eslint-disable-next-line
 console.log('[init] Done!');

package/scripts/initTestData.ts

@@ -0,0 +1,25 @@
+import { execSync } from 'node:child_process';
+import { dirname, resolve } from 'node:path';
+import { fileURLToPath } from 'node:url';
+
+const __dirname = dirname(fileURLToPath(import.meta.url));
+const ROOT_DIR = resolve(__dirname, '..');
+
+function exec(cmd: string): void {
+  execSync(cmd, { stdio: 'inherit', cwd: ROOT_DIR });
+}
+
+function initTestData(): void {
+  // eslint-disable-next-line no-console
+  console.log('[init:test-data] Initializing test data via npm run test...');
+  try {
+    exec('npm run test');
+  } catch {
+    // eslint-disable-next-line no-console
+    console.warn(
+      '[init:test-data] npm run test failed after init completed; Redis may be unavailable, skipping test data initialization',
+    );
+  }
+}
+
+initTestData();

package/scripts/upgrade.ts

@@ -300,7 +300,17 @@ function runInit(dryRun: boolean, version: string): void {
   exec('npm run init', { CABLOY_VERSION: version } as any);
 }
 
-// --- Step 5: Cleanup ---
+// --- Step 5: Run init:test-data ---
+
+function runInitTestData(dryRun: boolean): void {
+  if (dryRun) {
+    log('  [dry-run] Run: npm run init:test-data');
+    return;
+  }
+  exec('npm run init:test-data');
+}
+
+// --- Step 6: Cleanup ---
 
 function cleanup(dryRun?: boolean): void {
   if (dryRun) {
@@ -366,6 +376,11 @@ async function main(): Promise<void> {
     runInit(dryRun, latestPackageInfo.version);
     log('');
 
+    // 5. Run init:test-data
+    log('Running npm run init:test-data...');
+    runInitTestData(dryRun);
+    log('');
+
     if (dryRun) {
       log(`[dry-run] Current Cabloy version would become: ${latestPackageInfo.version}`);
     } else {
@@ -374,7 +389,7 @@ async function main(): Promise<void> {
 
     log('Upgrade complete!');
   } finally {
-    // 5. Cleanup
+    // 6. Cleanup
     cleanup(dryRun);
   }
 }

package/vona/pnpm-lock.yaml

@@ -7403,6 +7403,9 @@ packages:
   zova-module-a-routertabs@5.1.28:
     resolution: {integrity: sha512-GCDEVygoSgND197VBE4uH+rop5zCffWKjWZKboj20X7Wtcen5/stNNL/pNBoSgQmB+vpSnXqsGH2mHd2uq1ddg==}
 
+  zova-module-a-routertabs@5.1.29:
+    resolution: {integrity: sha512-5jiLc2UwWpzFzGbB7zRXH9FTQBcMPCUcF7zvvjZQaUPHlKeiOPKWzf8w3Lf21FOpluFkJ4Hwyz8ApU5tm9/dZw==}
+
   zova-module-a-ssr@5.1.23:
     resolution: {integrity: sha512-KcG1WVyNIkZ6xQ0s1azJQhmbEnEyychsmhsnbAwurpALwmfWFaSGDQlWVAdx2KxSb4TwV+X1iZhHvPnDOxmv5w==}
 
@@ -7418,6 +7421,9 @@ packages:
   zova-module-a-table@5.1.30:
     resolution: {integrity: sha512-/kHtRbI3lcajrjSaY5iYfalMslkYFSb6j4XBLA++pax2M7lCj3xqghRm9YQWDzXyAUNk+e6TxR8o2cREfLXtOQ==}
 
+  zova-module-a-table@5.1.31:
+    resolution: {integrity: sha512-lU3Kx6wPr0VVoPL2YsBEceQ35WenoRGZhyu2rQ0nakslwQ0cjywX4nfevfxUD2AYsQMFqkjYSHBZpZ25337NCA==}
+
   zova-module-a-zod@5.1.27:
     resolution: {integrity: sha512-t5nddb0S78QFJISAbVbMwpUmxejSYQIp4fMlmVs94wT1XXidTUD2e5kwC6sf3HvBn+9io+FBYSKlgqhWxcVOaA==}
 
@@ -7430,9 +7436,15 @@ packages:
   zova-module-a-zova@5.1.69:
     resolution: {integrity: sha512-wRWeERWiHv1VffLSjM+L82jUw4lhN+SykEd2gidAmlzqiJVwr97mqpRfm+4xAa8/i6+lIMbOdgyKnfmREMaC5A==}
 
+  zova-module-a-zova@5.1.70:
+    resolution: {integrity: sha512-FAGLow6iVpMxyLlVoKjeb0xcMQiheOjYVlSUI1m0Q64H8vdMovm5AJRD/79C5ETcHgkVJxgKCVl9C4xN19aTUQ==}
+
   zova-module-rest-resource@5.1.35:
     resolution: {integrity: sha512-bRGoS4WBFj7w74/3Nm2yZzRUu3efUQ4MuOwtRjKHv+Dhl1VFpPE9jwA2o+uHignjmoT1jcZXUb+/OxDT9/FOTQ==}
 
+  zova-module-rest-resource@5.1.36:
+    resolution: {integrity: sha512-lIKtm1ZGbd9uhLglqSXRJDe5el4UVtsOSvE/qrqxib6thtDvu6vFgZMu8ZrrQ8h1KPktZ9WOiX5oD/OpoYG5gg==}
+
   zova-rest-cabloy-basic-admin@file:.zova-rest/cabloy-basic-admin:
     resolution: {directory: .zova-rest/cabloy-basic-admin, type: directory}
 
@@ -7445,12 +7457,18 @@ packages:
   zova-suite-a-zova@5.1.101:
     resolution: {integrity: sha512-150zX7i6ALJgbjhtHquClsvnf9N+zhxwMJeniMXFEFyUfGQ4u5n5nOku41icVl1HzvuFBbHk8sPGNITHAOB9gw==}
 
+  zova-suite-a-zova@5.1.102:
+    resolution: {integrity: sha512-R5HB45pBHN9lZhWRmCuWH0DSMcDb6iBsgCQojxSZNsD8ttSCvWyu2FwNAmCQFguwEuPyZw8ZZndwr/8HAU3IxQ==}
+
   zova-suite-a-zova@5.1.98:
     resolution: {integrity: sha512-sipc11Lc3amHUbvLaluromNELu8XK8fWT2SyK8iTvZuRXMnpTAdE+s0lkfzO3bdmdfBLrlSyJq8z1derDzt67w==}
 
   zova@5.1.102:
     resolution: {integrity: sha512-c1pf2pYQMoB6HqMgIg1hCTwjwI8ZZwi9t1NoyGy/9gz82xBoaE9ykbMnMdn0Ug2vJYfNLCCrH9P1+OF86fWjTg==}
 
+  zova@5.1.103:
+    resolution: {integrity: sha512-AR+Pk9hozKvB6/R/fZ4WPtKX4I0TJxmHx8Ao8dpLovlXhacYi50dUHOTxUQDavwspkWjMDinNqjQWo2MpAVc9g==}
+
   zova@5.1.99:
     resolution: {integrity: sha512-S8voYFvheBH3Qpg2zYRGv3sssqsHCdBROnz/t8E4VmKsWqdhMrMo65p9XR1H1Lk+0J2m2KjA5Zf6dalClnPq3g==}
 
@@ -13064,6 +13082,8 @@ snapshots:
 
   zova-module-a-routertabs@5.1.28: {}
 
+  zova-module-a-routertabs@5.1.29: {}
+
   zova-module-a-ssr@5.1.23:
     dependencies:
       devalue: 5.8.1
@@ -13090,6 +13110,13 @@ snapshots:
     transitivePeerDependencies:
       - vue
 
+  zova-module-a-table@5.1.31(vue@3.5.38(typescript@5.9.3)):
+    dependencies:
+      '@tanstack/table-core': 8.21.3
+      '@tanstack/vue-table': 8.21.3(vue@3.5.38(typescript@5.9.3))
+    transitivePeerDependencies:
+      - vue
+
   zova-module-a-zod@5.1.27:
     dependencies:
       '@cabloy/zod-errors-custom': link:packages-utils/zod-errors-custom
@@ -13136,8 +13163,26 @@ snapshots:
       - typescript
       - vue
 
+  zova-module-a-zova@5.1.70(typescript@5.9.3)(vue@3.5.38(typescript@5.9.3)):
+    dependencies:
+      '@cabloy/compose': link:packages-utils/compose
+      '@cabloy/deps': link:packages-utils/deps
+      '@cabloy/json5': link:packages-utils/json5
+      '@cabloy/module-info': 2.0.0
+      '@cabloy/utils': link:packages-utils/utils
+      '@cabloy/vue-router': 4.4.16(vue@3.5.38(typescript@5.9.3))
+      '@cabloy/word-utils': 2.1.14
+      defu: 6.1.7
+      luxon: 3.7.2
+      zova-jsx: 1.1.63(typescript@5.9.3)
+    transitivePeerDependencies:
+      - typescript
+      - vue
+
   zova-module-rest-resource@5.1.35: {}
 
+  zova-module-rest-resource@5.1.36: {}
+
   zova-rest-cabloy-basic-admin@file:.zova-rest/cabloy-basic-admin(typescript@5.9.3):
     dependencies:
       '@tanstack/query-core': 5.101.0
@@ -13146,7 +13191,7 @@ snapshots:
       table-identity: link:packages-utils/table-identity
       vue: 3.5.38(typescript@5.9.3)
       zod: '@cabloy/zod@4.3.6'
-      zova: 5.1.102(typescript@5.9.3)(vue@3.5.38(typescript@5.9.3))
+      zova: 5.1.103(typescript@5.9.3)(vue@3.5.38(typescript@5.9.3))
       zova-jsx: 1.1.63(typescript@5.9.3)
       zova-module-a-api: 5.1.18
       zova-module-a-bean: 5.1.28
@@ -13158,11 +13203,11 @@ snapshots:
       zova-module-a-model: 5.1.27(vue@3.5.38(typescript@5.9.3))
       zova-module-a-openapi: 5.1.34
       zova-module-a-router: 5.1.26
-      zova-module-a-routertabs: 5.1.28
+      zova-module-a-routertabs: 5.1.29
       zova-module-a-ssr: 5.1.23
       zova-module-a-style: 5.1.29
-      zova-module-a-table: 5.1.30(vue@3.5.38(typescript@5.9.3))
-      zova-module-rest-resource: 5.1.35
+      zova-module-a-table: 5.1.31(vue@3.5.38(typescript@5.9.3))
+      zova-module-rest-resource: 5.1.36
     transitivePeerDependencies:
       - '@vue/composition-api'
       - debug
@@ -13266,6 +13311,40 @@ snapshots:
       - typescript
       - vue
 
+  zova-suite-a-zova@5.1.102(typescript@5.9.3)(vue@3.5.38(typescript@5.9.3)):
+    dependencies:
+      zova-module-a-api: 5.1.18
+      zova-module-a-app: 5.1.21
+      zova-module-a-bean: 5.1.28
+      zova-module-a-behavior: 5.1.22
+      zova-module-a-behaviors: 5.1.18
+      zova-module-a-boundary: 5.1.18
+      zova-module-a-command: 5.1.29
+      zova-module-a-fetch: 5.1.20
+      zova-module-a-form: 5.1.35(vue@3.5.38(typescript@5.9.3))
+      zova-module-a-icon: 5.1.23
+      zova-module-a-interceptor: 5.1.26
+      zova-module-a-logger: 5.1.23
+      zova-module-a-meta: 5.1.18
+      zova-module-a-model: 5.1.27(vue@3.5.38(typescript@5.9.3))
+      zova-module-a-openapi: 5.1.34
+      zova-module-a-router: 5.1.26
+      zova-module-a-routerstack: 5.1.23
+      zova-module-a-routertabs: 5.1.29
+      zova-module-a-ssr: 5.1.23
+      zova-module-a-ssrhmr: 5.1.19
+      zova-module-a-ssrserver: 5.1.19
+      zova-module-a-style: 5.1.29
+      zova-module-a-table: 5.1.31(vue@3.5.38(typescript@5.9.3))
+      zova-module-a-zod: 5.1.30
+      zova-module-a-zova: 5.1.70(typescript@5.9.3)(vue@3.5.38(typescript@5.9.3))
+    transitivePeerDependencies:
+      - '@vue/composition-api'
+      - debug
+      - supports-color
+      - typescript
+      - vue
+
   zova-suite-a-zova@5.1.98(typescript@5.9.3)(vue@3.5.38(typescript@5.9.3)):
     dependencies:
       zova-module-a-api: 5.1.18
@@ -13311,6 +13390,17 @@ snapshots:
       - typescript
       - vue
 
+  zova@5.1.103(typescript@5.9.3)(vue@3.5.38(typescript@5.9.3)):
+    dependencies:
+      zova-core: 5.1.57(typescript@5.9.3)
+      zova-suite-a-zova: 5.1.102(typescript@5.9.3)(vue@3.5.38(typescript@5.9.3))
+    transitivePeerDependencies:
+      - '@vue/composition-api'
+      - debug
+      - supports-color
+      - typescript
+      - vue
+
   zova@5.1.99(typescript@5.9.3)(vue@3.5.38(typescript@5.9.3)):
     dependencies:
       zova-core: 5.1.54(typescript@5.9.3)