cabloy 5.1.72 → 5.1.74

package/cabloy-docs/backend/master-detail-workflow.md

@@ -1,18 +1,43 @@
 # Master-Detail Workflow
 
-This guide explains how to scaffold a backend master-detail aggregate in the Cabloy monorepo.
+This guide explains how to scaffold and reason about backend detail aggregates in the Cabloy monorepo.
+
+Use this page when the business shape is not “two unrelated CRUD resources,” but a parent resource that owns one or more nested detail collections.
+
+> [!TIP]
+> For the deep evidence trail behind this workflow, also read [Master-Detail Source Reading Map](/backend/master-detail-source-reading-map).
+
+## What this page covers
+
+The current repo already demonstrates three related shapes:
+
+1. **master-detail** — one master resource owns a first-level detail collection
+2. **nested-detail** — a detail can itself own another detail collection
+3. **standalone-capable detail resource** — a detail can remain aggregate-owned only, or also keep its own standalone resource surface
+
+The strongest current specimen is:
+
+- `training-student` -> `training-record` -> `training-recordsubject`
+
+A practical reading of that chain is:
+
+- `student` is the master resource
+- `record` is a first-level detail under `student`
+- `subject` is a second-level detail under `record`
+- `record` also demonstrates the case where a detail keeps its own standalone CRUD/resource surface
 
 ## Why this page matters
 
-Some business shapes are not best expressed as two unrelated CRUD resources.
+Some business shapes are not best expressed as unrelated standalone resources.
 
-A common pattern is:
+A common Cabloy pattern is:
 
 - one master resource owns the aggregate lifecycle
 - one detail resource is edited as a nested collection under the master
 - the detail may or may not also expose its own standalone resource surface
+- the same structural rule can repeat recursively when a detail becomes the parent of another detail
 
-The `training-student` + `training-record` specimen in the current repo demonstrates this pattern.
+The `training-student` + `training-record` specimen demonstrates the first-level pattern, and the `training-record` + `training-recordsubject` thread demonstrates the recursive second-level pattern.
 
 ## Use the generator first
 
@@ -34,6 +59,8 @@ A practical reading of the arguments is:
 - `--fk=studentId`: detail-side FK field
 - `--detailMode=...`: whether the detail keeps a standalone resource surface
 
+The same structural rule applies recursively when a first-level detail later owns its own nested detail collection.
+
 ## Module naming rule
 
 For `--module` and `--detailModule`, use the canonical Vona module relative name such as `training-student` or `training-record`.
@@ -53,9 +80,10 @@ The generator is designed to create the aggregate-detail thread, including:
 1. master model relation wiring
 2. master service `include` lifecycle for create/view/update/delete
 3. master-side nested detail DTOs
-4. built-in `basic-details` UI metadata for row/bulk actions
+4. built-in `basic-details` UI metadata for nested row/bulk interactions
 5. detail FK persistence field in the detail entity
 6. detail schema/index support for the FK
+7. metadata refresh for both the master module and the detail module
 
 This keeps the structural pattern consistent before domain-specific refinement starts.
 
@@ -73,7 +101,12 @@ In this mode, the detail module remains:
 
 - entity/model/meta-based
 - owned by the master aggregate
-- without a standalone controller/service resource surface
+- without a standalone controller/service/DTO resource surface
+
+A practical source-backed nuance is:
+
+- if the detail resource was just scaffolded for aggregate usage, the standalone controller/service/DTO surface is removed
+- if an existing detail module already has a standalone surface, the generator refuses to silently repurpose it as aggregate-only
 
 Choose this mode when the detail is primarily edited only through the master workflow.
 
@@ -88,7 +121,8 @@ Use:
 In this mode, the detail module:
 
 - still participates in the master aggregate
-- keeps or creates its own standalone controller/service resource surface
+- keeps its own standalone controller/service/DTO resource surface
+- can be addressed both through nested editing and through its own independent resource workflow
 
 Choose this mode when the detail also needs independent entry points, workflows, or resource-level access outside the master editing flow.
 
@@ -106,44 +140,161 @@ Use standalone mode when:
 - external workflows need to query or mutate detail items directly
 - the detail has user-facing or integration-facing behavior beyond nested editing
 
-## Specimen mapping
+## Nested-detail pattern
+
+Nested-detail is not a separate special case. It is the same structural idea applied one level lower.
+
+The specimen chain is:
+
+- `student`
+  - `trainingRecords`
+    - `trainingRecordSubjects`
+
+A practical rule is:
+
+- the master owns first-level detail editing
+- a first-level detail can itself own second-level detail editing
+- each level repeats the same relation + DTO + include wiring pattern with the immediate parent as the owner
+
+That means `record` is both:
+
+- a detail under `student`
+- a parent of `trainingRecordSubjects`
+
+## DTO naming and placement rules
+
+The current source shows a consistent naming and placement rule for nested detail DTOs.
+
+| Concern                   | Rule                                                                                                     | Example                                                                      | Boundary                                                                                      |
+| ------------------------- | -------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------- |
+| Nested detail DTO naming  | Prefix nested detail DTO names with `detail` for immediate recognizability                               | `detailRecordMutate`, `detailRecordView`                                     | This rule is for nested detail DTOs, not every DTO in the child module                        |
+| First-level placement     | Place first-level detail DTOs beside the parent DTOs that consume them                                   | `training-student/src/dto/studentCreate.tsx` beside `detailRecord*.tsx`      | Do not move these DTOs into the child module just because the child also has its own resource |
+| Second-level placement    | Place second-level detail DTOs beside the DTOs of their immediate parent                                 | `training-record/src/dto/recordCreate.tsx` beside `detailRecordSubject*.tsx` | Repeat the same rule recursively for deeper levels                                            |
+| Standalone child boundary | A detail resource that keeps its own standalone surface still uses its normal standalone DTO names there | `recordCreate`, `recordUpdate`, `recordView` in `training-record`            | Standalone CRUD naming does not replace the nested `detail*` DTO convention                   |
+
+## DTO naming rule
+
+Use the `detail` prefix for nested detail DTOs so the role is explicit in both source and generated contract surfaces.
+
+Representative first-level examples:
+
+- `detailRecordBase`
+- `detailRecordMutate`
+- `detailRecordResItem`
+- `detailRecordView`
 
-The current specimen maps like this:
+Representative second-level examples:
+
+- `detailRecordSubjectBase`
+- `detailRecordSubjectMutate`
+- `detailRecordSubjectResItem`
+- `detailRecordSubjectView`
+
+This makes nested detail artifacts easy to distinguish from ordinary standalone CRUD DTOs.
+
+## DTO placement rule
+
+Place nested detail DTOs next to the parent DTOs that consume them.
+
+That means:
+
+- the `student*` DTOs and `detailRecord*` DTOs live together in `training-student/src/dto/`
+- the `record*` DTOs and `detailRecordSubject*` DTOs live together in `training-record/src/dto/`
+
+A practical recursive rule is:
+
+- first-level detail DTOs belong with the master DTOs
+- second-level detail DTOs belong with the first-level parent DTOs
+- repeat the same rule for deeper levels if the aggregate continues to nest
+
+This placement makes the ownership path obvious at the point where nested editing is actually authored.
+
+## `dtoClass` in master-detail DTO wiring
+
+The nested DTO thread is not only about naming. The current scaffolded pattern also uses `dtoClass` so the parent DTO keeps aggregate relation wiring while the nested detail DTO class defines the reusable field surface.
+
+Representative pattern:
+
+- parent DTOs include nested details through `include: { relationName: { dtoClass: DtoDetail... } }`
+- detail DTO families such as `detailRecordBase`, `detailRecordMutate`, and `detailRecordView` define which detail fields are exposed for each scene
+- nested details can repeat the same `dtoClass` pattern recursively one level lower
+
+That is why master-detail DTOs do not need to inline long relation column lists everywhere. They can reuse named detail DTO classes instead.
+
+For a broader explanation of `dtoClass` as a DTO inference option, also read [DTO Infer and Generation](/backend/dto-infer-generation).
+
+## Specimen walkthrough
+
+The current specimen maps like this.
+
+### First-level master-detail: `student -> record`
 
 - master relation: `vona/src/suite/a-training/modules/training-student/src/model/student.ts`
 - master service include lifecycle: `vona/src/suite/a-training/modules/training-student/src/service/student.ts`
-- master nested DTOs: `vona/src/suite/a-training/modules/training-student/src/dto/studentCreate.tsx`, `studentUpdate.tsx`, `studentView.tsx`
-- detail row/bulk metadata: `vona/src/suite/a-training/modules/training-student/src/dto/detailRecordResItem.tsx`
+- master nested DTO wiring: `vona/src/suite/a-training/modules/training-student/src/dto/studentCreate.tsx`, `studentUpdate.tsx`, `studentView.tsx`
+- first-level detail DTOs: `vona/src/suite/a-training/modules/training-student/src/dto/detailRecordBase.tsx`, `detailRecordMutate.tsx`, `detailRecordResItem.tsx`, `detailRecordView.tsx`
 - detail FK field: `vona/src/suite/a-training/modules/training-record/src/entity/record.tsx`
+- contract exposure: `vona/src/suite/a-training/modules/training-student/src/.metadata/index.ts`
+
+### Second-level nested-detail: `record -> subject`
+
+- detail-as-parent relation: `vona/src/suite/a-training/modules/training-record/src/model/record.ts`
+- detail-as-parent include lifecycle: `vona/src/suite/a-training/modules/training-record/src/service/record.ts`
+- second-level nested DTO wiring: `vona/src/suite/a-training/modules/training-record/src/dto/recordCreate.tsx`, `recordUpdate.tsx`, `recordView.tsx`
+- second-level detail DTOs: `vona/src/suite/a-training/modules/training-record/src/dto/detailRecordSubjectBase.tsx`, `detailRecordSubjectMutate.tsx`, `detailRecordSubjectResItem.tsx`, `detailRecordSubjectView.tsx`
+- contract exposure: `vona/src/suite/a-training/modules/training-record/src/.metadata/index.ts`
+
+### Detail resource that also keeps a standalone resource surface
 
-This is the reference shape the generator aims to standardize.
+The `training-record` module demonstrates the dual-role case.
+
+It is simultaneously:
+
+- a nested detail under `student`
+- a standalone resource with its own ordinary CRUD DTOs such as `recordCreate`, `recordUpdate`, and `recordView`
+
+That is the practical boundary to remember:
+
+- nested detail DTOs use `detail*` names in the parent module
+- the child resource can still keep its own ordinary standalone DTO names in its own standalone resource surface
 
 ## Recommended workflow
 
 1. run `:tools:masterDetail`
 2. inspect the generated relation, DTO, and service thread
-3. refine entity fields and validation rules for the domain
-4. refine detail columns/actions when the default `basic-details` behavior is not enough
-5. refresh and verify metadata/build outputs
+3. confirm whether the detail should remain aggregate-only or also stay standalone
+4. if the detail later becomes a parent of another detail, repeat the same pattern one level lower
+5. refine entity fields and validation rules for the domain
+6. refine detail columns/actions when the default `basic-details` behavior is not enough
+7. refresh and verify metadata/build outputs
 
-## Relationship to CRUD workflow
+## Relationship to other docs
 
 Use [CRUD Workflow](/backend/crud-workflow) when the target is primarily a standalone resource.
 
-Use this page when the target is a master resource with a nested detail collection.
+Use [Relations Guide](/backend/relations-guide) when the question is about general ORM relation semantics such as `hasMany`, `belongsTo`, `include`, or `with`.
+
+Use [Master-Detail Source Reading Map](/backend/master-detail-source-reading-map) when the question becomes “which source files prove the current master-detail and nested-detail behavior?”
+
+Use [Contract Loop Playbook](/fullstack/contract-loop-playbook) when the next question crosses the backend/frontend contract boundary.
 
-The two workflows are complementary:
+The workflows are complementary:
 
 - CRUD scaffolds standalone backend threads
 - master-detail scaffolds aggregate ownership plus nested detail editing
+- the source-reading map traces the current evidence trail behind both
 
 ## Verification checklist
 
-After generation:
+After generation or documentation changes:
 
-1. confirm the master model contains the `hasMany` relation
+1. confirm the master model contains the expected `hasMany` relation
 2. confirm master service create/view/update/delete includes the detail relation
 3. confirm master create/update/view DTOs include nested detail DTO wiring
-4. confirm the detail entity contains the FK field
-5. confirm detail schema/index output includes the FK support
-6. if standalone mode was chosen, confirm the detail module still exposes its standalone resource surface
+4. confirm the nested detail DTO names follow the `detail*` rule
+5. confirm the nested detail DTOs are placed beside the parent DTOs that consume them
+6. for second-level nested detail, confirm the same naming and placement rule repeats with the immediate parent
+7. confirm the detail entity contains the FK field
+8. confirm detail schema/index output includes the FK support
+9. confirm the module `.metadata/index.ts` exports the expected nested detail DTOs
+10. if standalone mode was chosen, confirm the detail module still exposes its standalone resource surface

package/cabloy-docs/backend/relations-guide.md

@@ -106,6 +106,10 @@ await this.scope.model.order.update(
 
 This is one of the strongest reasons Cabloy can express CRUD-oriented business flows compactly.
 
+If the next question becomes specifically about aggregate-owned detail resources, nested-detail recursion, or nested detail DTO naming/placement, continue with [Master-Detail Workflow](/backend/master-detail-workflow).
+
+If the next question becomes how a relation-aware DTO should keep a reusable named field surface instead of only inline relation columns, continue with [DTO Infer and Generation](/backend/dto-infer-generation), especially the `dtoClass` guidance.
+
 ## `belongsToMany`
 
 `belongsToMany` models `n:n` relations through an intermediate model.

package/lint-staged.config.mjs

@@ -36,7 +36,6 @@ const OXFMT_IGNORE_PATTERNS = [
   '**/src-capacitor',
   '**/src-cordova',
   // vona-specific
-  '**/zovaRest',
   'vona/packages-cli/cli-set-api/cli/templates',
   // zova-specific
   'zova/packages-cli/cli-set-front/cli/templates',

package/oxfmt.config.ts

@@ -38,7 +38,6 @@ export default defineConfig(
       '**/src-capacitor',
       '**/src-cordova',
       // vona-specific
-      '**/zovaRest',
       'vona/packages-cli/cli-set-api/cli/templates',
       // zova-specific
       'zova/packages-cli/cli-set-front/cli/templates',

package/oxlint.config.ts

@@ -59,7 +59,6 @@ export default defineConfig(
       '**/src-cordova',
       '**/package.json',
       // vona-specific
-      '**/zovaRest',
       'vona/packages-cli/cli-set-api/cli/templates',
       // zova-specific
       'zova/packages-cli/cli-set-front/cli/templates',

package/package.json

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

package/scripts/init.ts

@@ -115,6 +115,32 @@ function writeVersionMarker(): void {
   console.log(`[init] Marked Cabloy version: ${version}`);
 }
 
+function seedVonaZovaRestWorkspaceDependencies(pkgPath: string): void {
+  // `package.original.json` intentionally keeps Vona close to a minimal bootstrap state.
+  // During `npm run init`, seed the generated `.zova-rest/*` workspace dependencies back into
+  // `vona/package.json` before the first install so pnpm sees the `zova -> zova-core`
+  // dependency chain and applies the workspace patch instead of reporting it as unused.
+  const zovaRestWorkspaceDir = resolve(VONA_DIR, '.zova-rest');
+  if (!existsSync(zovaRestWorkspaceDir)) return;
+  const pkg = JSON.parse(readFileSync(pkgPath, 'utf-8')) as {
+    dependencies?: Record<string, string>;
+  };
+  pkg.dependencies ??= {};
+  let changed = false;
+  for (const entry of readdirSync(zovaRestWorkspaceDir, { withFileTypes: true })) {
+    if (!entry.isDirectory()) continue;
+    const depName = `zova-rest-${entry.name}`;
+    const depValue = 'workspace:^';
+    if (pkg.dependencies[depName] === depValue) continue;
+    pkg.dependencies[depName] = depValue;
+    changed = true;
+  }
+  if (!changed) return;
+  writeFileSync(pkgPath, `${JSON.stringify(pkg, null, 2)}\n`);
+  // eslint-disable-next-line
+  console.log('[init] Seeded Vona .zova-rest dependencies');
+}
+
 // --- Step 0: Set APP_NAME in .env files ---
 
 function setAppName(): void {
@@ -215,6 +241,7 @@ function initVona(): void {
   const pkgPath = resolve(VONA_DIR, 'package.json');
   // if (!existsSync(pkgPath)) {
   copyFileSync(resolve(VONA_DIR, 'package.original.json'), pkgPath);
+  seedVonaZovaRestWorkspaceDependencies(pkgPath);
   pnpmInstall(VONA_DIR);
   // }
   exec('npm run vona :tools:deps');
@@ -286,10 +313,10 @@ setAppName();
 generateEnvProdLocal();
 generateEnvProdDockerLocal();
 cleanupWorkspaceYaml();
-initVona();
 initZova();
-initCabloyDocs();
 buildSsrCabloyBasicStartBatch();
+initVona();
+initCabloyDocs();
 writeVersionMarker();
 // eslint-disable-next-line
 console.log('[init] Done!');

package/vona/oxfmt.config.ts

@@ -14,7 +14,6 @@ export default defineConfig(
       '.assets',
       'coverage',
       'docker-compose',
-      'zovaRest',
       'assets',
       '.app',
       '.claude',

package/vona/oxlint.config.ts

@@ -48,7 +48,6 @@ export default defineConfig(
       'coverage',
       'docker-compose',
       'package.json',
-      'zovaRest',
       'assets',
       'packages-cli/cli-set-api/cli/templates',
     ],

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

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

package/vona/packages-cli/cabloy-cli/src/lib/local.common.ts

@@ -153,7 +153,7 @@ export class LocalCommon {
     }
     _handleDeps('dependencies', deps);
     _handleDeps('devDependencies', depsDev);
-    // zovaRest
+    // zova rest workspace
     await this._generatePackageJson_pkgFromZovaRest(projectPath, pkgOriginal.dependencies);
     // save
     if (
@@ -176,7 +176,7 @@ export class LocalCommon {
     const bundles = await globby('*', { cwd: targetDir, onlyDirectories: true });
     for (const bundle of bundles) {
       const name = `zova-rest-${bundle}`;
-      devDependencies[name] = `file:./.zova-rest/${bundle}`;
+      devDependencies[name] = 'workspace:^';
     }
   }
 
@@ -203,7 +203,7 @@ export class LocalCommon {
         const isZovaRest = key.includes('zova-rest-');
         const isModule = key.includes('vona-module-') || key.includes('zova-module-');
         const isModuleWorkspace = isModule && version.startsWith('workspace:');
-        if (isZovaRest && version.includes('file:')) continue;
+        if (isZovaRest) continue;
         if (isModuleWorkspace) continue;
         // if (deps[key] && !isModule) continue;
         if (isModule) continue;

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

@@ -1,6 +1,6 @@
 {
   "name": "vona-cli",
-  "version": "1.1.123",
+  "version": "1.1.125",
   "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.121",
+  "version": "1.1.123",
   "gitHead": "a79189b882c17af5911573896a781bbb0046d37d",
   "description": "vona cli-set-api",
   "keywords": [

package/vona/packages-cli/cli-set-api/src/lib/bean/cli.bin.build.ts

@@ -56,6 +56,8 @@ const __dialectDriversAll = [
   'pg',
   'mysql2',
   'better-sqlite3',
+  'mariadb/callback',
+  'mariadb',
   'mysql',
   'oracledb',
   'pg-native',

package/vona/packages-cli/cli-set-api/src/lib/bean/cli.bin.buildModule.ts

@@ -56,6 +56,8 @@ export class CliBinBuildModule extends BeanCliBase {
     const aliasEntries: aliasImport.Alias[] = [];
     for (const name of [
       'better-sqlite3',
+      'mariadb/callback',
+      'mariadb',
       'mysql',
       'oracledb',
       'pg-native',

package/vona/packages-cli/cli-set-api/src/lib/bean/cli.bin.dev.ts

@@ -51,6 +51,7 @@ export class CliBinDev extends BeanCliBase {
         cwd: projectPath,
         exec: 'node',
         execArgs: [getImportEsm()],
+        ext: 'ts,tsx,json',
         // execArgs: ['--experimental-transform-types', getImportEsm(), '--trace-deprecation'],
         // signal: 'SIGHUP',
         watch: ['packages-utils', 'packages-vona', './src'],

package/vona/packages-cli/cli-set-api/src/lib/bean/cli.tools.deps.ts

@@ -20,7 +20,7 @@ export class CliToolsDeps extends BeanCliBase {
   }
 
   async _generate(projectPath: string) {
-    // generate zovaRest
+    // verify zova rest workspace
     const needPnpmInstall = await this._generateZovaRest(projectPath);
     // generate package.json
     const pnpmInstalled = await this.common._generatePackageJson(projectPath);
@@ -55,29 +55,16 @@ export class CliToolsDeps extends BeanCliBase {
   }
 
   async _generateZovaRest(projectPath: string) {
-    let needPnpmInstall = false;
     const targetDir = path.join(projectPath, '.zova-rest');
-    for (const module of this.modulesMeta.modulesArray) {
-      const moduleZovaRest = path.join(module.root, 'zovaRest');
-      if (!fse.existsSync(moduleZovaRest)) continue;
-      const bundles = await globby('*', { cwd: moduleZovaRest, onlyDirectories: true });
-      for (const bundle of bundles) {
-        const moduleZovaRestSrc = path.join(moduleZovaRest, bundle);
-        const moduleZovaRestDest = path.join(targetDir, bundle);
-        let needCopy = true;
-        if (fse.existsSync(moduleZovaRestDest)) {
-          const statDest = await fse.stat(path.join(moduleZovaRestDest, 'package.json'));
-          const statSrc = await fse.stat(path.join(moduleZovaRestSrc, 'package.json'));
-          // diff: 5s
-          if (statDest.mtimeMs + 5000 >= statSrc.mtimeMs) {
-            needCopy = false;
-          }
-        }
-        if (!needCopy) continue;
-        await fse.copy(moduleZovaRestSrc, moduleZovaRestDest, { preserveTimestamps: true });
-        needPnpmInstall = true;
-      }
+    if (!fse.existsSync(targetDir)) {
+      throw new Error(
+        'Zova REST workspace .zova-rest not found. Please run `npm run build:zova:admin` or `npm run build:zova:web` first.',
+      );
     }
-    return needPnpmInstall;
+    const bundles = await globby('*', { cwd: targetDir, onlyDirectories: true });
+    if (bundles.length > 0) return false;
+    throw new Error(
+      'No Zova REST bundles found in .zova-rest. Please run `npm run build:zova:admin` or `npm run build:zova:web` first.',
+    );
   }
 }

package/vona/packages-cli/cli-set-api/src/lib/bean/cli.tools.metadata.ts

@@ -286,7 +286,7 @@ export { ScopeModule${relativeNameCapitalize} as ScopeModule } from './index.ts'
       return pkg;
     }
     // cli
-    for (const name of ['cli', 'zovaRest']) {
+    for (const name of ['cli']) {
       const pathCheck = path.join(modulePath, name);
       if (!(await fse.pathExists(pathCheck))) continue;
       pkg = await _loadPkg();

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

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

package/vona/patches/zova-core@5.1.61.patch

@@ -0,0 +1,57 @@
+diff --git a/dist/bean/resource/error/errorGlobal.d.ts b/dist/bean/resource/error/errorGlobal.d.ts
+index 73cebe18f3e260c295bdf42a3d1ab9e86fa2de87..cb0ff5c3b541f646105198ee23ac0fc3d805023e 100644
+--- a/dist/bean/resource/error/errorGlobal.d.ts
++++ b/dist/bean/resource/error/errorGlobal.d.ts
+@@ -1,9 +1 @@
+-import type { TypeScopesErrorCodes } from '../../type.ts';
+-declare global {
+-    export interface Error {
+-        code?: TypeScopesErrorCodes | number | undefined;
+-        status?: number | string | undefined;
+-    }
+-}
+ export {};
+-//# sourceMappingURL=errorGlobal.d.ts.map
+
+diff --git a/dist/types/interface/module.d.ts b/dist/types/interface/module.d.ts
+index 838e299407218b7bfac469d42a12d6ab59820380..e8b61cc231e39ee3a270ee513ab43ff5a13fc290 100644
+--- a/dist/types/interface/module.d.ts
++++ b/dist/types/interface/module.d.ts
+@@ -23,12 +23,6 @@ export interface IModuleResource {
+     components: TypeModuleResourceComponents;
+ }
+ export declare const SymbolInstalled: unique symbol;
+-declare module '@cabloy/module-info' {
+-    interface IModule {
+-        resource: IModuleResource;
+-        info: IModuleInfo;
+-    }
+-}
+ export interface IModuleApp {
+ }
+ //# sourceMappingURL=module.d.ts.map
+
+diff --git a/dist/types/utils/env.d.ts b/dist/types/utils/env.d.ts
+index 708c0a584dfec65b8c7ad2d049156f900de49928..a8caacb276794e3ac70591b974f14d6eee3ac302 100644
+--- a/dist/types/utils/env.d.ts
++++ b/dist/types/utils/env.d.ts
+@@ -34,19 +34,4 @@ export interface ZovaConfigEnv {
+     MOCK_BUILD: string | undefined;
+     MOCK_BUILD_PORT: string | undefined;
+ }
+-declare global {
+-    namespace NodeJS {
+-        interface ProcessEnv {
+-            NODE_ENV: ZovaMetaMode;
+-            META_FLAVOR: ZovaMetaFlavor;
+-            META_MODE: ZovaMetaMode;
+-            META_APP_MODE: ZovaMetaAppMode;
+-            SSR: boolean;
+-            DEV: boolean;
+-            PROD: boolean;
+-            CLIENT: boolean;
+-            SERVER: boolean;
+-        }
+-    }
+-}
+ //# sourceMappingURL=env.d.ts.map