cabloy 5.1.231 → 5.1.233

package/.cabloy-version

@@ -1 +1 @@
-5.1.231
+5.1.233

package/CHANGELOG.md

@@ -1,5 +1,22 @@
 # Changelog
 
+## 5.1.233
+
+### Features
+
+- Apply feature updates.
+
+### Improvements
+
+- Migrate JavaScript code to TypeScript.
+
+## 5.1.232
+
+### Improvements
+
+- Refresh the Zova lockfile after preparing the compensation rerun.
+- Update the Vona zova-core patch for v5.1.94.
+
 ## 5.1.231
 
 ### Features

package/package.json

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

package/repo-agent-governance/managed-assets.json

@@ -95,7 +95,7 @@
     {
       "adapter": "codex",
       "category": "skill",
-      "sha256": "c3233550631e7782834811d3bd73b9b823b0bd429a681cedff85e24128b9ed35",
+      "sha256": "0324ce1fb9a9b7b2074f60b8252c62b124f5804b808be8146ebb2ccb8762b38b",
       "source": "skills/cabloy-frontend-scaffold/SKILL.md",
       "target": ".agents/skills/cabloy-frontend-scaffold/SKILL.md"
     },
@@ -179,7 +179,7 @@
     {
       "adapter": "codex",
       "category": "skill",
-      "sha256": "64615460c3bec383bb0010ddc1412e7fa8f122bbb3f87cfe5c824891fe247e6c",
+      "sha256": "0c7c673faf069c1cf2a879babc6a6acac4fc80963926fcb181fe529d9b24d331",
       "source": "skills/cabloy-spec-execution/references/execution-protocol.md",
       "target": ".agents/skills/cabloy-spec-execution/references/execution-protocol.md"
     },
@@ -431,7 +431,7 @@
     {
       "adapter": "claude",
       "category": "skill",
-      "sha256": "c3233550631e7782834811d3bd73b9b823b0bd429a681cedff85e24128b9ed35",
+      "sha256": "0324ce1fb9a9b7b2074f60b8252c62b124f5804b808be8146ebb2ccb8762b38b",
       "source": "skills/cabloy-frontend-scaffold/SKILL.md",
       "target": ".claude/skills/cabloy-frontend-scaffold/SKILL.md"
     },
@@ -515,7 +515,7 @@
     {
       "adapter": "claude",
       "category": "skill",
-      "sha256": "64615460c3bec383bb0010ddc1412e7fa8f122bbb3f87cfe5c824891fe247e6c",
+      "sha256": "0c7c673faf069c1cf2a879babc6a6acac4fc80963926fcb181fe529d9b24d331",
       "source": "skills/cabloy-spec-execution/references/execution-protocol.md",
       "target": ".claude/skills/cabloy-spec-execution/references/execution-protocol.md"
     },
@@ -683,7 +683,7 @@
     {
       "adapter": "cursor",
       "category": "policy",
-      "sha256": "162dc7bf2d01964a249bc11b29c429af2d379e29c2d61c748ce332f35a224a8e",
+      "sha256": "a41379c32f2ab77a691b282d13d3ad1fd2887e14694109f2afa43974a438cbee",
       "source": "policies/repository.md",
       "target": ".cursor/rules/cabloy-governance.mdc"
     },
@@ -781,7 +781,7 @@
     {
       "adapter": "cursor",
       "category": "skill",
-      "sha256": "c3233550631e7782834811d3bd73b9b823b0bd429a681cedff85e24128b9ed35",
+      "sha256": "0324ce1fb9a9b7b2074f60b8252c62b124f5804b808be8146ebb2ccb8762b38b",
       "source": "skills/cabloy-frontend-scaffold/SKILL.md",
       "target": ".cursor/skills/cabloy-frontend-scaffold/SKILL.md"
     },
@@ -865,7 +865,7 @@
     {
       "adapter": "cursor",
       "category": "skill",
-      "sha256": "64615460c3bec383bb0010ddc1412e7fa8f122bbb3f87cfe5c824891fe247e6c",
+      "sha256": "0c7c673faf069c1cf2a879babc6a6acac4fc80963926fcb181fe529d9b24d331",
       "source": "skills/cabloy-spec-execution/references/execution-protocol.md",
       "target": ".cursor/skills/cabloy-spec-execution/references/execution-protocol.md"
     },
@@ -1005,14 +1005,14 @@
     {
       "adapter": "codex",
       "category": "policy",
-      "sha256": "af4c50c261114d494961bd30a75c2a7baf999a43644d0aa9c218fbd8ad83c53d",
+      "sha256": "19b84cff474c23e561ba0cf532ff343da56febab3c484a4eb42912f9b9d8c6d3",
       "source": "policies/repository.md",
       "target": "AGENTS.md"
     },
     {
       "adapter": "claude",
       "category": "policy",
-      "sha256": "af4c50c261114d494961bd30a75c2a7baf999a43644d0aa9c218fbd8ad83c53d",
+      "sha256": "19b84cff474c23e561ba0cf532ff343da56febab3c484a4eb42912f9b9d8c6d3",
       "source": "policies/repository.md",
       "target": "CLAUDE.md"
     }

package/repo-agent-governance/policies/repository.md

@@ -61,7 +61,7 @@ Before inventing a custom implementation path:
 - 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.
 - For Zova frontend analysis, do not default to generic Vue reinterpretation first. Read the code through Zova’s controller / bean / IoC architecture before mapping it to Vue concepts.
 - For Zova source-reading or Vue-vs-Zova explanation tasks, start from the frontend reading guides and source-reading map in `repo-docs/frontend/` before doing framework-neutral reinterpretation.
-- In Zova application modules under `zova/src/module/**`, `zova/src/module-vendor/**`, `zova/src/suite/**/modules/**`, and `zova/src/suite-vendor/**/modules/**`, use emitted runtime suffixes for relative imports and exports: `.js` for `.ts` targets and `.jsx` for `.tsx` targets, including type-only imports and module tests. Preserve the deliberate `.ts`/`.tsx` convention in `zova/packages-utils/**` and `zova/packages-zova/**`; do not generalize this rule to Vona, CLI/templates, dependencies, generated output, or build artifacts.
+- In Zova application TypeScript/TSX source, authored or generated, relative imports and exports must name the actual source target: `.ts` for `.ts` targets and `.tsx` for `.tsx` targets, including type-only imports, tests, frontend entry/config source, and generated metadata. CLI templates and generators must preserve this convention in generated application source; regenerate generated consumers rather than hand-editing them. Preserve the existing source-suffix convention in `zova/packages-utils/**` and `zova/packages-zova/**`. Keep bare package names, assets, real JavaScript targets, compiled runtime loaders, and package exports unchanged; do not apply a repository-wide suffix replacement or extend this application-source rule to Vona, dependencies, or build artifacts.
 - In Zova page routes, any route with dynamic `params` must define `route.name`; do not rely on unnamed path-keyed routes for typed `$params`. Static routes should omit `route.name` unless a documented named-route requirement exists; use `$router.getPagePath(...)` for canonical static URL generation rather than adding a name or alias for convenience. Ordinary business routes without `locale` params should omit app-config aliases unless a documented system, compatibility, or user-facing URL exception requires one. Choose `ssrProfile` from the page's rendering contract: Web remains `public` by default, while `session` is an explicit choice for cookie-backed state, protected admission, personalized first paint, or private SSR data; the absence of a locale parameter alone does not select a profile. `requiresAuth` is independent, so anonymous routes must explicitly use `requiresAuth: false`. Regenerate page metadata after route changes.
 - For frontend async state that affects rendering or interaction across consumers, prefer model-owned `$useStateData(...)` over controller-managed fetch/cache state.
 - Default to establishing such query state during render. Use `disableSuspenseOnInit: true` only for relatively stable query-backed state when you want to skip the init-time `query.suspense()` kick; it does not prevent query creation, fetches, or hydration-time rendering. If strict readiness is needed later, wait explicitly at the interaction boundary.

package/repo-agent-governance/skills/cabloy-frontend-scaffold/SKILL.md

@@ -125,21 +125,26 @@ Do not throw away the generated structure and rewrite it from scratch unless the
 
 ### Relative import suffix follow-up
 
-For Zova application modules under `zova/src/module/**`, `zova/src/module-vendor/**`,
-`zova/src/suite/**/modules/**`, and `zova/src/suite-vendor/**/modules/**`, relative
-imports and exports name the emitted ESM file:
-
-- a `.ts` target uses `.js`
-- a `.tsx` target uses `.jsx`
-
-Apply this to ordinary and type-only imports, relative re-exports, and module tests.
-Keep the generated `.js`/`.jsx` specifiers as the baseline after CLI generation or
-metadata refresh; manual follow-up imports must use the same emitted suffix.
-
-Do not apply this rule globally. Preserve deliberate `.ts`/`.tsx` imports in
-`zova/packages-utils/**` and `zova/packages-zova/**`; do not normalize Vona, CLI or
-template source, dependencies, generated output, or build artifacts. Never use a
-repository-wide suffix replacement: inspect only the affected module thread.
+In Zova application TypeScript/TSX source, authored or generated, relative imports
+and exports name the actual source file:
+
+- a `.ts` target uses `.ts`
+- a `.tsx` target uses `.tsx`
+
+Apply this to ordinary and type-only imports, relative re-exports, module tests,
+frontend entry/config source, and generated application metadata. Application
+modules include `zova/src/module/**`, `zova/src/module-vendor/**`,
+`zova/src/suite/**/modules/**`, and `zova/src/suite-vendor/**/modules/**`.
+Keep generated `.ts`/`.tsx` specifiers as the baseline after CLI generation or
+metadata refresh; manual follow-up imports must use the same source suffix.
+If generation produces an emitted suffix for a TypeScript target, correct the
+owning template or generator and regenerate, rather than hand-patching its output.
+
+Preserve the existing `.ts`/`.tsx` imports in `zova/packages-utils/**` and
+`zova/packages-zova/**`. Leave bare package names, asset imports, real JavaScript
+targets, compiled runtime loaders, and package exports unchanged. Do not normalize
+Vona, dependencies, or build artifacts. Never use a repository-wide suffix
+replacement: inspect only the affected application source and its generation path.
 
 ## Step 5: Apply frontend follow-up logic deliberately
 
@@ -215,7 +220,7 @@ Check whether the feature needs:
 - typecheck
 - build
 - metadata regeneration verification
-- scoped relative-import verification: check the affected Zova module tree for accidental `.ts`/`.tsx` relative specifiers, while excluding intentional package source under `zova/packages-utils/**` and `zova/packages-zova/**`
+- scoped relative-import verification: check that affected authored and regenerated application source uses the actual `.ts`/`.tsx` target suffix, not stale `.js`/`.jsx` or extensionless TypeScript paths; preserve bare packages, assets, real JavaScript targets, compiled runtime loaders, and package exports
 - SSR or route-path verification
 - hydration-time initial-render equivalence when SSR, private state, browser-only state, or async model state changes
 - edition-specific flavor, SSR site baseline, and project-asset verification

package/repo-agent-governance/skills/cabloy-spec-execution/references/execution-protocol.md

@@ -130,13 +130,13 @@ Require explicit confirmation unless this same bounded dossier already has valid
 
 ## 6. Specialist routing
 
-| Task shape                                                                | Primary route                                       | Coordinator must preserve                                                                          |
-| ------------------------------------------------------------------------- | --------------------------------------------------- | -------------------------------------------------------------------------------------------------- |
-| Vona module/bean/service/model/entity/DTO/validation/migration/test       | `cabloy-backend-scaffold`                           | CLI-first generation, tenant/security review, migration/index/version gate, tests, OpenAPI impact  |
-| Zova page/component/route/model/metadata/SSR/test                         | `cabloy-frontend-scaffold`                          | route metadata, state ownership, hydration equivalence, emitted import suffixes, flavor/site proof |
-| OpenAPI, SDK/schema, generated consumer, reverse metadata, stale consumer | `cabloy-contract-loop`                              | source-first direction, paired SSR/REST reverse build, `deps:vona`, no hand edits                  |
-| master-detail, resource-field, module removal                             | corresponding specialist skill                      | specialized ownership and cleanup order                                                            |
-| requirement, architecture, scope, identity, or authority change           | `cabloy-spec-generation` / `cabloy-domain-planning` | no implementation around unresolved authority                                                      |
+| Task shape                                                                | Primary route                                       | Coordinator must preserve                                                                                |
+| ------------------------------------------------------------------------- | --------------------------------------------------- | -------------------------------------------------------------------------------------------------------- |
+| Vona module/bean/service/model/entity/DTO/validation/migration/test       | `cabloy-backend-scaffold`                           | CLI-first generation, tenant/security review, migration/index/version gate, tests, OpenAPI impact        |
+| Zova page/component/route/model/metadata/SSR/test                         | `cabloy-frontend-scaffold`                          | route metadata, state ownership, hydration equivalence, actual source import suffixes, flavor/site proof |
+| OpenAPI, SDK/schema, generated consumer, reverse metadata, stale consumer | `cabloy-contract-loop`                              | source-first direction, paired SSR/REST reverse build, `deps:vona`, no hand edits                        |
+| master-detail, resource-field, module removal                             | corresponding specialist skill                      | specialized ownership and cleanup order                                                                  |
+| requirement, architecture, scope, identity, or authority change           | `cabloy-spec-generation` / `cabloy-domain-planning` | no implementation around unresolved authority                                                            |
 
 The coordinator may pass the dossier to the specialist; it should not duplicate the specialist’s detailed command tree.
 

package/repo-docs/frontend/ioc-and-beans.md

@@ -112,7 +112,7 @@ The most important design point is that cross-module access should prefer bean i
 Same-module injection can stay class-oriented and concise:
 
 ```typescript
-import { ModelTodo } from '../../bean/model.todo.js';
+import { ModelTodo } from '../../bean/model.todo.ts';
 
 class ControllerTodo {
   @Use()

package/repo-docs/frontend/modules-and-suites.md

@@ -109,25 +109,32 @@ A practical convention from the legacy guidance is that `a-demo` can host demo o
 
 ## Import suffixes in Zova modules
 
-Zova application modules are authored in TypeScript and TSX, but their relative ESM
-specifiers name emitted runtime files. In module source, use `.js` for a `.ts` target
-and `.jsx` for a `.tsx` target:
+Zova application TypeScript/TSX source uses relative ESM specifiers that name the
+actual source target: `.ts` for a `.ts` file and `.tsx` for a `.tsx` file.
 
 ```ts
-import type { ModelStudent } from '../model/student.js';
+import type { ModelStudent } from '../model/student.ts';
 
-import { RenderCard } from './render.card.jsx';
+import { RenderCard } from './render.card.tsx';
 ```
 
-This applies to relative imports, type-only imports, re-exports, module tests, and
-module metadata that imports application code. Bare package imports are unchanged.
+This applies to authored and generated application source: ordinary and type-only
+imports, relative re-exports, module tests, frontend entry/config source, and
+generated metadata that imports application code. It includes module packages
+under `zova/src/module/**`, `zova/src/module-vendor/**`,
+`zova/src/suite/**/modules/**`, and `zova/src/suite-vendor/**/modules/**`.
+The existing `.ts`/`.tsx` imports in `zova/packages-utils/**` and
+`zova/packages-zova/**` remain unchanged.
 
-The scope is intentionally limited to module packages under `zova/src/module/**`,
-`zova/src/module-vendor/**`, `zova/src/suite/**/modules/**`, and
-`zova/src/suite-vendor/**/modules/**`. Do not copy this convention into
-`zova/packages-utils/**` or `zova/packages-zova/**`: those package sources have
-intentional `.ts`/`.tsx` imports. Do not use a repository-wide replacement across
-Vona, CLI or template source, dependencies, generated output, or build artifacts.
+CLI templates and generators must emit these actual source suffixes in application
+source. Refresh generated metadata and consumers through the owning CLI rather
+than hand-editing them. If output still names an emitted `.js`/`.jsx` file for a
+TypeScript target, fix the owning generation path and regenerate.
+
+This is not a rule to rename every JavaScript import. Bare package names, assets,
+real JavaScript targets, compiled runtime loaders, and package exports keep their
+existing specifiers. Do not apply a repository-wide replacement across Vona,
+dependencies, or build artifacts.
 
 ## Module and suite boundaries in practice
 
@@ -197,7 +204,7 @@ When editing or creates frontend code, ask:
 1. does this belong in an existing module or a new one?
 2. is this really one feature unit, or should it become part of a suite?
 3. does the naming follow Zova’s module/suite conventions?
-4. do relative imports and re-exports use emitted `.js`/`.jsx` suffixes within the affected module, without changing excluded package source?
+4. do relative imports and re-exports in authored and regenerated application source name actual `.ts`/`.tsx` targets, while preserving bare packages, assets, compiled runtime loaders, and package exports?
 5. will the chosen placement preserve the intended architectural and bundle boundaries?
 
 That helps AI keep frontend growth aligned with Zova’s modular system instead of falling back to generic folder expansion.

package/repo-docs/frontend/page-route-guide.md

@@ -11,7 +11,7 @@ That route record is the framework-level description of how the page is reached,
 ## Representative route record
 
 ```typescript
-import { ZPageCounter } from './.metadata/page/counter.js';
+import { ZPageCounter } from './.metadata/page/counter.ts';
 
 export const routes: IModuleRoute[] = [
   {

package/repo-docs/frontend/routed-dialog-guide.md

@@ -42,7 +42,7 @@ A routed-dialog target is an ordinary module page route. Do not invent a separat
 For a static target, keep the usual static-route convention: omit `name` unless the route has a documented named-route requirement.
 
 ```typescript
-import { ZPageCustomerPicker } from './.metadata/page/customerPicker.js';
+import { ZPageCustomerPicker } from './.metadata/page/customerPicker.ts';
 
 export const routes: IModuleRoute[] = [
   {
@@ -55,7 +55,7 @@ export const routes: IModuleRoute[] = [
 For a route with dynamic params, continue to declare `name`. This is required for the generated typed `$params` contract.
 
 ```typescript
-import { ZPageCustomerDetail } from './.metadata/page/customerDetail.js';
+import { ZPageCustomerDetail } from './.metadata/page/customerDetail.ts';
 
 export const routes: IModuleRoute[] = [
   {

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

@@ -70,7 +70,17 @@ Use the root commands to select the workspace scope:
 
 Explicit native and legacy checks use `--noEmit --incremental false`: Zova selects `tsconfig.vue-tsc.json`, and Vona selects `tsconfig.json`. Vona's daily config has no `include` or project `references`; default source discovery is filtered by `exclude`, following Zova's approach. Backend/application/module source and module tests are checked together in one program. CLI tooling, package-directory roots, dependencies, distribution output, and generated runtime/REST directories are excluded from initial discovery. Exclusions are not import barriers: required framework/package source and hidden module metadata still participate through imports. Unreferenced hidden helpers and generated `.vona` bootstraps are not independent daily-check roots.
 
-Choose the narrowest **supported, semantically appropriate checking project**, not simply the nearest module `tsconfig.json`. Prefer the active repository's root/workspace source-check entrypoints; a module publication/declaration configuration is not automatically a standalone application check. Before using a custom local invocation or interpreting configuration-related diagnostics, inspect the selected configuration's `extends` chain and effective compiler options, and confirm whether dependencies resolve to source or declarations. Dependency source imported into the consuming program is checked under that program's compiler options; the dependency package's own `tsconfig.json` is not automatically applied. Distinguish an unsuitable invocation/configuration from a business-source type error, and do not change import suffixes or relax compiler options merely to make that invocation pass. Keep daily application checks separate from publication/declaration validation, and verify the actual entrypoints in Cabloy Start rather than assuming all Basic aliases apply.
+For a module-local source change, use the nearest module `tsconfig.json` for a focused check when it covers the affected files. Zova's module source configurations and workspace source-check configurations now share `allowImportingTsExtensions: true`, so `.ts`/`.tsx` imports do not require switching to a workspace-wide check. Use the root/workspace entrypoints for cross-module changes, complete application checks, CI, and release verification; a module check follows its imports but does not cover every downstream consumer.
+
+For example, run this focused Zova source check from the repository root:
+
+```bash
+node scripts/typecheck.ts native zova --noEmit --composite false --incremental false --project src/suite/a-demo/modules/demo-basic/tsconfig.json
+```
+
+The runner resolves `--project` relative to the selected workspace (`zova` here), not the repository root. Replace `native` with `typescript` for a classic-compiler comparison. Module configurations can inherit `composite: true`; `--composite false --incremental false` selects a single-program check without build-info output and avoids TS6379 when disabling incremental compilation. This direct invocation does not run workspace `prerun`, so prepare dependencies and generated metadata through the existing workspace workflow when needed.
+
+Use source-check `tsconfig.json`, not publication/declaration `tsconfig.build.json`, for this lane. Inspect the selected configuration's `extends` chain, effective options, and file coverage when diagnosing configuration-related errors. Imported dependency source still uses the consuming program's compiler options, not the dependency's own configuration. Keep source checks separate from publication/declaration validation, and verify the actual entrypoints in Cabloy Start rather than assuming all Basic aliases apply.
 
 Root `npm run tsc` runs `tsc:zova`, then `tsc:vona`; these are the only root `tsc` entrypoints. Compiler selection remains in the nested workspaces: use `pnpm --dir zova run tsc:legacy` or `pnpm --dir vona run tsc:legacy` for comparison or fallback, and the corresponding workspace `tsc:native` scripts for explicit native checks. The former `tsc:force`, `tsc:vona:native:force`, and nested Vona `tsc:native:force` aliases have been removed: these source checks neither run a project build nor emit declarations/build-info files. Each module's existing publication scripts remain responsible for its declaration output; there is no separate root declaration-validation workflow.
 

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

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

package/vona/packages-cli/cli-set-api/src/lib/bean/toolsBin/testCleanupAdapters.test.ts

@@ -103,6 +103,22 @@ test('Redis scans escaped literal prefixes, deletes bounded batches and leaves d
   assert.ok(fake.closed);
 });
 
+test('Redis scan work is independent of deletion batches and forwards empty-page cursors', async () => {
+  const fake = redis([]);
+  const cursors: string[] = [];
+  const counts: number[] = [];
+  fake.connection.scan = async (cursor, _match, _pattern, _count, size) => {
+    cursors.push(cursor);
+    counts.push(size);
+    return cursor === '0' ? ['42', []] : ['0', ['owned:1', 'owned:2', 'owned:3']];
+  };
+  await clearExactRedisPrefix(fake.connection, 'owned:', validate, { batchSize: 2 });
+  assert.deepEqual(cursors, ['0', '42']);
+  assert.deepEqual(counts, [1024, 1024]);
+  assert.deepEqual(fake.deleted, [['owned:1', 'owned:2'], ['owned:3']]);
+  assert.ok(fake.closed);
+});
+
 test('Redis rejects a foreign key before deleting any batch', async () => {
   const fake = redis(['owned:1', 'development:sentinel']);
   await assert.rejects(

package/vona/packages-cli/cli-set-api/src/lib/bean/toolsBin/testCleanupAdapters.ts

@@ -88,7 +88,9 @@ export async function clearExactRedisPrefix(
         'MATCH',
         `${escapeRedisCleanupPattern(prefix)}*`,
         'COUNT',
-        batchSize,
+        // MATCH still traverses the whole database; keep scan work separate from
+        // the bounded deletion batches to avoid excessive round trips.
+        1024,
       );
       if (
         !Array.isArray(result) ||