cabloy 5.1.69 → 5.1.71

package/CHANGELOG.md

@@ -1,5 +1,29 @@
 # Changelog
 
+## 5.1.71
+
+### Features
+
+- Improve CEL default value handling.
+- Update published functionality.
+
+### Improvements
+
+- Harden ignored-file handling in lint-staged.
+- Normalize `commandssync` metadata formatting.
+- Add a schema-driven field effects guide.
+
+## 5.1.70
+
+### Features
+
+- Improve CEL numeric formatting for training records.
+- Trigger `onEffect` callbacks for form fields.
+
+### Improvements
+
+- Add examples for CEL numeric formatting to the documentation.
+
 ## 5.1.69
 
 ### Features

package/cabloy-docs/.vitepress/config.mjs

@@ -422,6 +422,10 @@ export default defineConfig({
               text: 'Form Scene to Page Meta',
               link: '/frontend/form-scene-to-page-meta-guide',
             },
+            {
+              text: 'Schema-Driven Field Effects',
+              link: '/frontend/schema-driven-field-effects-guide',
+            },
             {
               text: 'Permission, formScene, and Action Visibility',
               link: '/frontend/permission-formscene-action-visibility-guide',

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

@@ -27,6 +27,26 @@ Use `$apiSchema` when the frontend needs to inspect what the backend contract sa
 
 That usually means the problem is shifting from “fetch data” to “use metadata to drive behavior.”
 
+## One practical metadata-driven expression example
+
+When schema-driven form or table rendering uses JSX/CEL evaluation, the runtime can resolve helper functions against the current scope.
+
+For example, frontend CEL expressions can now use `toFixed(value, precision)` to keep a numeric value at the desired precision:
+
+```text
+toFixed(getValue('price'), 2)
+```
+
+In the shared form/table CEL environment:
+
+- `toFixed(...)` returns a string with fixed decimal precision
+- `getValue(name)` reads the current field value or current row value from the active runtime scope
+- `getProperty(name)` reads the current schema property metadata from the active runtime scope
+
+That is useful when the backend contract already owns the field metadata and the frontend only needs a thin expression layer for schema-driven display behavior.
+
+If your next question is not only how expressions read schema-driven scope, but how backend-owned field metadata attaches live field-side behavior through `ZovaRender.onEffect(...)`, `ZovaEvent`, and command chains, continue with [Schema-Driven Field Effects Guide](/frontend/schema-driven-field-effects-guide).
+
 ## Read together with
 
 Use this page together with:

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

@@ -438,6 +438,8 @@ Why it matters:
 
 This is the clearest example that command beans can be scene-sensitive without fitting the resource-row patterns.
 
+If your next question is not only what this command bean does, but how backend field metadata, `ZovaRender.onEffect(...)`, `ZovaEvent`, and command chains cooperate to implement schema-driven form effects, continue with [Schema-Driven Field Effects Guide](/frontend/schema-driven-field-effects-guide).
+
 ### `basic-commandssync:log`
 
 Read:

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

@@ -34,6 +34,8 @@ If your next question is how these public APIs cooperate internally at runtime,
 
 If your next question is how `formScene` becomes `formMeta`, then `pageMeta`, and finally visible shell/tab state, continue with [Form Scene to Page Meta Guide](/frontend/form-scene-to-page-meta-guide).
 
+If your next question is how backend/entity schema metadata drives field-level reactive form behavior such as normalization, derived values, and field-to-field updates, continue with [Schema-Driven Field Effects Guide](/frontend/schema-driven-field-effects-guide).
+
 ## What you should learn first
 
 If you only remember one idea, remember this one:
@@ -64,6 +66,8 @@ That Student thread is a good specimen because it grows through the same path mo
 
 So as you read the code samples below, treat them as different stages of the same Student form rather than unrelated fragments.
 
+If your next question is not only how a schema-driven form renders, but how backend/entity field metadata can attach live field-to-field behavior such as normalization and derived-value updates, continue with [Schema-Driven Field Effects Guide](/frontend/schema-driven-field-effects-guide).
+
 ## Step 1: Choose the right form style
 
 Before writing code, choose which of these three styles matches your Student page.
@@ -308,6 +312,14 @@ Schema-driven rendering is a strong fit when:
 - frontend and backend should stay close to the same Student contract truth
 - you want to reduce duplicated Student field configuration
 
+A practical expression example is a schema-driven field display that formats a numeric value through CEL:
+
+```text
+toFixed(getValue('price'), 2)
+```
+
+In the shared form CEL scope, `getValue(name)` reads the current field value and `toFixed(...)` returns a string with fixed decimal precision.
+
 Read together with [API Schema Guide](/frontend/api-schema-guide).
 
 ## Step 6: Add validation

package/cabloy-docs/frontend/frontend-source-reading-roadmap.md

@@ -116,11 +116,13 @@ Start here when your question is about `ZForm`, `formMeta`, page-entry forms, or
 ### Focused deep dives
 
 - [Form Scene to Page Meta Guide](/frontend/form-scene-to-page-meta-guide)
+- [Schema-Driven Field Effects Guide](/frontend/schema-driven-field-effects-guide)
 
 ### Best next step
 
 - if the question is “how does form runtime work?” -> read [Zova Form Under the Hood](/frontend/zova-form-under-the-hood)
 - if the question is “how does `formScene` become shell-visible state?” -> read [Form Scene to Page Meta Guide](/frontend/form-scene-to-page-meta-guide)
+- if the question is “how does backend/schema metadata drive field-level reactive behavior?” -> read [Schema-Driven Field Effects Guide](/frontend/schema-driven-field-effects-guide)
 
 ## Topic cluster: resources and ModelResource
 

package/cabloy-docs/frontend/schema-driven-field-effects-guide.md

@@ -0,0 +1,252 @@
+# Schema-Driven Field Effects Guide
+
+This guide explains how schema-driven field effects work in current Cabloy Basic when backend-owned field metadata drives live frontend form behavior.
+
+Use this page when you want to understand questions such as:
+
+- how can a backend entity field drive frontend form behavior
+- what does `ZovaRender.onEffect(...)` actually attach to
+- how do `ZovaEvent` and `ZovaCommand` cooperate to update other fields
+- when should a derived-field rule live in schema metadata instead of page/controller logic
+- which files should I read first for schema-driven field reactivity
+
+Use this page together with:
+
+- [Form Guide](/frontend/form-guide)
+- [Zova Form Under the Hood](/frontend/zova-form-under-the-hood)
+- [Zova Form Source Reading Map](/frontend/zova-form-source-reading-map)
+- [API Schema Guide](/frontend/api-schema-guide)
+- [Command Scene Authoring](/frontend/command-scene-authoring)
+
+Use this page after [Form Guide](/frontend/form-guide) when your next question is not only how schema-driven forms render, but how backend-owned field metadata becomes live field-side behavior through `ZovaRender.onEffect(...)`, `ZovaEvent`, and command chains.
+
+## Why this page exists
+
+The current frontend docs already explain nearby pieces well:
+
+- [Form Guide](/frontend/form-guide) explains the public form authoring surface
+- [Zova Form Under the Hood](/frontend/zova-form-under-the-hood) explains the runtime cooperation among form controllers, field controllers, schema metadata, and behaviors
+- [Zova Form Source Reading Map](/frontend/zova-form-source-reading-map) explains which framework files to read next
+- [Command Scene Authoring](/frontend/command-scene-authoring) explains the built-in `command` scene and representative command beans
+- [API Schema Guide](/frontend/api-schema-guide) explains why schema metadata can drive frontend behavior
+
+What those pages do not isolate directly is one common cross-layer pattern:
+
+- backend entity metadata contributes frontend render metadata
+- field metadata attaches a field-side effect
+- the effect emits a declarative event/command chain
+- command beans write the result back into form state
+
+That is the gap this page fills.
+
+## The shortest accurate mental model
+
+A practical mental model is:
+
+1. backend entity or DTO schema owns the field metadata truth
+2. `ZovaRender.onEffect(...)` adds field-side frontend behavior to that metadata
+3. the form runtime turns that metadata into a live field render context
+4. a `ZovaEvent` executes one or more `ZovaCommand` nodes declaratively
+5. those commands read current field scope and write normalized or derived values back into the form
+
+That means a field effect in Zova is **schema-owned frontend behavior**, not only a page-local callback or ad hoc widget trick.
+
+## What this page is not
+
+This page is not:
+
+- a replacement for [Form Guide](/frontend/form-guide)
+- a full command-scene guide instead of [Command Scene Authoring](/frontend/command-scene-authoring)
+- a general page-workflow guide for routing, dialogs, submit flow, or page lifecycle orchestration
+- the separate `formScene -> formMeta -> pageMeta -> shell/tab state` bridge covered by [Form Scene to Page Meta Guide](/frontend/form-scene-to-page-meta-guide)
+
+Its job is narrower:
+
+- explain how schema-owned field metadata becomes live field-side behavior
+- clarify where `ZovaRender.onEffect(...)`, `ZovaEvent`, `ZovaCommand`, and form runtime each fit
+- give a short source-confirmed reading path for this pattern
+
+## A representative specimen
+
+A compact specimen lives in:
+
+```text
+vona/src/suite/a-training/modules/training-record/src/entity/record.tsx
+```
+
+The key pattern in that file is:
+
+- one shared `onEffectForAverageScore` event chain is declared once
+- `subjectCount` and `totalScore` both attach that same effect through `ZovaRender.onEffect(...)`
+- the effect first normalizes input through `basic-commandssync:expr`
+- the effect then writes the derived `averageScore` through `basic-commands:setValue`
+
+This specimen matters because it demonstrates three durable rules:
+
+1. one field effect can be reused by multiple driving fields
+2. normalization can happen before the derived-field writeback
+3. the derived-field rule stays declarative and schema-owned rather than being buried in one page-local method
+
+The business example is average score, but the reusable pattern is broader:
+
+- normalize one or more source fields
+- compute a small derived value
+- write that value back into form state through commands
+
+## Where each concept lives
+
+This topic becomes much easier to read once the layers are separated clearly.
+
+### 1. Entity or DTO field metadata owns schema truth
+
+In current Cabloy Basic authoring, backend-side schema definitions can carry frontend render metadata through `@Api.field(...)` and related helpers.
+
+That metadata is not only validation truth.
+It can also describe:
+
+- field order
+- render provider selection
+- scene-specific behavior
+- field-side effects
+
+For the surrounding metadata-driven model, also see [API Schema Guide](/frontend/api-schema-guide).
+
+### 2. `ZovaRender.onEffect(...)` attaches field-side behavior
+
+`ZovaRender.onEffect(...)` belongs on field render metadata.
+
+Its role is not to define a command bean and not to replace a page controller.
+Its role is to say:
+
+- when this field participates in runtime interaction
+- execute this declarative effect chain in the field runtime context
+
+That keeps the effect attached to the schema-owned field definition instead of scattering it across unrelated page code.
+
+### 3. `ZovaEvent` is the declarative event container
+
+`ZovaEvent` groups one or more command invocations into a small event pipeline.
+
+In this pattern, the important point is not JSX syntax by itself.
+The important point is that the field effect stays:
+
+- declarative
+- composable
+- command-oriented
+- readable as metadata-driven behavior rather than imperative widget code
+
+### 4. `ZovaCommand` nodes perform the concrete steps
+
+A `ZovaCommand` node names one concrete action.
+In the average-score specimen, two built-in command families matter:
+
+- `basic-commandssync:expr`
+- `basic-commands:setValue`
+
+`basic-commandssync:expr` is a small synchronous command bean that returns the evaluated expression result.
+A representative source file is:
+
+```text
+zova/src/suite/cabloy-basic/modules/basic-commandssync/src/bean/command.expr.tsx
+```
+
+`basic-commands:setValue` is the built-in form-field writeback command bean.
+A representative source file is:
+
+```text
+zova/src/suite/cabloy-basic/modules/basic-commands/src/bean/command.setValue.tsx
+```
+
+That `setValue` command is especially important because it checks `renderContext.$scene === 'formField'` and then updates the target field through the live form runtime.
+For the command-scene side of that story, see [Command Scene Authoring](/frontend/command-scene-authoring).
+
+### 5. The form runtime provides the live field scope
+
+The field effect does not run against a dead schema object.
+It runs inside the form runtime, where the field and form controllers provide live helpers such as current field scope and form-state mutation.
+
+That is why a schema-owned effect can still read current values and write derived values back into the active form.
+For the runtime side, see [Zova Form Under the Hood](/frontend/zova-form-under-the-hood) and [Zova Form Source Reading Map](/frontend/zova-form-source-reading-map).
+
+## When this pattern fits well
+
+This pattern fits best when the behavior is:
+
+- field-local or cross-field within one form
+- small enough to stay declarative
+- closely tied to schema-owned field semantics
+- useful across more than one page or runtime path that consumes the same schema truth
+
+Typical good fits include:
+
+- derived fields such as totals, labels, or averages
+- lightweight input normalization
+- small field-to-field synchronization rules
+- metadata-driven behavior that should travel with the backend contract
+
+## When page or controller logic fits better
+
+Do not force every interactive rule into field metadata.
+
+Prefer page/controller logic when the behavior is:
+
+- strongly tied to one page workflow
+- asynchronous or orchestration-heavy
+- dependent on routing, dialogs, or page lifecycle
+- too large or too stateful to stay readable as a field event chain
+
+A practical boundary is:
+
+- if the rule reads like a small schema-owned field behavior, prefer field effects
+- if the rule reads like a page workflow, prefer page/controller code
+
+## Source-confirmed reading path
+
+When reading this topic, use this order:
+
+1. `vona/src/suite/a-training/modules/training-record/src/entity/record.tsx`
+2. `zova/src/suite/cabloy-basic/modules/basic-commandssync/src/bean/command.expr.tsx`
+3. `zova/src/suite/cabloy-basic/modules/basic-commands/src/bean/command.setValue.tsx`
+4. `zova/src/suite-vendor/a-zova/modules/a-form/src/component/form/controller.tsx`
+5. `zova/src/suite-vendor/a-zova/modules/a-form/src/component/formField/controller.tsx`
+6. `zova/src/suite-vendor/a-zova/modules/a-form/src/types/formField.ts`
+
+That order moves from one business-facing specimen, to the effect commands themselves, to the form and field runtime that make the effect live.
+
+## Relationship to other guides
+
+Use these boundaries when choosing the next page:
+
+- if you want public form authoring first, read [Form Guide](/frontend/form-guide)
+- if you want general schema-driven metadata behavior, read [API Schema Guide](/frontend/api-schema-guide)
+- if you want deeper form runtime cooperation, read [Zova Form Under the Hood](/frontend/zova-form-under-the-hood)
+- if you want the shortest file-order map for form internals, read [Zova Form Source Reading Map](/frontend/zova-form-source-reading-map)
+- if you want the command-scene runtime model behind named commands, read [Command Scene Authoring](/frontend/command-scene-authoring)
+- if you want the separate `formScene -> formMeta -> pageMeta -> shell/tab state` bridge, read [Form Scene to Page Meta Guide](/frontend/form-scene-to-page-meta-guide)
+
+## Final takeaway
+
+The most accurate way to read schema-driven field effects in current Cabloy Basic is:
+
+- schema metadata owns the field-level behavior contract
+- `ZovaRender.onEffect(...)` attaches declarative field-side behavior
+- `ZovaEvent` and `ZovaCommand` execute the effect as a small command pipeline
+- form runtime scope makes the effect live
+- command beans write normalized or derived values back into the active form state
+
+That is the source-confirmed meaning of schema-driven field effects in the current frontend architecture.
+
+## Verification checklist
+
+When documenting or changing this area, verify in this order:
+
+1. confirm the specimen still matches the current `training-record` entity metadata
+2. confirm command claims still match `command.expr.tsx` and `command.setValue.tsx`
+3. confirm the runtime boundary still matches the current `a-form` form and form-field controllers
+4. build the docs site:
+
+   ```bash
+   npm run docs:build
+   ```
+
+5. verify the page is reachable from the frontend sidebar and related form/command guides

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

@@ -146,6 +146,14 @@ and more:
 
 This is why table work often belongs in the broader contract loop when the real source of truth is backend field metadata.
 
+A practical expression example is a schema-driven cell display that formats the current row value through CEL:
+
+```text
+toFixed(getValue('price'), 2)
+```
+
+In the shared table CEL scope, `getValue(name)` reads the current row value and `toFixed(...)` returns a string with fixed decimal precision.
+
 For the schema side of that contract, also see [API Schema Guide](/frontend/api-schema-guide).
 
 ## Step 4: Use built-in or custom `tableCell` render resources

package/cabloy-docs/frontend/zova-form-source-reading-map.md

@@ -249,6 +249,8 @@ Use this path when you are asking questions like:
 
 If your next question becomes how `formScene` becomes `formMeta`, then `pageMeta`, and finally visible shell/tab state, continue with [Form Scene to Page Meta Guide](/frontend/form-scene-to-page-meta-guide).
 
+If your next question becomes how backend/entity schema metadata attaches field-side effects through `ZovaRender.onEffect(...)` and command chains, continue with [Schema-Driven Field Effects Guide](/frontend/schema-driven-field-effects-guide).
+
 ## 8. Representative specimens to read before editing the framework
 
 Use this section when you want one small example before reading the framework internals.

package/cabloy-docs/frontend/zova-form-under-the-hood.md

@@ -18,6 +18,8 @@ If your next question is not “how does this runtime work?” but “which file
 
 If your next question is specifically how `formScene` flows into `formMeta`, then `pageMeta`, and finally shell/tab state, continue with [Form Scene to Page Meta Guide](/frontend/form-scene-to-page-meta-guide).
 
+If your next question is how backend/entity schema metadata attaches live field-side behavior through `ZovaRender.onEffect(...)`, `ZovaEvent`, and command chains, continue with [Schema-Driven Field Effects Guide](/frontend/schema-driven-field-effects-guide).
+
 > [!TIP]
 > **Zova Form docs path**
 >
@@ -94,6 +96,8 @@ That page shows:
 - a provider-level layout behavior override
 - a blank row used for action controls
 
+If you want a business-facing specimen where backend entity metadata attaches live field-side behavior through `ZovaRender.onEffect(...)`, `ZovaEvent`, and command chains, continue with [Schema-Driven Field Effects Guide](/frontend/schema-driven-field-effects-guide).
+
 The rest of this page explains how those public authoring shapes become real runtime behavior.
 
 ## The core source-reading path

package/lint-staged.config.mjs

@@ -1,3 +1,5 @@
+import { basename, isAbsolute, matchesGlob, relative, sep } from 'node:path';
+
 // Must stay in sync with oxfmt.config.ts ignorePatterns
 const OXFMT_IGNORE_PATTERNS = [
   // root original
@@ -40,53 +42,59 @@ const OXFMT_IGNORE_PATTERNS = [
   'zova/packages-cli/cli-set-front/cli/templates',
 ];
 
+function normalizeFilepath(filepath) {
+  const normalized = isAbsolute(filepath) ? relative(process.cwd(), filepath) : filepath;
+  return normalized.split(sep).join('/');
+}
+
+function matchesPathPattern(filepath, pattern) {
+  if (matchesGlob(filepath, pattern)) return true;
+  if (pattern.startsWith('**/')) {
+    const suffix = pattern.slice(3);
+    if (!/[*?]/.test(suffix)) {
+      return (
+        filepath === suffix || filepath.endsWith(`/${suffix}`) || filepath.includes(`/${suffix}/`)
+      );
+    }
+  }
+  if (!/[*?]/.test(pattern)) {
+    return filepath === pattern || filepath.startsWith(`${pattern}/`);
+  }
+  return false;
+}
+
 function isOxfmtIgnored(filepath) {
-  const parts = filepath.split('/');
-  const basename = parts.at(-1);
+  const normalized = normalizeFilepath(filepath);
+  const filename = basename(normalized);
   return OXFMT_IGNORE_PATTERNS.some(pattern => {
-    // basename-only patterns (e.g. *.min.js)
     if (!pattern.includes('/')) {
-      if (matchGlob(basename, pattern)) return true;
+      return matchesGlob(filename, pattern);
     }
-    // **/prefix patterns
-    if (pattern.startsWith('**/')) {
-      const suffix = pattern.slice(3);
-      for (let i = 0; i < parts.length; i++) {
-        if (matchGlob(parts[i], suffix)) return true;
-      }
-    }
-    // **/dir/** patterns
-    if (pattern.startsWith('**/') && pattern.endsWith('/**')) {
-      const dir = pattern.slice(3, -3);
-      if (parts.includes(dir)) return true;
-    }
-    // prefix/path patterns (no **)
-    if (!pattern.startsWith('**') && filepath.includes(pattern)) return true;
-    return false;
+    return matchesPathPattern(normalized, pattern);
   });
 }
 
-function matchGlob(name, pattern) {
-  const re = pattern
-    .replace(/[.+^${}()|[\]\\]/g, '\\$&')
-    .replace(/\*/g, '[^/]*')
-    .replace(/\?/g, '[^/]');
-  return new RegExp(`^${re}$`).test(name);
+function filterIgnored(filenames) {
+  return filenames.filter(filename => !isOxfmtIgnored(filename));
+}
+
+function joinShellArgs(filenames) {
+  return filenames.map(filename => JSON.stringify(filename)).join(' ');
 }
 
-function filterIgnored(filenames) {
-  return filenames.filter(f => !isOxfmtIgnored(f));
+function createOxfmtCommand(filenames) {
+  return `node scripts/run-oxfmt-safe.mjs ${joinShellArgs(filenames)}`;
 }
 
 export default {
   '*.{js,jsx,ts,tsx,vue,mjs,cjs}': filenames => {
     const filtered = filterIgnored(filenames);
     if (filtered.length === 0) return [];
-    return ['npm run lint:fix', `npm run format:fix -- ${filtered.join(' ')}`];
+    return ['npm run lint:fix', createOxfmtCommand(filtered)];
   },
   '*.{json,yaml,yml,md,css,scss,html}': filenames => {
     const filtered = filterIgnored(filenames);
     if (filtered.length === 0) return [];
-    return [`npm run format:fix -- ${filtered.join(' ')}`];
+    return [createOxfmtCommand(filtered)];
   },
 };

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "cabloy",
-  "version": "5.1.69",
+  "version": "5.1.71",
   "gitHead": "2c5c19284bab738e492856189acb6fad74b8a7b7",
   "description": "A Node.js fullstack framework",
   "keywords": [
@@ -82,5 +82,5 @@
   "engines": {
     "node": ">=24.4.0"
   },
-  "packageManager": "pnpm@11.5.2"
+  "packageManager": "pnpm@11.9.0"
 }

package/scripts/run-oxfmt-safe.mjs

@@ -0,0 +1,53 @@
+import { spawnSync } from 'node:child_process';
+
+const NO_TARGETS_MESSAGE =
+  'Expected at least one target file. All matched files may have been excluded by ignore rules.';
+
+function stripNoTargetsMessage(output) {
+  return output
+    .split('\n')
+    .filter(line => !line.includes(NO_TARGETS_MESSAGE))
+    .join('\n')
+    .trimEnd();
+}
+
+function writeOutput(stream, output) {
+  if (output) {
+    stream.write(output);
+  }
+}
+
+const filenames = process.argv.slice(2);
+if (filenames.length === 0) {
+  process.exit(0);
+}
+
+const result = spawnSync('pnpm', ['exec', 'oxfmt', '--write', ...filenames], {
+  encoding: 'utf8',
+  stdio: 'pipe',
+});
+
+if (result.error) {
+  throw result.error;
+}
+
+const stdout = result.stdout ?? '';
+const stderr = result.stderr ?? '';
+if (result.status === 0) {
+  writeOutput(process.stdout, stdout);
+  writeOutput(process.stderr, stderr);
+  process.exit(0);
+}
+
+const combinedOutput = `${stdout}\n${stderr}`;
+if (combinedOutput.includes(NO_TARGETS_MESSAGE)) {
+  const cleanStdout = stripNoTargetsMessage(stdout);
+  const cleanStderr = stripNoTargetsMessage(stderr);
+  writeOutput(process.stdout, cleanStdout ? `${cleanStdout}\n` : '');
+  writeOutput(process.stderr, cleanStderr ? `${cleanStderr}\n` : '');
+  process.exit(0);
+}
+
+writeOutput(process.stdout, stdout);
+writeOutput(process.stderr, stderr);
+process.exit(result.status ?? 1);

package/vona/packages-cli/cabloy-cli/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@cabloy/cli",
-  "version": "3.1.23",
+  "version": "3.1.25",
   "gitHead": "a79189b882c17af5911573896a781bbb0046d37d",
   "description": "@cabloy/cli",
   "keywords": [

package/vona/packages-cli/cli/package.json

@@ -1,6 +1,6 @@
 {
   "name": "vona-cli",
-  "version": "1.1.120",
+  "version": "1.1.122",
   "gitHead": "a79189b882c17af5911573896a781bbb0046d37d",
   "description": "vona cli",
   "keywords": [

package/vona/packages-cli/cli-set-api/package.json

@@ -1,6 +1,6 @@
 {
   "name": "vona-cli-set-api",
-  "version": "1.1.118",
+  "version": "1.1.120",
   "gitHead": "a79189b882c17af5911573896a781bbb0046d37d",
   "description": "vona cli-set-api",
   "keywords": [

package/vona/packages-utils/module-glob/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@cabloy/module-glob",
-  "version": "5.3.13",
+  "version": "5.3.15",
   "gitHead": "a79189b882c17af5911573896a781bbb0046d37d",
   "description": "cabloy module-glob",
   "keywords": [

package/vona/packages-utils/utils/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@cabloy/utils",
-  "version": "2.1.22",
+  "version": "2.1.24",
   "gitHead": "a79189b882c17af5911573896a781bbb0046d37d",
   "description": "cabloy utils",
   "keywords": [