cabloy 5.1.75 → 5.1.76

package/.claude/hooks/contract-loop-gate.ts

@@ -234,7 +234,7 @@ function buildMessages(filePath: string, result: AnalysisResult): string {
 
   if (result.reverseReason) {
     messages.push(
-      `Reverse chain: ${result.reverseReason} If backend tooling or backend metadata will consume this handoff, refresh generated metadata when applicable, then run \`npm run build:zova:admin\` and \`npm run deps:vona\` for the Cabloy Basic Admin path.`,
+      `Reverse chain: ${result.reverseReason} If backend tooling or backend metadata will consume this handoff, refresh generated metadata when applicable, run the relevant Zova build first, and then run \`npm run deps:vona\` for the Cabloy Basic path. Use \`npm run build:zova:admin\` for Admin changes, and also run \`npm run build:zova:web\` when the Web flavor is affected.`,
     );
     if (isHighConfidenceReverseSource(filePath)) {
       if (shouldSkipAutoSync(filePath)) {

package/.claude/skills/cabloy-contract-loop/SKILL.md

@@ -11,17 +11,19 @@ Read the public [Contract Loop Playbook](../../../cabloy-docs/fullstack/contract
 
 ## Important recovery note for stale local file consumers
 
-When generated `.zova-rest` output or other generated consumer artifacts already contain the expected new keys or types but Vona still behaves as if old consumer types are installed, treat that first as a local file-dependency installation problem rather than a source-editing problem.
+When the generated `.zova-rest` artifacts or other generated consumer artifacts already contain the expected new keys or types but Vona still sees stale consumer types, treat that first as a local dependency drift problem rather than a source-editing problem.
 
 This includes the reverse fullstack direction where newly added frontend resources such as custom renderers are later consumed by backend metadata.
 
 In that situation:
 
 1. run the normal sync or regeneration flow first
-2. if Vona consumes newly added or changed Zova Admin render/action/metadata in Cabloy Basic, run `npm run build:zova:admin` from the repo root before anything else
-3. otherwise, if the change only affects flavor-built REST/type output, rebuild the relevant Zova flavor output first
-4. run `deps:vona`
-5. if stale behavior remains, rebuild `vona/node_modules` and reinstall dependencies
+2. run the relevant Zova build from the repo root before `npm run deps:vona`
+   - use `npm run build:zova:admin` for Admin-facing render/action/metadata changes
+   - also run `npm run build:zova:web` when the Web flavor is affected
+3. do not treat `build:rest:*` alone as sufficient, because the SSR bundle and rest output must move together
+4. run `npm run deps:vona`
+5. if the generated `.zova-rest` artifacts already contain the expected changes but Vona still sees stale types, delete `vona/node_modules` and reinstall dependencies
 
 Do not keep debugging source-level contract or renderer changes until the local file-package installation state is known to be healthy.
 

package/.claude/skills/cabloy-contract-loop/references/contract-loop-map.md

@@ -123,8 +123,9 @@ Practical check after generation:
    - module metadata
 2. generated handoff
    - metadata output
-   - flavor build output
+   - the relevant flavor build output
 3. sync surface
+   - run the relevant Zova build first
    - `deps:vona`
 4. consumer layers
    - backend `ZovaRender.*(...)` references

package/.claude/skills/cabloy-contract-loop/references/verification-checklist.md

@@ -50,10 +50,10 @@ If all of these are true:
 - generated `.zova-rest` or related generated consumer artifacts already contain the expected new keys or types
 - the normal regeneration or sync flow already ran
 - when relevant, the affected Zova flavor build already ran
-- `deps:vona` already ran
-- Vona still behaves as if old consumer types are installed
+- `npm run deps:vona` already ran
+- Vona still sees stale types
 
-Then suspect a stale or unhealthy local installation state in `vona/node_modules`.
+Then treat it as local dependency drift and suspect a stale or unhealthy local installation state in `vona/node_modules`.
 
 Recovery action:
 

package/.claude/skills/cabloy-frontend-scaffold/SKILL.md

@@ -185,7 +185,7 @@ Stay frontend-first, but if the frontend task clearly depends on backend contrac
 - backend OpenAPI output may need refresh or inspection
 - backend DTO/controller response shape may be the real source of truth
 - frontend SDK or schema-driven layers should be regenerated from contract output rather than hand-patched
-- newly added frontend resources that backend metadata will consume may require a reverse handoff through frontend build output and `deps:vona`
+- newly added frontend resources that backend metadata will consume may require a reverse handoff through the relevant Zova build first and then `npm run deps:vona`
 
 Do not turn the skill into a backend workflow. Only surface the reminder when the contract boundary is clearly involved.
 

package/.claude/skills/cabloy-frontend-scaffold/references/follow-up-checklist.md

@@ -15,8 +15,9 @@ After generating or extending a frontend thread, check which follow-up layers ap
 - SSR init-data needs
 - OpenAPI SDK or schema-driven layer impact
 - backend contract reminder if frontend depends on generated backend contract output
-- if backend metadata will consume newly added frontend render resources, run the relevant Zova build and then `deps:vona`
-- if generated `.zova-rest` output is updated but backend still sees stale shared types, rebuild `vona/node_modules` and reinstall
+- if backend metadata will consume newly added frontend render resources, run the relevant Zova build first and then `npm run deps:vona`
+- do not treat `build:rest:*` alone as sufficient, because the SSR bundle and rest output must move together
+- if the generated `.zova-rest` artifacts are updated but backend still sees stale shared types after `npm run deps:vona`, treat it as local dependency drift and rebuild `vona/node_modules` and reinstall
 
 ## Interaction and UI follow-up
 

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

@@ -9,12 +9,12 @@ Use this skill when the user wants to change a field on an existing Vona backend
 
 ## Important recovery note for stale generated consumers
 
-When generated `.zova-rest` output already contains the expected new keys or types but Vona still behaves as if old consumer types are installed, treat that first as a local file-dependency installation problem rather than a source-editing problem.
+When the generated `.zova-rest` artifacts already contain the expected new keys or types but Vona still sees stale consumer types, treat that first as a local dependency drift problem rather than a source-editing problem.
 
 In that situation:
 
-1. run the normal sync flow such as `deps:vona`
-2. if the stale behavior remains, rebuild `vona/node_modules` and reinstall dependencies
+1. run the normal sync flow, including the relevant Zova build first and then `npm run deps:vona`
+2. if the generated `.zova-rest` artifacts already contain the expected changes but the stale behavior remains, rebuild `vona/node_modules` and reinstall dependencies
 
 Keep this recovery rule visible during renderer-aware or contract-loop follow-up work. Do not keep debugging source-level renderer registrations until the local file-package installation state is known to be healthy.
 

package/.claude/skills/cabloy-resource-field-update/references/custom-renderer-demo-checklist.md

@@ -94,9 +94,9 @@ cd vona && npm test -- <resource-test>.test.ts
 
 ## 6. Recovery rule when generated keys still look stale
 
-If the generated `.zova-rest` files already contain the new renderer keys but Vona still behaves as if old types are installed:
+If the generated `.zova-rest` artifacts already contain the new renderer keys but Vona still sees stale types after the normal sync flow:
 
-- suspect a stale or unhealthy `vona/node_modules` installation state
-- after normal `deps:vona`, rebuild `vona/node_modules` and reinstall dependencies if needed
+- treat it as local dependency drift
+- after the relevant Zova build and `npm run deps:vona`, rebuild `vona/node_modules` and reinstall dependencies if needed
 
 This is an installation-state recovery step, not the normal first move.

package/.claude/skills/cabloy-resource-field-update/references/follow-up-checklist.md

@@ -67,14 +67,16 @@ Apply when the user explicitly wants to demonstrate custom renderer development:
 ### If custom frontend renderers were introduced
 
 - `npm run zova :tools:metadata <module-name>`
-- `npm run build:zova:admin`
+- run the relevant Zova build first:
+  - `npm run build:zova:admin` for Admin-facing render/action/metadata changes
+  - also `npm run build:zova:web` when the Web flavor is affected
 - `npm run deps:vona`
 - `cd vona && npm run tsc`
 - `cd vona && npm test -- <resource-test>.test.ts`
 
 ## Common recovery rule
 
-If generated `.zova-rest` output already contains the new renderer keys but Vona still behaves as if old types are installed:
+If the generated `.zova-rest` artifacts already contain the new renderer keys but Vona still sees stale types after the normal sync flow:
 
-- suspect a stale `vona/node_modules` installation state
+- treat it as local dependency drift
 - rebuild `vona/node_modules` and reinstall dependencies if normal `deps:vona` sync did not recover the local file-package installation state

package/.claude/skills/cabloy-resource-field-update/references/verification-checklist.md

@@ -58,7 +58,14 @@ cd vona && npm run tsc
 cd vona && npm test -- <resource-test>.test.ts
 ```
 
-If web SSR also matters, add the web build and then repeat dependency sync as needed.
+If the same handoff must also be available to Web, also run:
+
+```bash
+npm run build:zova:web
+npm run deps:vona
+```
+
+Do not treat `build:rest:*` alone as sufficient, because the SSR bundle and rest output must move together.
 
 ## 4. What to verify in the result
 
@@ -82,11 +89,11 @@ Confirm:
 
 If all of these are true:
 
-- generated `.zova-rest` files already contain the new renderer keys
-- `deps:vona` was run
-- Vona still behaves as if old renderer types are installed
+- the generated `.zova-rest` artifacts already contain the new renderer keys
+- `npm run deps:vona` was run after the relevant Zova build
+- Vona still sees stale renderer types
 
-Then suspect a stale or unhealthy local installation state in `vona/node_modules`.
+Then treat it as local dependency drift and suspect a stale or unhealthy local installation state in `vona/node_modules`.
 
 Recovery action:
 

package/CHANGELOG.md

@@ -1,5 +1,12 @@
 # Changelog
 
+## 5.1.76
+
+### Improvements
+
+- Unify wording around reverse-chain dependency drift.
+- Finish cleanup of reverse-chain documentation wording.
+
 ## 5.1.75
 
 ### Improvements

package/CLAUDE.md

@@ -46,9 +46,8 @@ Before inventing a custom implementation path:
 - Treat contract-loop work as one of four branches: forward chain, reverse chain, consumer drift, or local dependency drift.
 - For the forward chain, change backend contract truth first and regenerate frontend consumers rather than hand-patching them.
 - After forward regeneration, keep frontend follow-up thin: prefer semantic model facades and reuse the existing resource-owner when the custom API still belongs to the same resource.
-- For the reverse chain, when Vona consumes newly added or changed Zova Admin render/action/metadata, always run `npm run build:zova:admin` before `npm run deps:vona`. Do not treat `build:rest:cabloyBasicAdmin` alone as sufficient, because the Admin JS bundle and rest output must move together.
-- If generated artifacts already contain the expected changes but consumers still behave stale, suspect local dependency drift before making more source edits.
-- For Vona consumption drift after Zova-generated type/rest output changes, if `npm run deps:vona` still leaves stale consumer types, delete `vona/node_modules` and reinstall dependencies before further debugging or hand-patching dependency links.
+- For the reverse chain, always run the relevant Zova build first, then run `npm run deps:vona`: use `npm run build:zova:admin` for Admin changes, and also run `npm run build:zova:web` when the Web flavor is affected. Do not treat `build:rest:*` alone as sufficient, because the SSR bundle and rest output must move together.
+- If the generated `.zova-rest` artifacts already contain the expected changes but Vona consumers still see stale types after `npm run deps:vona`, treat it as local dependency drift: delete `vona/node_modules` and reinstall dependencies before further debugging or hand-patching dependency links.
 - For Cabloy Start, apply the same reverse-chain logic but resolve the Start-specific flavor names and generated-output paths from the active Start repo before recommending commands.
 - Treat legacy docs as input material, not as unquestioned truth. When docs conflict with source code, prefer current source code.
 - For frontend work, assume Cabloy Basic and Cabloy Start share a frontend engineering layer but may diverge in UI layer, frontend flavors, suite/module availability, SSR site baselines, project assets, and generated outputs.

package/cabloy-docs/fullstack/contract-loop-playbook.md

@@ -162,9 +162,9 @@ Then diagnose **generated-output drift**:
 
 Examples:
 
-- generated `.zova-rest` output already contains the new keys or types
-- generated SDK already contains the new method
-- backend or frontend still behaves as if old local file packages are installed
+- the generated `.zova-rest` artifacts already contain the new keys or types
+- the generated SDK already contains the new method
+- backend or frontend still sees stale consumers after the normal sync flow
 
 Then suspect **local dependency drift**:
 
@@ -272,7 +272,7 @@ and then the relevant build path for the active edition and flavor.
 
 ### Stage 3: Vona sync handoff
 
-After the frontend-generated handoff is ready, re-sync Vona’s local file dependencies.
+After the frontend-generated handoff is ready, run the relevant Zova build first and then re-sync Vona’s local dependency state with `npm run deps:vona`.
 
 For the current **Cabloy Basic Admin** branch, the representative sequence is:
 
@@ -281,7 +281,14 @@ npm run build:zova:admin
 npm run deps:vona
 ```
 
-If the same resource path must also be available to Web, also refresh the Web branch.
+If the same resource path must also be available to Web, also run:
+
+```bash
+npm run build:zova:web
+npm run deps:vona
+```
+
+Do not treat `build:rest:*` alone as sufficient. The SSR bundle and the generated rest output should move together.
 
 For **Cabloy Start**, use the same reverse-chain logic, but resolve the Start-specific flavor names and output paths from the active Start repo before recommending commands.
 
@@ -300,7 +307,7 @@ Typical checks:
 Use this branch only when all of these are already true:
 
 - source truth was edited in the right place
-- generation or build output already contains the intended change
+- the generated `.zova-rest` artifacts or other build output already contain the intended change
 - the normal sync flow already ran
 - consumers still behave stale
 

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

@@ -125,7 +125,7 @@ For Cabloy Basic, the representative reverse-chain path is:
 
 1. change the frontend-owned truth
 2. regenerate frontend metadata when applicable
-3. build the relevant frontend flavor output so the shared handoff is refreshed
+3. run the relevant Zova build so the shared handoff is refreshed
 4. run `npm run deps:vona`
 5. verify backend-side consumers can now see the refreshed handoff
 
@@ -137,7 +137,7 @@ npm run build:zova:admin
 npm run deps:vona
 ```
 
-If the same resource path must also be available for Web, add:
+If the same resource path must also be available for Web, also run:
 
 ```bash
 npm run build:zova:web
@@ -146,7 +146,8 @@ npm run deps:vona
 
 A practical rule is:
 
-- treat metadata generation, flavor build, and `deps:vona` as one reverse-chain handoff
+- treat metadata generation, the relevant flavor build, and `deps:vona` as one reverse-chain handoff
+- do not treat `build:rest:*` alone as sufficient, because the SSR bundle and rest output should move together
 - do not stop after the frontend source edit alone
 
 ## `training-student` as a compact reverse-chain specimen
@@ -194,8 +195,8 @@ This is the problem when:
 Typical fix:
 
 1. stop editing source files
-2. run the normal sync flow with `npm run deps:vona`
-3. if needed, rebuild `vona/node_modules` and reinstall dependencies
+2. run the normal sync flow with the relevant Zova build first and then `npm run deps:vona`
+3. if the generated `.zova-rest` artifacts already contain the expected changes but Vona still sees stale types, rebuild `vona/node_modules` and reinstall dependencies
 
 Representative recovery path:
 

package/cabloy-docs/fullstack/introduction.md

@@ -103,7 +103,7 @@ Use the playbook to distinguish four cases clearly:
 
 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.
+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, then run `npm run deps:vona`, and if the generated `.zova-rest` artifacts already contain the expected changes but Vona still sees stale shared types, rebuild `vona/node_modules` and reinstall dependencies.
 
 ## How the fullstack system stays connected
 

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

@@ -126,7 +126,7 @@ 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:
+If backend-side type consumers still cannot see the new shared renderer types even though the generated `.zova-rest` artifacts are already correct after the normal sync flow, treat it as local dependency drift and rebuild `vona/node_modules` and reinstall dependencies:
 
 ```bash
 cd vona && rm -rf node_modules && pnpm install

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

@@ -73,7 +73,8 @@ Important handoff note for this phase:
 - 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
+- do not treat `build:rest:*` alone as sufficient, because the SSR bundle and rest output must move together
+- if the generated `.zova-rest` artifacts already contain the expected changes but backend-side shared types still look stale after that normal sync flow, treat it as local dependency drift and 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.
 

package/package.json

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

package/vona/pnpm-lock.yaml

@@ -474,8 +474,8 @@ importers:
         specifier: npm:@cabloy/zod@4.3.8
         version: '@cabloy/zod@4.3.8'
       zova:
-        specifier: ^5.1.118
-        version: 5.1.118(typescript@5.9.3)(vue@3.5.39(typescript@5.9.3))
+        specifier: ^5.1.119
+        version: 5.1.119(typescript@5.9.3)(vue@3.5.39(typescript@5.9.3))
       zova-jsx:
         specifier: ^1.1.67
         version: 1.1.67(typescript@5.9.3)
@@ -7613,15 +7613,24 @@ packages:
   zova-module-a-zova@5.1.81:
     resolution: {integrity: sha512-H5D3TwmGVi7C4syp6EZJSy0JZB8pk92gh4zWOelj8l/WT2Xqfc/98RtL/o21lsrOobSjJC8hfplSdJWuTUO60w==}
 
+  zova-module-a-zova@5.1.82:
+    resolution: {integrity: sha512-JDgLmu/7+oPrFLb7/zhHtl739+dhuBL/J508ObWuahiVymU7wzJEPPSmi/XaCnKB58FXpfcaoe0rMoxNsT0gmA==}
+
   zova-module-rest-resource@5.1.40:
     resolution: {integrity: sha512-rMqZaXSK6nJ4LW2O1yO/jZqxI7joCiWylzjutMTKpx7EfNmtK1t1nVoWFd+gCTxqgbbv9uXh0vfFaSFA7GKYFg==}
 
   zova-suite-a-zova@5.1.117:
     resolution: {integrity: sha512-Ceo7CqXmmDHCGKvwQ9cb90DLbF5P0s2qT/jYyBeTf8BllpSjIqYqxUPE0Eh88XYWHlTWgH28wP6SD7DeGfPaCA==}
 
+  zova-suite-a-zova@5.1.118:
+    resolution: {integrity: sha512-DhnlKOT6VG0+v60TjQNN/Qaa9v1UEsGU8jo/layFlLociG5AHUuoiCABSN4dklYcBnAVwu1EvCVQhcgnWwrPfA==}
+
   zova@5.1.118:
     resolution: {integrity: sha512-hgj4FKy68B2Mve47NrhqhQEaESbdZUci/7WtlGagaZgyFzfBn19CHkWDRkJNToeBVb/LD1Zwt0HY7TDEe7WPDw==}
 
+  zova@5.1.119:
+    resolution: {integrity: sha512-st8Wwh4NvoNcZUvNb67XsG7GVhaMyFIK/EZ6Zfc0uqwdKtUShC6IBGHMc3u/28cIXRcpsH5REi9HL6SB8WQj/Q==}
+
   zwitch@1.0.5:
     resolution: {integrity: sha512-V50KMwwzqJV0NpZIZFwfOD5/lyny3WlSzRiXgA0G7VUnRlqttta1L6UQIHzd6EuBY/cHGfwTIck7w1yH6Q5zUw==}
 
@@ -13242,6 +13251,22 @@ snapshots:
       - typescript
       - vue
 
+  zova-module-a-zova@5.1.82(typescript@5.9.3)(vue@3.5.39(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.39(typescript@5.9.3))
+      '@cabloy/word-utils': 2.1.14
+      defu: 6.1.7
+      luxon: 3.7.2
+      zova-jsx: 1.1.67(typescript@5.9.3)
+    transitivePeerDependencies:
+      - typescript
+      - vue
+
   zova-module-rest-resource@5.1.40: {}
 
   zova-suite-a-zova@5.1.117(typescript@5.9.3)(vue@3.5.39(typescript@5.9.3)):
@@ -13278,6 +13303,40 @@ snapshots:
       - typescript
       - vue
 
+  zova-suite-a-zova@5.1.118(typescript@5.9.3)(vue@3.5.39(typescript@5.9.3)):
+    dependencies:
+      zova-module-a-api: 5.1.21
+      zova-module-a-app: 5.1.24
+      zova-module-a-bean: 5.1.31
+      zova-module-a-behavior: 5.1.25
+      zova-module-a-behaviors: 5.1.21
+      zova-module-a-boundary: 5.1.21
+      zova-module-a-command: 5.1.33
+      zova-module-a-fetch: 5.1.23
+      zova-module-a-form: 5.1.43(vue@3.5.39(typescript@5.9.3))
+      zova-module-a-icon: 5.1.26
+      zova-module-a-interceptor: 5.1.29
+      zova-module-a-logger: 5.1.26
+      zova-module-a-meta: 5.1.21
+      zova-module-a-model: 5.1.30(vue@3.5.39(typescript@5.9.3))
+      zova-module-a-openapi: 5.1.41
+      zova-module-a-router: 5.1.29
+      zova-module-a-routerstack: 5.1.26
+      zova-module-a-routertabs: 5.1.32
+      zova-module-a-ssr: 5.1.26
+      zova-module-a-ssrhmr: 5.1.22
+      zova-module-a-ssrserver: 5.1.22
+      zova-module-a-style: 5.1.32
+      zova-module-a-table: 5.1.37(vue@3.5.39(typescript@5.9.3))
+      zova-module-a-zod: 5.1.34
+      zova-module-a-zova: 5.1.82(typescript@5.9.3)(vue@3.5.39(typescript@5.9.3))
+    transitivePeerDependencies:
+      - '@vue/composition-api'
+      - debug
+      - supports-color
+      - typescript
+      - vue
+
   zova@5.1.118(typescript@5.9.3)(vue@3.5.39(typescript@5.9.3)):
     dependencies:
       zova-core: 5.1.61(patch_hash=0f4164c4d2bbb16d671beb5c26759dff37769be0709df941bc7b90b94261ac54)(typescript@5.9.3)
@@ -13289,6 +13348,17 @@ snapshots:
       - typescript
       - vue
 
+  zova@5.1.119(typescript@5.9.3)(vue@3.5.39(typescript@5.9.3)):
+    dependencies:
+      zova-core: 5.1.61(patch_hash=0f4164c4d2bbb16d671beb5c26759dff37769be0709df941bc7b90b94261ac54)(typescript@5.9.3)
+      zova-suite-a-zova: 5.1.118(typescript@5.9.3)(vue@3.5.39(typescript@5.9.3))
+    transitivePeerDependencies:
+      - '@vue/composition-api'
+      - debug
+      - supports-color
+      - typescript
+      - vue
+
   zwitch@1.0.5: {}
 
   zwitch@2.0.4: {}

package/zova/pnpm-lock.yaml

@@ -74,7 +74,7 @@ importers:
         version: 10.5.1(postcss@8.5.15)
       axios:
         specifier: ^1.16.1
-        version: 1.18.1
+        version: 1.18.1(supports-color@10.2.2)
       compression:
         specifier: ^1.8.1
         version: 1.8.1
@@ -308,8 +308,8 @@ importers:
         version: link:src/suite/a-training/modules/training-student
     devDependencies:
       '@cabloy/cli':
-        specifier: ^3.1.26
-        version: 3.1.26(vue@3.5.38(typescript@5.9.3))
+        specifier: ^3.1.27
+        version: 3.1.27(vue@3.5.38(typescript@5.9.3))
       '@cabloy/lint':
         specifier: ^5.1.27
         version: 5.1.30(@typescript-eslint/eslint-plugin@8.62.0(@typescript-eslint/parser@8.62.0(eslint@10.5.0(jiti@2.7.0))(typescript@5.9.3))(eslint@10.5.0(jiti@2.7.0))(typescript@5.9.3))(@typescript-eslint/rule-tester@8.62.0(eslint@10.5.0(jiti@2.7.0))(typescript@5.9.3))(@typescript-eslint/typescript-estree@8.62.0(typescript@5.9.3))(@typescript-eslint/utils@8.62.0(eslint@10.5.0(jiti@2.7.0))(typescript@5.9.3))(eslint@10.5.0(jiti@2.7.0))(oxfmt@0.45.0)(oxlint@1.71.0)(supports-color@10.2.2)(typescript@5.9.3)(vue-eslint-parser@10.4.1(eslint@10.5.0(jiti@2.7.0)))
@@ -383,8 +383,8 @@ importers:
   packages-cli/cli:
     dependencies:
       '@cabloy/cli':
-        specifier: ^3.1.26
-        version: 3.1.26(vue@3.5.38(typescript@5.9.3))
+        specifier: ^3.1.27
+        version: 3.1.27(vue@3.5.38(typescript@5.9.3))
       '@cabloy/process-helper':
         specifier: ^3.1.8
         version: 3.1.8
@@ -395,7 +395,7 @@ importers:
         specifier: ^7.6.2
         version: 7.8.5
       zova-cli-set-front:
-        specifier: ^1.2.91
+        specifier: ^1.2.92
         version: link:../cli-set-front
     devDependencies:
       clean-package:
@@ -417,8 +417,8 @@ importers:
         specifier: ^7.28.6
         version: 7.29.7(@babel/core@7.29.7)
       '@cabloy/cli':
-        specifier: ^3.1.26
-        version: 3.1.26(vue@3.5.38(typescript@5.9.3))
+        specifier: ^3.1.27
+        version: 3.1.27(vue@3.5.38(typescript@5.9.3))
       '@cabloy/extend':
         specifier: ^3.2.8
         version: 3.2.8
@@ -816,7 +816,7 @@ importers:
         specifier: ^5.1.61
         version: link:../zova-core
       zova-suite-a-zova:
-        specifier: ^5.1.117
+        specifier: ^5.1.118
         version: link:../../src/suite-vendor/a-zova
     devDependencies:
       clean-package:
@@ -1001,7 +1001,7 @@ importers:
         specifier: ^5.1.34
         version: link:modules/a-zod
       zova-module-a-zova:
-        specifier: ^5.1.81
+        specifier: ^5.1.82
         version: link:modules/a-zova
 
   src/suite-vendor/a-zova/modules/a-api:
@@ -1075,7 +1075,7 @@ importers:
     dependencies:
       axios:
         specifier: ^1.16.1
-        version: 1.18.1
+        version: 1.18.1(supports-color@10.2.2)
     devDependencies:
       clean-package:
         specifier: ^2.2.0
@@ -1344,8 +1344,8 @@ importers:
         version: link:../../../../../packages-utils/zova-jsx
     devDependencies:
       '@cabloy/cli':
-        specifier: ^3.1.26
-        version: 3.1.26(vue@3.5.38(typescript@5.9.3))
+        specifier: ^3.1.27
+        version: 3.1.27(vue@3.5.38(typescript@5.9.3))
       '@types/luxon':
         specifier: ^3.7.1
         version: 3.7.2
@@ -1961,8 +1961,8 @@ packages:
   '@bufbuild/protobuf@2.12.1':
     resolution: {integrity: sha512-BvAMfS6LrgZiryOAZ4pBYucu4wG/Ei/9o9DZ9akbREnMLbPJiom2i8b9C8IsKErQoiKqVhrerzt3kOT/RrzLHg==}
 
-  '@cabloy/cli@3.1.26':
-    resolution: {integrity: sha512-EPE7N3GDbPiimWPO/pdZ06ZWFlZm2gdtgb7mZ5my2Jgakw0Zp9Zt1aDyHx8il/nO6sHzzsESfbHC2/lXXpENTw==}
+  '@cabloy/cli@3.1.27':
+    resolution: {integrity: sha512-KMNKh6AbkxfgWx4+HL5ufDEInVdx11k8mIXLL55LMChA4h0dkwQ4z7CReSr4sDXs0jW2nGxgAdi7xjVzn8yZnw==}
 
   '@cabloy/compose@2.1.8':
     resolution: {integrity: sha512-TdEr9BY54BYoIlTjkrOKkzK8yJWmP07OrRTh4punJMnWzM+oDExQ2EGCGAHXnEHjLWqdhyMGm/ejmxnVgBmraQ==}
@@ -8189,7 +8189,7 @@ snapshots:
 
   '@bufbuild/protobuf@2.12.1': {}
 
-  '@cabloy/cli@3.1.26(vue@3.5.38(typescript@5.9.3))':
+  '@cabloy/cli@3.1.27(vue@3.5.38(typescript@5.9.3))':
     dependencies:
       '@babel/parser': 7.29.7
       '@cabloy/module-glob': 5.3.16
@@ -10252,7 +10252,7 @@ snapshots:
 
   acorn@8.17.0: {}
 
-  agent-base@6.0.2:
+  agent-base@6.0.2(supports-color@10.2.2):
     dependencies:
       debug: 4.4.3(supports-color@10.2.2)
     transitivePeerDependencies:
@@ -10364,11 +10364,11 @@ snapshots:
     dependencies:
       possible-typed-array-names: 1.1.0
 
-  axios@1.18.1:
+  axios@1.18.1(supports-color@10.2.2):
     dependencies:
       follow-redirects: 1.16.0
       form-data: 4.0.6
-      https-proxy-agent: 5.0.1
+      https-proxy-agent: 5.0.1(supports-color@10.2.2)
       proxy-from-env: 2.1.0
     transitivePeerDependencies:
       - debug
@@ -11784,9 +11784,9 @@ snapshots:
       statuses: 2.0.2
       toidentifier: 1.0.1
 
-  https-proxy-agent@5.0.1:
+  https-proxy-agent@5.0.1(supports-color@10.2.2):
     dependencies:
-      agent-base: 6.0.2
+      agent-base: 6.0.2(supports-color@10.2.2)
       debug: 4.4.3(supports-color@10.2.2)
     transitivePeerDependencies:
       - supports-color