cabloy 5.1.50 → 5.1.51

package/cabloy-docs/reference/backend-directory-structure.md

@@ -0,0 +1,88 @@
+# Backend Directory Structure
+
+This page gives a compact reference view of the backend tree under `vona/`.
+
+## Why this page exists
+
+The package map explains the architectural meaning of package, module, and suite boundaries.
+
+This page complements that by showing the practical backend tree layout used in the Cabloy repository.
+
+## Simplified backend tree
+
+Representative backend structure:
+
+```text
+vona/
+├── packages-cli/
+├── packages-utils/
+├── packages-vona/
+└── src/
+   ├── module/
+   ├── module-vendor/
+   ├── suite/
+   └── suite-vendor/
+```
+
+## Meaning of the main directories
+
+| Path                      | Meaning                                  |
+| ------------------------- | ---------------------------------------- |
+| `vona/packages-cli/`      | Vona CLI entrypoints and command sets    |
+| `vona/packages-utils/`    | shared backend-side utilities            |
+| `vona/packages-vona/`     | framework packages                       |
+| `vona/src/module/`        | first-party standalone modules           |
+| `vona/src/module-vendor/` | vendor-provided standalone modules       |
+| `vona/src/suite/`         | first-party suites and their modules     |
+| `vona/src/suite-vendor/`  | vendor-provided suites and their modules |
+
+## Project-level backend areas
+
+Within the backend application layer, contributors should also know these practical areas:
+
+| Path                       | Meaning                                            |
+| -------------------------- | -------------------------------------------------- |
+| `vona/env/`                | backend env files and runtime configuration inputs |
+| `vona/src/backend/config/` | project-level backend config and locale overrides  |
+| `vona/src/backend/typing/` | project-level backend type definitions             |
+| `vona/src/backend/play/`   | backend playground-oriented verification assets    |
+
+## Practical development reading of the tree
+
+A useful rule is:
+
+- start in `vona/src/module/` when the work belongs to a standalone module
+- start in `vona/src/suite/` when the work belongs to a suite-composed business area
+- inspect `vona/packages-cli/` when the task is about command discovery or generation behavior
+- inspect `vona/src/backend/config/` when the task is about project-level config overrides rather than module-local defaults
+
+A practical generator-oriented reading is:
+
+- `:create:module` and `:create:suite` choose the structural target first
+- `:create:bean` then places scene-based resources under the chosen module
+- initializer commands such as `:init:constant`, `:init:types`, and `:init:asset` create module-scope resource files rather than ordinary bean-scene classes
+
+## Relationship to other reference pages
+
+Read this page together with:
+
+- [Package Map](/reference/package-map)
+- [Backend Essentials](/backend/backend-essentials)
+- [Backend CLI](/backend/cli)
+- [Backend Scripts](/backend/scripts)
+
+A practical split is:
+
+- [Backend (Vona)](/backend/introduction) is the broader backend hub
+- [Package Map](/reference/package-map) explains architecture boundaries and package metadata
+- this page explains the practical directory tree contributors navigate
+
+## Implementation checks for backend file-location changes
+
+When changing backend code, ask:
+
+1. does this change belong to a standalone module, a suite-contained module, or project-level backend config?
+2. is the task about generation behavior under `packages-cli/` or runtime behavior under `src/`?
+3. should the example use a module path, a suite path, or a project-level backend path?
+
+That helps keep backend file references aligned with the actual monorepo layout.

package/cabloy-docs/reference/cli-reference.md

@@ -0,0 +1,49 @@
+# CLI Reference
+
+This page is the compact reference layer for the two main command entrypoints.
+
+## Vona
+
+Entry from repo root:
+
+```bash
+npm run vona :
+npm run vona :create
+npm run vona :tools
+```
+
+Primary command families:
+
+- `bin:*`
+- `create:*`
+- `init:*`
+- `tools:*`
+
+## Zova
+
+Entry from repo root:
+
+```bash
+npm run zova :
+npm run zova :create
+npm run zova :refactor
+```
+
+Primary command families:
+
+- `bin:*`
+- `create:*`
+- `init:*`
+- `refactor:*`
+- `tools:*`
+- `openapi:*`
+
+## Workflow guidance for docs, skills, and rules
+
+When creating docs, skills, or rules, use the CLI family names as the public mental model first. Only drop to file-level implementation details when the command surface is insufficient.
+
+Use this page together with:
+
+- [Backend Quickstart](/backend/quickstart)
+- [Frontend (Zova)](/frontend/introduction)
+- [Backend OpenAPI to Frontend SDK](/fullstack/openapi-to-sdk)

package/cabloy-docs/reference/glossary.md

@@ -0,0 +1,38 @@
+# Glossary
+
+## Cabloy
+
+The fullstack framework and monorepo direction that combines backend and frontend workflows.
+
+## Vona
+
+The backend framework in the Cabloy ecosystem.
+
+## Zova
+
+The frontend framework in the Cabloy ecosystem.
+
+## Cabloy Basic
+
+The public reference repository for the shared Cabloy architecture.
+
+## Cabloy Start
+
+A private sibling repository with different UI and module choices, provided as a value-add edition.
+
+## Edition detection
+
+The process of identifying whether the current repo is Cabloy Basic or Cabloy Start before choosing a workflow, example, or skill branch.
+
+## CLI-first
+
+The practice of using existing Vona and Zova command families before attempting manual scaffolding or refactor work.
+
+## Read next
+
+Use the glossary together with:
+
+- [Fullstack Introduction](/fullstack/introduction)
+- [Backend (Vona)](/backend/introduction)
+- [Frontend (Zova)](/frontend/introduction)
+- [Package Map](/reference/package-map)

package/cabloy-docs/reference/package-map.md

@@ -0,0 +1,105 @@
+# Package Map
+
+This monorepo is organized around a small set of stable top-level areas.
+
+## Root
+
+- `package.json` — shared scripts and release entrypoints
+- `lerna.json` — package topology
+- `.docs-internal/` — internal engineering docs
+- `.claude/` — Claude commands, skills, and local settings
+- `cabloy-docs/` — unified public docs
+
+## Backend side
+
+- `vona/packages-cli/` — Vona CLI and command sets
+- `vona/packages-utils/` — shared utilities
+- `vona/packages-vona/` — framework packages
+- `vona/src/module/` — first-party Vona modules
+- `vona/src/module-vendor/` — vendor-provided modules
+- `vona/src/suite/` — first-party suites and their modules
+- `vona/src/suite-vendor/` — vendor-provided suites and their modules
+
+A useful structural rule is:
+
+- **package** is the publishable/package-metadata unit
+- **module** is the main backend capability unit
+- **suite** is the composition unit that groups modules into a larger architecture surface
+
+## Representative backend package metadata
+
+Representative package metadata in the current repo shows the distinction clearly.
+
+### Module package
+
+Example: `vona/src/module/demo-student/package.json`
+
+- package name: `vona-module-demo-student`
+- title: `demo-student`
+- `vonaModule.dependencies` records module-level framework dependencies
+
+### Suite package
+
+Example: `vona/src/suite/a-demo/package.json`
+
+- package name: `vona-suite-a-demo`
+- title: `a-demo`
+- `dependencies` declare which module packages the suite composes
+
+### Suite-contained module package
+
+Example: `vona/src/suite/a-demo/modules/demo-basic/package.json`
+
+- package name: `vona-module-demo-basic`
+- title: `demo-basic`
+- `vonaModule.dependencies` still expresses module-level dependencies even when the module lives under a suite
+
+This matters because Vona modularization is not just folder layout. Package metadata participates in dependency declarations and architecture boundaries.
+
+## Practical modularization edge table
+
+| Unit    | Main role                             | Where dependency intent is usually expressed                         |
+| ------- | ------------------------------------- | -------------------------------------------------------------------- |
+| Package | metadata and publication unit         | package-level `dependencies`, scripts, exports, and release metadata |
+| Module  | main backend capability unit          | `vonaModule.dependencies` for framework/module dependency intent     |
+| Suite   | composition unit for multiple modules | normal package `dependencies` that compose module packages           |
+
+A practical comparison is:
+
+- a standalone module package still uses `vonaModule.dependencies` to describe backend framework/module dependency intent
+- a suite package uses ordinary package `dependencies` to compose the module packages it contains or depends on
+- a suite-contained module still remains a module package with its own `vonaModule.dependencies`
+
+## How this relates to backend docs
+
+Use this package map together with:
+
+- [Backend Essentials](/backend/backend-essentials)
+- [Backend Foundation](/backend/foundation)
+- [Backend CLI](/backend/cli)
+- [Backend Scripts](/backend/scripts)
+- [Backend Directory Structure](/reference/backend-directory-structure)
+
+A practical split is:
+
+- the backend essentials pages explain the architecture model
+- this page grounds that model in the real monorepo layout
+
+For the broader backend entry path, also see [Backend (Vona)](/backend/introduction).
+
+## Frontend side
+
+- `zova/packages-cli/` — Zova CLI and command sets
+- `zova/packages-utils/` — shared utilities
+- `zova/packages-zova/` — framework packages
+- `zova/src/` — modules, suites, and vendor source
+
+For the frontend architectural meaning of modules, suites, scope-driven resources, and runtime/startup structure, see `/frontend/modules-and-suites`, `/frontend/module-scope`, `/frontend/ioc-and-beans`, `/frontend/environment-config-guide`, `/frontend/app-startup-guide`, and `/frontend/system-startup-guide`.
+
+## Sibling edition
+
+- `cabloy-start` is a separate sibling repository, not a subdirectory of this monorepo.
+
+### Maintainer note for cross-repo guidance
+
+When maintaining docs, skills, or rules that refer to Cabloy Start, keep the cross-repo guidance conceptually aligned with the system documented here.

package/cabloy-docs/reference/repo-scripts.md

@@ -0,0 +1,36 @@
+# Repo Scripts
+
+The root `package.json` is the first reference point for shared monorepo workflows.
+
+## Current shared entrypoints in Cabloy Basic
+
+- `npm run init`
+- `npm run vona`
+- `npm run zova`
+- `npm run dev`
+- `npm run dev:zova:admin`
+- `npm run dev:zova:web`
+- `npm run build`
+- `npm run build:zova`
+- `npm run start`
+- `npm run test`
+- `npm run tsc`
+- `npm run docs:dev`
+- `npm run docs:build`
+- `npm run docs:preview`
+
+## Edition-sensitive note
+
+Cabloy Start keeps the same high-level pattern while using different frontend flavors such as `cabloyStartAdmin` and `cabloyStartWeb`.
+
+### Documentation and automation guidance
+
+When documenting or automating flavor-specific commands, always confirm the active repo first.
+
+## Read together with
+
+Use this page together with:
+
+- [Backend Quickstart](/backend/quickstart)
+- [Runtime and Flavors](/backend/runtime-and-flavors)
+- [CLI Reference](/reference/cli-reference)

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "cabloy",
-  "version": "5.1.50",
+  "version": "5.1.51",
   "gitHead": "2c5c19284bab738e492856189acb6fad74b8a7b7",
   "description": "A Node.js fullstack framework",
   "keywords": [
@@ -41,6 +41,9 @@
     "format:fix": "oxfmt --write",
     "lint": "oxlint",
     "lint:fix": "oxlint --fix",
+    "docs:dev": "pnpm --dir cabloy-docs docs:dev",
+    "docs:build": "pnpm --dir cabloy-docs docs:build",
+    "docs:preview": "pnpm --dir cabloy-docs docs:preview",
     "docs:fix": "textlint --fix ./cabloy-docs/**/*.md",
     "release-patch": "node scripts/release.ts patch",
     "release-minor": "node scripts/release.ts minor",

package/scripts/init.ts

@@ -17,6 +17,7 @@ const __dirname = dirname(fileURLToPath(import.meta.url));
 const ROOT_DIR = resolve(__dirname, '..');
 const VONA_DIR = resolve(ROOT_DIR, 'vona');
 const ZOVA_DIR = resolve(ROOT_DIR, 'zova');
+const CABLOY_DOCS_DIR = resolve(ROOT_DIR, 'cabloy-docs');
 
 // --- Helpers ---
 
@@ -202,6 +203,16 @@ function cleanupWorkspaceYaml(): void {
   }
 }
 
+// --- Step G: init:cabloy-docs ---
+
+function initCabloyDocs(): void {
+  const pkgPath = resolve(CABLOY_DOCS_DIR, 'package.json');
+  if (!existsSync(pkgPath)) return;
+  // eslint-disable-next-line
+  console.log('[init] Initializing cabloy-docs...');
+  exec('pnpm install --no-frozen-lockfile', CABLOY_DOCS_DIR);
+}
+
 // --- Main ---
 
 setAppName();
@@ -210,6 +221,7 @@ generateEnvProdDockerLocal();
 cleanupWorkspaceYaml();
 initVona();
 initZova();
+initCabloyDocs();
 buildSsrCabloyBasicStartBatch();
 // eslint-disable-next-line
 console.log('[init] Done!');

package/scripts/upgrade.ts

@@ -14,10 +14,11 @@ const TEMP_DIR = resolve(ROOT_DIR, 'node_modules/.cabloy-upgrade');
 
 // --- Whitelist ---
 
-const WHITELIST_DIRS: string[] = [
+const OVERWRITE_DIRS: string[] = [
   // root
   'scripts',
   '.husky',
+  'cabloy-docs',
   // vona
   'vona/packages-vona',
   'vona/packages-cli',
@@ -36,6 +37,12 @@ const WHITELIST_DIRS: string[] = [
   'zova/scripts',
 ];
 
+const MERGE_DIRS: string[] = [
+  // Claude project assets
+  '.claude/commands',
+  '.claude/skills',
+];
+
 const BLACKLIST_DIRS: string[] = [
   // vona
   'vona/src/suite-vendor/a-test',
@@ -43,6 +50,7 @@ const BLACKLIST_DIRS: string[] = [
 
 const WHITELIST_FILES: string[] = [
   // root
+  'CLAUDE.md',
   'tsconfig.json',
   'tsconfig.base.json',
   'tsconfig.base.esm.json',
@@ -79,6 +87,14 @@ function exec(cmd: string): void {
   execSync(cmd, { stdio: 'inherit', cwd: ROOT_DIR });
 }
 
+function shouldCopyPath(path: string): boolean {
+  return !path.includes('.DS_Store');
+}
+
+function copyDirectory(src: string, dest: string): void {
+  cpSync(src, dest, { recursive: true, filter: shouldCopyPath });
+}
+
 async function extractTarball(tarballPath: string, targetDir: string): Promise<void> {
   rmSync(targetDir, { recursive: true, force: true });
   mkdirSync(targetDir, { recursive: true });
@@ -145,7 +161,7 @@ async function downloadAndExtract(): Promise<void> {
 
 function selectiveOverwrite(dryRun?: boolean): void {
   // Overwrite directories
-  for (const dir of WHITELIST_DIRS) {
+  for (const dir of OVERWRITE_DIRS) {
     const src = resolve(TEMP_DIR, dir);
     const dest = resolve(ROOT_DIR, dir);
     if (!existsSync(src)) continue;
@@ -156,7 +172,19 @@ function selectiveOverwrite(dryRun?: boolean): void {
     if (existsSync(dest)) {
       rmSync(dest, { recursive: true, force: true });
     }
-    cpSync(src, dest, { recursive: true, filter: src => !src.includes('.DS_Store') });
+    copyDirectory(src, dest);
+  }
+
+  // Merge directories
+  for (const dir of MERGE_DIRS) {
+    const src = resolve(TEMP_DIR, dir);
+    const dest = resolve(ROOT_DIR, dir);
+    if (!existsSync(src)) continue;
+    if (dryRun) {
+      log(`  [dry-run] Merge directory: ${dir}`);
+      continue;
+    }
+    copyDirectory(src, dest);
   }
 
   // Delete directories

package/vona/README.md

@@ -2,7 +2,7 @@ English | [简体中文](./README.zh-CN.md)
 
 # Vona
 
-Vona is a fullstack framework for building SSR/SPA/Website/Admin in one codebase, featuring frontend and backend separation and native type sharing
+Vona is a fullstack framework for building SSR/SPA/Web/Admin in one codebase, featuring frontend and backend separation and native type sharing
 
 - Supports dual-layer tabs navigation, enabling efficient page switching while maintaining page state
 - Dynamically render CRUD list pages, entry pages, and search forms, while demonstrating best practices for Tanstack Table, Tanstack Form, and Tanstack Query
@@ -37,9 +37,9 @@ Frontend-backend type sharing mechanism:
 
 ## Demo Online
 
-The Website and Admin of Cabloy Store are built by one codebase
+The Web and Admin of Cabloy Store are built by one codebase
 
-- Website: [https://cabloy.com](https://cabloy.com)
+- Web: [https://cabloy.com](https://cabloy.com)
 - Admin: [https://cabloy.com/admin](https://cabloy.com/admin)
 
 ## GIF Demo

package/vona/README.zh-CN.md

@@ -2,7 +2,7 @@
 
 # Vona 是什么
 
-Vona 是一款全栈框架，支持单代码库构建`SSR/SPA/Web网站/Admin中后台`，采用前后端分离架构，并内置前后端类型共享能力
+Vona 是一款全栈框架，支持单代码库构建`SSR/SPA/Web/Admin`，采用前后端分离架构，并内置前后端类型共享能力
 
 - 提供 DTO 动态推断与生成能力，减少重复的类型定义工作，提升开发效率
 - 支持双层页签导航，实现高效页面切换，并保持页面状态
@@ -37,10 +37,10 @@ Vona 采用前后端分离的架构。前端使用 Zova 框架，将构建生成
 
 ## 在线演示
 
-使用同一套代码实现 Cabloy Store 的`Web网站`和`Admin中后台`
+使用同一套代码实现 Cabloy Store 的`Web`和`Admin`
 
-- Web 网站：[https://cabloy.com](https://cabloy.com)
-- Admin 中后台：[https://cabloy.com/admin](https://cabloy.com/admin)
+- Web：[https://cabloy.com](https://cabloy.com)
+- Admin：[https://cabloy.com/admin](https://cabloy.com/admin)
 
 ## 动图演示
 

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

@@ -1,6 +1,6 @@
 {
   "name": "vona",
-  "version": "5.1.40",
+  "version": "5.1.41",
   "gitHead": "a79189b882c17af5911573896a781bbb0046d37d",
   "description": "Vona is an intuitive, elegant and powerful Node.js framework for rapidly developing enterprise applications of any size",
   "keywords": [

package/vona/src/suite-vendor/a-cabloy/modules/a-datasharding/package.json

@@ -1,6 +1,6 @@
 {
   "name": "vona-module-a-datasharding",
-  "version": "5.1.5",
+  "version": "5.1.6",
   "gitHead": "a79189b882c17af5911573896a781bbb0046d37d",
   "description": "",
   "keywords": [

package/vona/src/suite-vendor/a-cabloy/modules/a-datasharding/src/bean/summerCache.datasourceWrite.ts

@@ -1,7 +1,7 @@
 import type { TableIdentity } from 'table-identity';
 import type { IDatabaseClientRecord } from 'vona-module-a-orm';
 
-import { BeanSummerCacheBase, SummerCache } from 'vona-module-a-summer';
+import { ServiceSummerCacheBase, SummerCache } from 'vona-module-a-summer';
 
 export type TSummerCacheDatasourceWriteKey = TableIdentity;
 export type TSummerCacheDatasourceWriteData = keyof IDatabaseClientRecord;
@@ -14,7 +14,7 @@ export type TSummerCacheDatasourceWriteData = keyof IDatabaseClientRecord;
     ttl: 3 * 1000, // 3s
   },
 })
-export class SummerCacheDatasourceWrite extends BeanSummerCacheBase<
+export class SummerCacheDatasourceWrite extends ServiceSummerCacheBase<
   TSummerCacheDatasourceWriteKey,
   TSummerCacheDatasourceWriteData
 > {}

package/vona/src/suite-vendor/a-cabloy/package.json

@@ -1,6 +1,6 @@
 {
   "name": "vona-suite-a-cabloy",
-  "version": "5.1.28",
+  "version": "5.1.29",
   "gitHead": "a79189b882c17af5911573896a781bbb0046d37d",
   "description": "",
   "author": "",

package/vona/src/suite-vendor/a-captcha/modules/a-captcha/package.json

@@ -1,6 +1,6 @@
 {
   "name": "vona-module-a-captcha",
-  "version": "5.1.6",
+  "version": "5.1.7",
   "gitHead": "a79189b882c17af5911573896a781bbb0046d37d",
   "description": "",
   "keywords": [

package/vona/src/suite-vendor/a-captcha/modules/a-captcha/src/bean/cacheRedis.captcha.ts

@@ -1,4 +1,4 @@
-import { BeanCacheRedisBase, CacheRedis } from 'vona-module-a-cache';
+import { ServiceCacheRedisBase, CacheRedis } from 'vona-module-a-cache';
 
 import type { ICaptchaDataCache } from '../types/captcha.ts';
 
@@ -6,7 +6,7 @@ export type TCacheRedisCaptchaKey = string;
 export type TCacheRedisCaptchaData = ICaptchaDataCache;
 
 @CacheRedis({ disableTransactionCompensate: true })
-export class CacheRedisCaptcha extends BeanCacheRedisBase<
+export class CacheRedisCaptcha extends ServiceCacheRedisBase<
   TCacheRedisCaptchaKey,
   TCacheRedisCaptchaData
 > {}

package/vona/src/suite-vendor/a-captcha/package.json

@@ -1,6 +1,6 @@
 {
   "name": "vona-suite-a-captcha",
-  "version": "5.1.10",
+  "version": "5.1.11",
   "gitHead": "a79189b882c17af5911573896a781bbb0046d37d",
   "description": "",
   "author": "",

package/vona/src/suite-vendor/a-vona/modules/a-bean/cli/bean/metadata/generate.ts

@@ -5,20 +5,19 @@ export default async function (options: IMetadataCustomGenerateOptions): Promise
   const contentImports: string[] = [];
   const contentRecordsGlobal: string[] = [];
   for (const globFile of globFiles) {
-    const { className, beanName, fileNameJSRelative, isIgnore, isVirtual } = globFile;
-    if (isIgnore || isVirtual) continue;
-    const beanFullName = beanName;
+    const { className, beanName, fileNameJSRelative, isIgnore } = globFile;
+    if (isIgnore) continue;
     contentImports.push(`import type { ${className} } from '${fileNameJSRelative}';`);
-    contentRecordsGlobal.push(`'${beanFullName}': ${className};`);
+    contentRecordsGlobal.push(`    '${beanName}': ${className};`);
   }
   if (contentImports.length === 0) return '';
   // combine
   const content = `/** ${sceneName}: begin */
 ${contentImports.join('\n')}
-import 'vona';  
+import 'vona';
 declare module 'vona' {
   export interface IBeanRecordGlobal {
-    ${contentRecordsGlobal.join('\n')}
+${contentRecordsGlobal.join('\n')}
   }
 }
 /** ${sceneName}: end */

package/vona/src/suite-vendor/a-vona/modules/a-bean/package.json

@@ -1,6 +1,6 @@
 {
   "name": "vona-module-a-bean",
-  "version": "5.1.5",
+  "version": "5.1.6",
   "gitHead": "a79189b882c17af5911573896a781bbb0046d37d",
   "description": "",
   "keywords": [

package/vona/src/suite-vendor/a-vona/modules/a-cache/cli/cacheMem/boilerplate/{{sceneName}}.{{beanName}}.ts_

@@ -1,8 +1,8 @@
-import { BeanCacheMemBase, CacheMem } from 'vona-module-a-cache';
+import { ServiceCacheMemBase, CacheMem } from 'vona-module-a-cache';
 
 export type TCacheMem<%=argv.beanNameCapitalize%>Key = any;
 export type TCacheMem<%=argv.beanNameCapitalize%>Data = any;
 
 @CacheMem()
 export class CacheMem<%=argv.beanNameCapitalize%>
-  extends BeanCacheMemBase<TCacheMem<%=argv.beanNameCapitalize%>Key, TCacheMem<%=argv.beanNameCapitalize%>Data> {}
+  extends ServiceCacheMemBase<TCacheMem<%=argv.beanNameCapitalize%>Key, TCacheMem<%=argv.beanNameCapitalize%>Data> {}

package/vona/src/suite-vendor/a-vona/modules/a-cache/cli/cacheRedis/boilerplate/{{sceneName}}.{{beanName}}.ts_

@@ -1,8 +1,8 @@
-import { BeanCacheRedisBase, CacheRedis } from 'vona-module-a-cache';
+import { ServiceCacheRedisBase, CacheRedis } from 'vona-module-a-cache';
 
 export type TCacheRedis<%=argv.beanNameCapitalize%>Key = any;
 export type TCacheRedis<%=argv.beanNameCapitalize%>Data = any;
 
 @CacheRedis()
 export class CacheRedis<%=argv.beanNameCapitalize%>
-  extends BeanCacheRedisBase<TCacheRedis<%=argv.beanNameCapitalize%>Key, TCacheRedis<%=argv.beanNameCapitalize%>Data> {}
+  extends ServiceCacheRedisBase<TCacheRedis<%=argv.beanNameCapitalize%>Key, TCacheRedis<%=argv.beanNameCapitalize%>Data> {}

package/vona/src/suite-vendor/a-vona/modules/a-cache/package.json

@@ -1,6 +1,6 @@
 {
   "name": "vona-module-a-cache",
-  "version": "5.1.5",
+  "version": "5.1.6",
   "gitHead": "a79189b882c17af5911573896a781bbb0046d37d",
   "description": "",
   "keywords": [

package/vona/src/suite-vendor/a-vona/modules/a-cache/src/.metadata/index.ts

@@ -1,8 +1,6 @@
 // eslint-disable
 /** bean: begin */
 export * from '../bean/bean.cache.ts';
-export * from '../bean/bean.cacheMemBase.ts';
-export * from '../bean/bean.cacheRedisBase.ts';
 
 import 'vona';
 declare module 'vona' {
@@ -26,6 +24,19 @@ declare module 'vona' {
   }
 }
 /** bean: end */
+/** service: begin */
+export * from '../service/cacheMemBase_.ts';
+export * from '../service/cacheRedisBase_.ts';
+
+import 'vona-module-a-bean';
+declare module 'vona-module-a-bean' {
+  
+  
+}
+declare module 'vona-module-a-cache' {
+   
+}
+/** service: end */
 /** broadcast: begin */
 export * from '../bean/broadcast.memClear.ts';
 export * from '../bean/broadcast.memDel.ts';