cabloy 5.1.229 → 5.1.231

package/.cabloy-version

@@ -1 +1 @@
-5.1.229
+5.1.231

package/.github/workflows/playwright-e2e.yml

@@ -98,7 +98,8 @@ jobs:
         if: runner.os != 'Linux'
         run: npx playwright install chromium
       - name: run focused managed E2E regression gate
-        run: node --test zova/packages-utils/zova-vite/test/configUtils.test.ts scripts/testClaimProcesses.test.ts scripts/runIsolatedTest.test.ts scripts/generateOpenapiIsolated.test.ts scripts/testClaimCleanup.test.ts scripts/testProcessGuardianWindows.test.ts scripts/testBrowserGuardianWindows.test.ts vona/packages-vona/vona-core/src/lib/core/testClaim.test.ts vona/packages-vona/vona-core/src/lib/core/testClaimFilesystem.test.ts vona/packages-vona/vona-core/src/lib/framework/processWorker.test.ts vona/src/suite-vendor/a-vona/modules/a-static/test/middlewareSystem.static.test.ts vona/src/suite-vendor/a-vona/modules/a-metrics/test/middlewareSystem.health.test.ts vona/src/suite-vendor/a-vona/modules/a-logger/test/middlewareSystem.httpLog.test.ts vona/src/suite-vendor/a-vona/modules/a-logger/src/lib/redactIsolatedReadyHeader.test.ts repo-e2e/scripts/managedTest.test.ts repo-e2e/scripts/managedTestImports.test.ts repo-e2e/scripts/e2e.test.ts repo-e2e/scripts/runE2eArgs.test.ts repo-e2e/scripts/runE2e.test.ts
+        # Bound concurrent PowerShell/Add-Type cold starts on Windows runners.
+        run: node --test ${{ runner.os == 'Windows' && '--test-concurrency=2' || '' }} zova/packages-utils/zova-vite/test/configUtils.test.ts scripts/testClaimProcesses.test.ts scripts/runIsolatedTest.test.ts scripts/generateOpenapiIsolated.test.ts scripts/testClaimCleanup.test.ts scripts/testProcessGuardianWindows.test.ts scripts/testBrowserGuardianWindows.test.ts vona/packages-vona/vona-core/src/lib/core/testClaim.test.ts vona/packages-vona/vona-core/src/lib/core/testClaimFilesystem.test.ts vona/packages-vona/vona-core/src/lib/framework/processWorker.test.ts vona/src/suite-vendor/a-vona/modules/a-static/test/middlewareSystem.static.test.ts vona/src/suite-vendor/a-vona/modules/a-metrics/test/middlewareSystem.health.test.ts vona/src/suite-vendor/a-vona/modules/a-logger/test/middlewareSystem.httpLog.test.ts vona/src/suite-vendor/a-vona/modules/a-logger/src/lib/redactIsolatedReadyHeader.test.ts repo-e2e/scripts/managedTest.test.ts repo-e2e/scripts/managedTestImports.test.ts repo-e2e/scripts/e2e.test.ts repo-e2e/scripts/runE2eArgs.test.ts repo-e2e/scripts/runE2e.test.ts
       - name: run Basic E2E baseline
         run: npm run test:e2e -- cabloy-basic home-user-account
       - name: upload Playwright artifacts
@@ -206,7 +207,8 @@ jobs:
         if: runner.os != 'Linux'
         run: npx playwright install chromium
       - name: run focused managed E2E regression gate
-        run: node --test zova/packages-utils/zova-vite/test/configUtils.test.ts scripts/testClaimProcesses.test.ts scripts/runIsolatedTest.test.ts scripts/generateOpenapiIsolated.test.ts scripts/testClaimCleanup.test.ts scripts/testProcessGuardianWindows.test.ts scripts/testBrowserGuardianWindows.test.ts vona/packages-vona/vona-core/src/lib/core/testClaim.test.ts vona/packages-vona/vona-core/src/lib/core/testClaimFilesystem.test.ts vona/packages-vona/vona-core/src/lib/framework/processWorker.test.ts vona/src/suite-vendor/a-vona/modules/a-static/test/middlewareSystem.static.test.ts vona/src/suite-vendor/a-vona/modules/a-metrics/test/middlewareSystem.health.test.ts vona/src/suite-vendor/a-vona/modules/a-logger/test/middlewareSystem.httpLog.test.ts vona/src/suite-vendor/a-vona/modules/a-logger/src/lib/redactIsolatedReadyHeader.test.ts repo-e2e/scripts/managedTest.test.ts repo-e2e/scripts/managedTestImports.test.ts repo-e2e/scripts/e2e.test.ts repo-e2e/scripts/runE2eArgs.test.ts repo-e2e/scripts/runE2e.test.ts
+        # Bound concurrent PowerShell/Add-Type cold starts on Windows runners.
+        run: node --test ${{ runner.os == 'Windows' && '--test-concurrency=2' || '' }} zova/packages-utils/zova-vite/test/configUtils.test.ts scripts/testClaimProcesses.test.ts scripts/runIsolatedTest.test.ts scripts/generateOpenapiIsolated.test.ts scripts/testClaimCleanup.test.ts scripts/testProcessGuardianWindows.test.ts scripts/testBrowserGuardianWindows.test.ts vona/packages-vona/vona-core/src/lib/core/testClaim.test.ts vona/packages-vona/vona-core/src/lib/core/testClaimFilesystem.test.ts vona/packages-vona/vona-core/src/lib/framework/processWorker.test.ts vona/src/suite-vendor/a-vona/modules/a-static/test/middlewareSystem.static.test.ts vona/src/suite-vendor/a-vona/modules/a-metrics/test/middlewareSystem.health.test.ts vona/src/suite-vendor/a-vona/modules/a-logger/test/middlewareSystem.httpLog.test.ts vona/src/suite-vendor/a-vona/modules/a-logger/src/lib/redactIsolatedReadyHeader.test.ts repo-e2e/scripts/managedTest.test.ts repo-e2e/scripts/managedTestImports.test.ts repo-e2e/scripts/e2e.test.ts repo-e2e/scripts/runE2eArgs.test.ts repo-e2e/scripts/runE2e.test.ts
       - name: run Commerce cart model regression
         run: node --test zova/src/suite/a-commerce/modules/commerce-trade/test/lib/cartModel.test.ts
       - name: build Commerce Zova artifacts

package/.github/workflows/vona-test-sqlite3.yml

@@ -93,7 +93,8 @@ jobs:
       - name: init
         run: npm run init
       - name: run isolated test infrastructure gate
-        run: node --test scripts/testClaimProcesses.test.ts scripts/runIsolatedTest.test.ts scripts/testClaimCleanup.test.ts scripts/testProcessGuardianWindows.test.ts vona/packages-vona/vona-core/src/lib/core/testClaim.test.ts vona/packages-vona/vona-core/src/lib/core/testClaimFilesystem.test.ts vona/packages-vona/vona-core/src/lib/framework/bootstrap.test.ts vona/packages-vona/vona-core/src/lib/framework/useApp.test.ts vona/packages-cli/cli-set-api/test/binBuildEntries.test.ts vona/packages-cli/cli-set-api/test/binTestPatterns.test.ts
+        # Bound concurrent PowerShell/Add-Type cold starts on Windows runners.
+        run: node --test ${{ runner.os == 'Windows' && '--test-concurrency=2' || '' }} scripts/testClaimProcesses.test.ts scripts/runIsolatedTest.test.ts scripts/testClaimCleanup.test.ts scripts/testProcessGuardianWindows.test.ts vona/packages-vona/vona-core/src/lib/core/testClaim.test.ts vona/packages-vona/vona-core/src/lib/core/testClaimFilesystem.test.ts vona/packages-vona/vona-core/src/lib/framework/bootstrap.test.ts vona/packages-vona/vona-core/src/lib/framework/useApp.test.ts vona/packages-cli/cli-set-api/test/binBuildEntries.test.ts vona/packages-cli/cli-set-api/test/binTestPatterns.test.ts
       - name: run A-Pay focused gate
         run: npm run test -- test-pay/test/paymentSession.test.ts test-pay/test/payMock.test.ts test-pay/test/paypalProvider.test.ts test-pay/test/paypalLifecycle.test.ts test-pay/test/stripeProvider.test.ts test-pay/test/stripeLifecycle.test.ts test-pay/test/outbox.test.ts test-pay/test/webhook.test.ts
         working-directory: vona

package/CHANGELOG.md

@@ -1,5 +1,28 @@
 # Changelog
 
+## 5.1.231
+
+### Features
+
+- Add commerce functionality.
+- Add formatting support.
+- Apply feature updates.
+
+### Bug Fixes
+
+- Fix Windows tests.
+- Patch Zod integration.
+
+### Improvements
+
+- Update the controller implementation.
+
+## 5.1.230
+
+### Features
+
+- Apply feature updates (details not specified in commit messages).
+
 ## 5.1.229
 
 ### Features

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "cabloy",
-  "version": "5.1.229",
+  "version": "5.1.231",
   "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": "b883f2b01ab79d51b23e899be43a1c90a821db916490f50c4b28958eedf36b6e",
+      "sha256": "c3233550631e7782834811d3bd73b9b823b0bd429a681cedff85e24128b9ed35",
       "source": "skills/cabloy-frontend-scaffold/SKILL.md",
       "target": ".agents/skills/cabloy-frontend-scaffold/SKILL.md"
     },
@@ -179,14 +179,14 @@
     {
       "adapter": "codex",
       "category": "skill",
-      "sha256": "4f1b4b87b2c0d2ff485c58c8f891189fd3dc7914d66af806c1a808d22cd94124",
+      "sha256": "64615460c3bec383bb0010ddc1412e7fa8f122bbb3f87cfe5c824891fe247e6c",
       "source": "skills/cabloy-spec-execution/references/execution-protocol.md",
       "target": ".agents/skills/cabloy-spec-execution/references/execution-protocol.md"
     },
     {
       "adapter": "codex",
       "category": "skill",
-      "sha256": "17fd93c93c94e5a5b36bcea2c70e779d031b8158b99d03556e8d358e80ad7893",
+      "sha256": "9ec7a5dd8b7c1a5d561a96562ee754c148e1d14db953d3629075af89e38613d3",
       "source": "skills/cabloy-spec-execution/references/status-and-evidence.md",
       "target": ".agents/skills/cabloy-spec-execution/references/status-and-evidence.md"
     },
@@ -431,7 +431,7 @@
     {
       "adapter": "claude",
       "category": "skill",
-      "sha256": "b883f2b01ab79d51b23e899be43a1c90a821db916490f50c4b28958eedf36b6e",
+      "sha256": "c3233550631e7782834811d3bd73b9b823b0bd429a681cedff85e24128b9ed35",
       "source": "skills/cabloy-frontend-scaffold/SKILL.md",
       "target": ".claude/skills/cabloy-frontend-scaffold/SKILL.md"
     },
@@ -515,14 +515,14 @@
     {
       "adapter": "claude",
       "category": "skill",
-      "sha256": "4f1b4b87b2c0d2ff485c58c8f891189fd3dc7914d66af806c1a808d22cd94124",
+      "sha256": "64615460c3bec383bb0010ddc1412e7fa8f122bbb3f87cfe5c824891fe247e6c",
       "source": "skills/cabloy-spec-execution/references/execution-protocol.md",
       "target": ".claude/skills/cabloy-spec-execution/references/execution-protocol.md"
     },
     {
       "adapter": "claude",
       "category": "skill",
-      "sha256": "17fd93c93c94e5a5b36bcea2c70e779d031b8158b99d03556e8d358e80ad7893",
+      "sha256": "9ec7a5dd8b7c1a5d561a96562ee754c148e1d14db953d3629075af89e38613d3",
       "source": "skills/cabloy-spec-execution/references/status-and-evidence.md",
       "target": ".claude/skills/cabloy-spec-execution/references/status-and-evidence.md"
     },
@@ -781,7 +781,7 @@
     {
       "adapter": "cursor",
       "category": "skill",
-      "sha256": "b883f2b01ab79d51b23e899be43a1c90a821db916490f50c4b28958eedf36b6e",
+      "sha256": "c3233550631e7782834811d3bd73b9b823b0bd429a681cedff85e24128b9ed35",
       "source": "skills/cabloy-frontend-scaffold/SKILL.md",
       "target": ".cursor/skills/cabloy-frontend-scaffold/SKILL.md"
     },
@@ -865,14 +865,14 @@
     {
       "adapter": "cursor",
       "category": "skill",
-      "sha256": "4f1b4b87b2c0d2ff485c58c8f891189fd3dc7914d66af806c1a808d22cd94124",
+      "sha256": "64615460c3bec383bb0010ddc1412e7fa8f122bbb3f87cfe5c824891fe247e6c",
       "source": "skills/cabloy-spec-execution/references/execution-protocol.md",
       "target": ".cursor/skills/cabloy-spec-execution/references/execution-protocol.md"
     },
     {
       "adapter": "cursor",
       "category": "skill",
-      "sha256": "17fd93c93c94e5a5b36bcea2c70e779d031b8158b99d03556e8d358e80ad7893",
+      "sha256": "9ec7a5dd8b7c1a5d561a96562ee754c148e1d14db953d3629075af89e38613d3",
       "source": "skills/cabloy-spec-execution/references/status-and-evidence.md",
       "target": ".cursor/skills/cabloy-spec-execution/references/status-and-evidence.md"
     },

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

@@ -281,6 +281,8 @@ Always end with a verification path that matches the scope of the frontend chang
 
 For ordinary frontend changes, prefer a few critical user flows through the existing E2E infrastructure, selected by affected behavior with spec names, tags, or `--grep`. Reuse existing scenarios or extend them narrowly; do not require exhaustive isolated-test matrices, extensive fake dependencies, or custom source-evaluation loaders before delivery. When an actual problem is fixed, add focused regression coverage. Targeted unit or framework tests remain useful when they efficiently prove the behavior being changed; this is not a ban on existing tests or managed test-resource isolation.
 
+Business E2E should primarily assert user actions, visible business outcomes, and persistence after save/reload. Do not turn architecture guidance into default browser assertions about Controller/IoC object identity, model instances, or Query/cache internals. Assert those internals only for an explicit architecture/framework acceptance contract or a focused regression, preferably at the smallest suitable unit, framework, or integration layer. This does not remove architecture requirements or server-side safety checks.
+
 Keep relevant format, lint, and type checks lightweight and scope-dependent. Prepare only the affected flavor's required artifacts for runtime verification. Preserve applicable route, SSR/hydration, authentication, authorization, contract, and acceptance checks; frontend E2E does not replace server-side enforcement. If runtime verification is unavailable or not authorized, report the gap rather than building a substitute harness. See [Frontend Scripts](../../../repo-docs/frontend/scripts.md) for edition-aware preparation and filtered E2E commands.
 
 Shared checks, when applicable, include:

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

@@ -115,6 +115,7 @@ Source ownership: <observed paths and proposed paths>
 Specialist route: <backend/frontend/contract-loop/specialist>
 Safety/contract constraints: <tenant, auth, lifecycle, transaction, SSR, migration, privacy>
 Verification: <exact approved ATP procedures and commands>
+Failure handling: <bounded in-scope diagnosis/repair/reruns, limits, and explicit stop conditions; or stop/report only>
 Evidence: <required revision/environment/procedure/result/redacted artifact>
 Target classes: <observed existing / proposed new / explicitly approved new; design checks, ADR and planned additions>
 Quality gates: <authority audit; chart input eligibility/model/freshness; human approval/evidence>
@@ -147,10 +148,12 @@ Verify the approved connected outcome, not merely supporting helper behavior. On
 
 After user correction, redirect the affected approach rather than rename, relocate, or repackage rejected work. Reassess only the affected scope and preserve valid unchanged approvals; the correction does not itself authorize destructive cleanup or a different feature.
 
+The approved dossier may cover bounded in-scope diagnosis, implementation/test repair, and reruns, including locator corrections. Record the first failure and subsequent attempts, then complete that connected work within the stated limits without another approval for each substep. Do not weaken expected business/security outcomes, skip required checks, or expand scope to obtain a pass. If repair/reruns are not authorized, the limit is reached, or the user explicitly required first-failure stopping, stop and report. This permission is prospective and never overrides an existing narrower approval.
+
 Stop and report rather than guessing when:
 
 - a command to run is not yet observed, or a creation path lacks the explicit approved-new design/ADR/execution boundary; future source absence alone is not a blocker for an approved creation task;
-- a test fails or a required artifact is missing;
+- a failed test or missing required artifact cannot be resolved within the approved repair/rerun boundary, or an explicit stop condition applies;
 - the working tree becomes attribution-ambiguous;
 - a specialist discovers a requirement or contract change;
 - a planned external/destructive operation is needed;

package/repo-agent-governance/skills/cabloy-spec-execution/references/status-and-evidence.md

@@ -24,6 +24,8 @@ Do not use `progress.md` to add requirements, technical contracts, acceptance pr
 
 ## Evidence layout
 
+Retain the minimum sufficient evidence required by the test plan and attribution rules below. Prefer existing test-runner reports, redacted logs, and concise ATP/progress pointers rather than duplicating their contents across receipt layers. Do not create full input snapshots, exhaustive hash manifests, custom evidence verifiers, or multilayer receipts by default; new evidence machinery needs an explicit test-plan requirement or a concrete attribution/integrity risk that existing artifacts cannot address. Preserving source hashes during sanitization does not require inventing a new all-input hashing system. Keep mandatory revision/worktree attribution, actual failures, privacy review, and historical evidence intact unless a separate approved consolidation follows the lifecycle rules below.
+
 Prefer the scalable phase/ATP layout for newly observed proof when the suite permits extensions:
 
 ```text
@@ -104,6 +106,14 @@ A genuinely documentary/design-only task can instead follow `not-started -> in-p
 
 A task may be `implementation-complete` when source work is complete but an ATP, browser check, paired build, release gate, redaction decision, or durable artifact remains. A phase can be verified without implying that a separately defined integration or release phase is verified.
 
+## Evidence lifecycle and consolidation
+
+Retain artifacts for a named ongoing development need, an applicable acceptance/retention requirement, or unique information still needed to explain a result. Creation alone and hypothetical future usefulness are not reasons for permanent retention. Maintained source-controlled business tests provide ongoing regression protection; historical run artifacts record only what happened for their attributed revision and do not prove changed code remains correct.
+
+Keep current delivery state, coverage gaps, and blockers concise in the existing progress/phase records. Retain key acceptance results and only the supporting primary evidence and revision/dirty-worktree attribution they still require. Move durable discoveries needed for further development into the owning source tests, design record, or issue/handoff instead of depending on an artifact chain. Retired one-shot runners, resolved diagnostic detail, repeated inventories/snapshots, and documentary receipts need not remain permanently when they have no such purpose or unique information.
+
+Inspect before deleting or overwriting historical material and obtain explicit approval for the consolidation/deletion scope, including replacement of any earlier unchanged-retention commitment. Preserve meaningful successes, failures, waivers, and gaps truthfully; retain primary proof required by continuing acceptance claims. Update incoming links and state when old hash-based verifiers are retired or no longer applicable rather than recreating their dependency chains. Do not delete by extension or Git status, replace the clutter with a giant archive or a new manifest/checker system, or promote acceptance status. Reorganizing existing evidence alone does not require rerunning business tests; verify affected references and records with existing tools. This guidance does not itself authorize cleanup or override a controlling retention requirement.
+
 ## Historical evidence and supersession
 
 Evidence is revision- and authority-scoped. When source paths, generated artifacts, contracts, scope, or security assumptions change:

package/repo-docs/ai/verification.md

@@ -2,6 +2,28 @@
 
 AI-assisted work should finish with checks that match the scope of the change.
 
+## Proportional verification
+
+Prefer a few critical business flows through existing test infrastructure over exhaustive upfront matrices or bespoke verification harnesses. Preserve applicable security, authorization, tenant isolation, SSR/hydration, data consistency, migration, cleanup, and formal acceptance requirements.
+
+### Assert business outcomes at the business layer
+
+Business E2E should focus on user actions, visible results, and persistence after save/reload, plus essential rejection paths. Architecture guidance is not automatically a requirement to inspect Controller/IoC object identity, model instances, or Query/cache internals in the browser. Test internal invariants when an explicit architecture/framework contract or an actual regression requires them, preferably at the smallest suitable unit, framework, or integration layer. Architecture requirements and server-side enforcement still apply.
+
+### Keep evidence sufficient, not elaborate
+
+Prefer native test reports, redacted logs, and concise ATP/progress links. Retain required revision/worktree attribution, changed-file scope, exact procedures, relevant environment/fixture identities, and observed outcomes, including failures. Do not introduce full input snapshots, exhaustive hash manifests, custom evidence verifiers, or multiple receipt layers unless the test plan requires them or a concrete attribution/integrity risk cannot be addressed with existing artifacts. Preserve privacy review and historical evidence; simpler future evidence is not permission to delete old records.
+
+Retain artifacts only for a named ongoing development need, an applicable acceptance/retention requirement, or unique information still needed to explain a result—not merely because they were generated or might someday be useful. Maintained source-controlled business tests provide ongoing regression protection; historical logs describe a particular run and cannot prove changed code remains correct. Keep current status and blockers in existing progress/phase records, and move durable discoveries into the owning tests, design record, or issue/handoff. A concise delivery summary plus the few primary artifacts needed to support continuing acceptance claims is preferable to permanent process-file chains.
+
+Historical consolidation requires inspection and explicit approval of the deletion scope, including any change to prior retention commitments. Preserve meaningful outcomes, failures, waivers, gaps, and necessary revision attribution; update links and retire obsolete verifier expectations. Remove redundant snapshots/receipts and one-shot helpers only when their required or unique information is retained elsewhere or no longer needed. Do not substitute a giant archive or another checker system. Evidence reorganization alone needs reference/record checks, not business-test reruns, and never advances acceptance or overrides controlling retention requirements.
+
+### Handle failures within the approved boundary
+
+For specification execution, the approved dossier may include bounded in-scope diagnosis, repair, and reruns, with limits and stop conditions. When covered, record the failure and perform the connected correction without requesting approval for every locator or test-fix substep. Do not weaken business/security expectations to obtain a pass. Stop when the approved repair/rerun boundary is absent or exhausted, an explicit first-failure stop applies, or new scope, authority, dependency, safety, external, or destructive-operation questions require renewed approval. This guidance does not broaden or retrospectively replace an existing approval.
+
+See the canonical `cabloy-frontend-scaffold` verification guidance and the `cabloy-spec-execution` execution-protocol and status-and-evidence references for operational details.
+
 ## Documentation verification
 
 For public docs changes, verify at minimum:

package/repo-docs/backend/model-guide.md

@@ -29,6 +29,7 @@ Representative pattern:
 
 ```typescript
 import { BeanModelBase, Model } from 'vona-module-a-orm';
+
 import { EntityStudent } from '../entity/student.ts';
 
 @Model({ entity: EntityStudent })

package/repo-docs/backend/websocket-usage-guide.md

@@ -63,6 +63,7 @@ Representative structure:
 
 ```typescript
 import type { IDecoratorSocketNamespaceOptions } from 'vona-module-a-socket';
+
 import { BeanSocketNamespaceBase, SocketNamespace } from 'vona-module-a-socket';
 
 declare module 'vona-module-a-socket' {
@@ -242,6 +243,7 @@ import type {
   ISocketConnectionExecute,
 } from 'vona-module-a-socket';
 import type { WebSocket } from 'ws';
+
 import { BeanBase } from 'vona';
 import { SocketConnection } from 'vona-module-a-socket';
 
@@ -284,6 +286,7 @@ Representative generated shape:
 import type { Next } from 'vona';
 import type { IDecoratorSocketPacketOptions, ISocketPacketExecute } from 'vona-module-a-socket';
 import type { WebSocket } from 'ws';
+
 import { BeanBase } from 'vona';
 import { SocketPacket } from 'vona-module-a-socket';
 

package/repo-docs/frontend/controller-boundary-guide.md

@@ -88,8 +88,8 @@ static $componentOptions: IComponentOptions = {
 Application configuration supplies the shared renderer contract:
 
 ```ts
-import type { ZovaContext } from 'zova';
 import type { VNodeChild } from 'vue';
+import type { ZovaContext } from 'zova';
 
 config.boundary = {
   loading: {

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

@@ -138,9 +138,10 @@ In practice, Zova can still preserve the ergonomic class-based development exper
 Use a getter when injection arguments must be prepared dynamically. The getter must explicitly identify the target bean with `beanFullName`; `usePrepareArg(...)` supplies initialization arguments only and does not resolve the target bean.
 
 ```typescript
-import { Use, usePrepareArg } from 'zova';
 import type { ServiceSsrLayout } from 'zova-module-home-base';
 
+import { Use, usePrepareArg } from 'zova';
+
 class ControllerLayout {
   @Use({ beanFullName: 'home-base.service.ssrLayout' })
   get $$serviceSsrLayout(): ServiceSsrLayout {

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

@@ -115,6 +115,7 @@ and `.jsx` for a `.tsx` target:
 
 ```ts
 import type { ModelStudent } from '../model/student.js';
+
 import { RenderCard } from './render.card.jsx';
 ```
 

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

@@ -70,6 +70,8 @@ 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.
+
 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.
 
 In both nested workspaces, `npm run tsc` delegates to `npm run tsc:native`. Native and legacy checks first run `npm run prerun`, then invoke the selected compiler with incremental caching disabled. Root workspace aliases delegate to these scripts too, so dependency and generated metadata preparation is not bypassed. Each workspace's `prerun` runs only its `:tools:deps` command; it does not call `tsc`, avoiding recursive script execution. Preparation may refresh generated metadata or dependency manifests and install changed dependencies, while the compiler step itself emits no declarations or build-info files.

package/vona/env/.env

@@ -94,6 +94,7 @@ HOME_USER_BUILTIN_ROLE_SYSTEM_ADMIN_SITE_IDS = *
 
 # auth
 
+AUTH_USEMOCKFORDEV = true
 AUTH_GITHUB_CLIENTID =
 AUTH_GITHUB_CLIENTSECRET =
 

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

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

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

@@ -1,6 +1,6 @@
 {
   "name": "@cabloy/zod-query",
-  "version": "2.1.13",
+  "version": "2.1.14",
   "gitHead": "a79189b882c17af5911573896a781bbb0046d37d",
   "description": "zod-query",
   "keywords": [

package/vona/packages-utils/zod-query/src/lib/query.ts

@@ -10,13 +10,16 @@ interface IParsePayload {
 }
 
 let ZodMetadata: any;
-export function setParseAdapter(zodMetadata: any) {
+let shouldAdapt: (() => boolean) | undefined;
+export function setParseAdapter(zodMetadata: any, policy?: () => boolean) {
   ZodMetadata = zodMetadata;
+  shouldAdapt = policy;
   (z.core as any).setParseAdapter(__parseAdapter);
 }
 
 function __parseAdapter(inst: z.ZodType, parse) {
   return (payload: IParsePayload, _) => {
+    if (shouldAdapt?.() === false) return parse(payload, _);
     const type = inst.type;
     switch (type) {
       case 'string':

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

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

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

@@ -1,6 +1,6 @@
 {
   "name": "vona-core",
-  "version": "5.1.50",
+  "version": "5.1.51",
   "gitHead": "a79189b882c17af5911573896a781bbb0046d37d",
   "description": "vona",
   "keywords": [

package/vona/packages-vona/vona-core/src/lib/bean/type.ts

@@ -7,9 +7,9 @@ import type { TypeErrorsInternal } from './resource/error/errorInternal.ts';
 export interface IBeanRecordGlobal {}
 export interface IBeanRecordGeneral {}
 export type TypeBeanRecordGeneralSelector<SCENE extends keyof IBeanSceneRecord> = {
-  [K in keyof IBeanRecordGeneral as K extends `${string}.${SCENE}.${string}`
-    ? K
-    : never]: IBeanRecordGeneral[K];
+  [
+    K in keyof IBeanRecordGeneral as K extends `${string}.${SCENE}.${string}` ? K : never
+  ]: IBeanRecordGeneral[K];
 };
 export type TypeBeanRecordGeneralSelectorKeys<SCENE extends keyof IBeanSceneRecord> =
   keyof TypeBeanRecordGeneralSelector<SCENE>;