cabloy 5.1.224 → 5.1.226

package/.cabloy-version

@@ -1 +1 @@
-5.1.224
+5.1.226

package/.github/workflows/vona-tsc.yml

@@ -24,5 +24,5 @@ jobs:
         run: npm run init
       - name: typecheck runner tests
         run: npm run test:typecheck
-      - name: legacy typecheck
-        run: npm run tsc:legacy
+      - name: typecheck
+        run: npm run tsc

package/CHANGELOG.md

@@ -1,5 +1,34 @@
 # Changelog
 
+## 5.1.226
+
+### Features
+
+- Add rules.
+
+### Bug Fixes
+
+- Fix module glob handling on Windows.
+- Correct issues in `test.ts`.
+
+### Improvements
+
+- Refactor TypeScript compilation code.
+
+## 5.1.225
+
+### Features
+
+- Apply feature updates.
+
+### Bug Fixes
+
+- Fix test CI.
+
+### Improvements
+
+- Update the pnpm version.
+
 ## 5.1.224
 
 ### Features

package/CONTRIBUTING.md

@@ -11,7 +11,7 @@ Contributions to Cabloy Basic source, tests, tooling, and documentation are welc
 
 ## Set up a development checkout
 
-You need Git, Node.js `>=24.4.0`, pnpm `>=11.5.2`, Redis `>=7.2.6`, and one documented development database baseline: SQLite, MySQL `>=8`, or PostgreSQL `>=16`. SQLite setups using `better-sqlite3` may also require a native build toolchain for `node-gyp`.
+You need Git, Node.js `>=24.4.0`, pnpm `>=12.14.0`, Redis `>=7.2.6`, and one documented development database baseline: SQLite, MySQL `>=8`, or PostgreSQL `>=16`. SQLite setups using `better-sqlite3` may also require a native build toolchain for `node-gyp`.
 
 ```bash
 git clone https://github.com/cabloy/cabloy.git
@@ -21,7 +21,7 @@ npm run init
 
 `npm run init` is more than a package install: it installs multiple workspaces, prepares generated local configuration, initializes and synchronizes Vona and Zova, and generates required frontend and backend artifacts. Run it intentionally rather than as a retry for an unrelated narrow change.
 
-CI workflows run after pushes to `main`; do not assume that every pull request is automatically validated. The SQLite unit-test and Chromium Basic/Commerce E2E workflows configure Ubuntu, Windows, and macOS with Node.js 24 and pnpm 11.5.2. Matrix configuration alone is not proof that the platform gates or all six Basic/Commerce E2E combinations passed. For maintained edition and onboarding guidance, see [Cabloy Editions](https://cabloy.com/editions/overview#cabloy-basic).
+CI workflows run after pushes to `main`; do not assume that every pull request is automatically validated. The SQLite unit-test and Chromium Basic/Commerce E2E workflows configure Ubuntu, Windows, and macOS with Node.js 24 and pnpm 12.14.0. Matrix configuration alone is not proof that the platform gates or all six Basic/Commerce E2E combinations passed. For maintained edition and onboarding guidance, see [Cabloy Editions](https://cabloy.com/editions/overview#cabloy-basic).
 
 ## Develop and validate
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "cabloy",
-  "version": "5.1.224",
+  "version": "5.1.226",
   "gitHead": "2c5c19284bab738e492856189acb6fad74b8a7b7",
   "description": "A Node.js fullstack framework",
   "keywords": [
@@ -50,15 +50,9 @@
     "contract:generate:isolated": "node scripts/generateOpenapiIsolated.ts",
     "test:docs:e2e": "npm run docs:build && playwright test --config repo-e2e/docs/playwright.config.ts",
     "db:reset": "cd vona && npm run db:reset",
-    "tsc": "npm run tsc:native",
-    "tsc:force": "npm run tsc:zova:native && npm run tsc:vona:native:force",
+    "tsc": "npm run tsc:zova && npm run tsc:vona",
     "tsc:zova": "pnpm --dir zova run tsc",
-    "tsc:native": "npm run tsc:zova:native && npm run tsc:vona:native",
-    "tsc:legacy": "npm run tsc:zova:legacy && pnpm --dir vona run tsc:legacy",
-    "tsc:zova:native": "node scripts/typecheck.ts native zova --noEmit --incremental false --project tsconfig.vue-tsc.json",
-    "tsc:zova:legacy": "node scripts/typecheck.ts typescript zova --noEmit --incremental false --project tsconfig.vue-tsc.json",
-    "tsc:vona:native": "pnpm --dir vona run tsc:native",
-    "tsc:vona:native:force": "pnpm --dir vona run tsc:native:force",
+    "tsc:vona": "pnpm --dir vona run tsc",
     "test:typecheck": "node --test scripts/typecheck.test.ts",
     "deps:vona": "pnpm --dir vona run vona :tools:deps",
     "deps:zova": "pnpm --dir zova run zova :tools:deps",
@@ -116,7 +110,7 @@
   },
   "engines": {
     "node": ">=24.4.0",
-    "pnpm": ">=11.5.2"
+    "pnpm": ">=12.14.0"
   },
   "packageManager": "pnpm@12.14.0"
 }

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

@@ -179,7 +179,7 @@
     {
       "adapter": "codex",
       "category": "skill",
-      "sha256": "044824fcfceff8153b722b8239d81d939286cb05ec03f75e78cfd03afe465f5a",
+      "sha256": "a7aae017823a738fbf031424bb68b6cd982f0832102dfbe7320eacaf713919f8",
       "source": "skills/cabloy-spec-execution/references/execution-protocol.md",
       "target": ".agents/skills/cabloy-spec-execution/references/execution-protocol.md"
     },
@@ -249,7 +249,7 @@
     {
       "adapter": "codex",
       "category": "skill",
-      "sha256": "846d81a0c8067900c4bcf3b9a854ca831cf4f0d2a184511fc6a01560da3b8dcb",
+      "sha256": "02ef6d9b6ac9f6746508b343281a2160ed55a05039f7c21677e216acde579792",
       "source": "skills/cabloy-spec-generation/SKILL.md",
       "target": ".agents/skills/cabloy-spec-generation/SKILL.md"
     },
@@ -515,7 +515,7 @@
     {
       "adapter": "claude",
       "category": "skill",
-      "sha256": "044824fcfceff8153b722b8239d81d939286cb05ec03f75e78cfd03afe465f5a",
+      "sha256": "a7aae017823a738fbf031424bb68b6cd982f0832102dfbe7320eacaf713919f8",
       "source": "skills/cabloy-spec-execution/references/execution-protocol.md",
       "target": ".claude/skills/cabloy-spec-execution/references/execution-protocol.md"
     },
@@ -585,7 +585,7 @@
     {
       "adapter": "claude",
       "category": "skill",
-      "sha256": "846d81a0c8067900c4bcf3b9a854ca831cf4f0d2a184511fc6a01560da3b8dcb",
+      "sha256": "02ef6d9b6ac9f6746508b343281a2160ed55a05039f7c21677e216acde579792",
       "source": "skills/cabloy-spec-generation/SKILL.md",
       "target": ".claude/skills/cabloy-spec-generation/SKILL.md"
     },
@@ -683,7 +683,7 @@
     {
       "adapter": "cursor",
       "category": "policy",
-      "sha256": "b8453cbb90a6b75014615dea5ffb8f8e6b31be1e5c3392c1dc4bc0f4456adb57",
+      "sha256": "27ddaa18de3cd88e11dc20c0ad626fe07d5b6231f08243e3fbece7242dcbdc9a",
       "source": "policies/repository.md",
       "target": ".cursor/rules/cabloy-governance.mdc"
     },
@@ -865,7 +865,7 @@
     {
       "adapter": "cursor",
       "category": "skill",
-      "sha256": "044824fcfceff8153b722b8239d81d939286cb05ec03f75e78cfd03afe465f5a",
+      "sha256": "a7aae017823a738fbf031424bb68b6cd982f0832102dfbe7320eacaf713919f8",
       "source": "skills/cabloy-spec-execution/references/execution-protocol.md",
       "target": ".cursor/skills/cabloy-spec-execution/references/execution-protocol.md"
     },
@@ -935,7 +935,7 @@
     {
       "adapter": "cursor",
       "category": "skill",
-      "sha256": "846d81a0c8067900c4bcf3b9a854ca831cf4f0d2a184511fc6a01560da3b8dcb",
+      "sha256": "02ef6d9b6ac9f6746508b343281a2160ed55a05039f7c21677e216acde579792",
       "source": "skills/cabloy-spec-generation/SKILL.md",
       "target": ".cursor/skills/cabloy-spec-generation/SKILL.md"
     },
@@ -1005,14 +1005,14 @@
     {
       "adapter": "codex",
       "category": "policy",
-      "sha256": "18d072d31b706f8eadda5d757ee3db7d69c4a7ea5e4c14dc33ab3ac307ae89e0",
+      "sha256": "e5929a9b3fa63d76faa596fcd24a9faa4fc8bcadd3eae2e99507ac0b33567efe",
       "source": "policies/repository.md",
       "target": "AGENTS.md"
     },
     {
       "adapter": "claude",
       "category": "policy",
-      "sha256": "18d072d31b706f8eadda5d757ee3db7d69c4a7ea5e4c14dc33ab3ac307ae89e0",
+      "sha256": "e5929a9b3fa63d76faa596fcd24a9faa4fc8bcadd3eae2e99507ac0b33567efe",
       "source": "policies/repository.md",
       "target": "CLAUDE.md"
     }

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

@@ -71,6 +71,8 @@ Before inventing a custom implementation path:
 - Treat hooks, permissions, local settings, credentials, MCP registration, command discovery, and automatic command execution as platform-specific integrations, not portable rule or skill capabilities.
 - Plan to resolve named blockers for a bounded increment, not every future detail. Define finite exit criteria, batch related decisions, and require new facts, decision value, or explicit blocker reduction for further planning; do not substitute repeated refinement for delivery.
 - Scope blockers to their actual dependency branches and surface meaningful, independently verifiable implementation candidates elsewhere without executing them unapproved. Once the selected increment is ready, request missing execution approval or proceed within existing unchanged approval; do not repeatedly reconfirm the same scope. Preserve security gates and separate runtime evidence/release requirements; neither a planning-round quota nor empty scaffolding justifies bypass or completion.
+- Prefer the smallest connected slice that delivers the approved business, framework, or tooling outcome. Justify new foundations, abstractions, and defensive mechanisms by a named existing or approved-scope consumer, or a concrete material risk; hypothetical reuse and isolated passing helper tests are not sufficient justification.
+- Stop optional refinement once the approved outcome and required checks are satisfied. After user correction, redirect the approach rather than rename or repackage rejected work; correction does not authorize unrelated scope, destructive cleanup, or bypassing security and acceptance gates.
 - After implementation, do not launch broad reviews automatically; when review is needed, scope it to the current diff and report only high-confidence issues.
 - Sanitize machine-local paths before retaining or sharing evidence: preserve useful repository-relative locations, failures, exit codes, and source hashes; check the tool's supported coverage and manually review remaining sensitive data. Path sanitization is not secret scanning or acceptance proof.
 - Do not modify shared environment identity or ports merely to bypass a busy resource. For intentional parallel worktree setup, follow `repo-docs/fullstack/parallel-worktree-environment.md`; otherwise wait for the shared resource or ask the user. Create or change worktree-local environment overrides only through the explicitly invoked `cabloy-worktree-environment` skill and its confirmation phase, and only in `vona/env/.env.local` and `zova/env/.env.local`; never modify flavor-, mode-, app-mode-, or runtime-specific `.env.*.local` files. The skill derives the standard `APP_NAME`, `SERVER_LISTEN_PORT`, `DEV_SERVER_PORT`, `DEV_SERVER_HMR_PORT`, and API-derived `API_BASE_URL` tuple only from Git worktree metadata and fixed port baselines; never read or expose `.env*` content while recommending values. Admin and Web are alternative commands using this shared tuple and must not run concurrently in one worktree; use another linked worktree for concurrent use. Detect the active edition before choosing scripts, and never run `npm run init` as an automatic follow-up.

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

@@ -31,7 +31,7 @@ A new wrapper is a planned addition until implementation creates it in the durab
 
 ## 2. Target selection
 
-The normal unit of work is one WBS item. A phase may be selected only when the phase is a finite, explicitly approved batch and the WBS defines its task set and closure boundary.
+The normal unit of work is one WBS item. A phase may be selected only when the phase is a finite, explicitly approved batch and the WBS defines its task set and closure boundary. Use the existing scope and authority description to identify the observable business, framework, or tooling outcome and the minimum connected implementation path that delivers it; include supporting work only where that path or a concrete material risk requires it.
 
 A valid target dossier names:
 
@@ -71,7 +71,7 @@ Before implementation, verify:
 - tenant, identity, authorization, ownership, privacy, lifecycle, transaction, concurrency, idempotency, audit, and recovery constraints are defined for the task’s risk;
 - the requested change does not broaden scope or create a competing persistence, identity, or API authority.
 
-Apply readiness to the selected increment and its real dependency graph. Record each blocker with its affected branch, decision owner and finite closure condition in existing records; keep future refinements and release-only questions separate. Do not require the new implementation's runtime ATP evidence before implementation starts, but retain required predecessor evidence and any specifically mandated pre-implementation qualification. When blocked, surface one meaningful, independently verifiable alternative if available, without executing it unapproved or changing formal dependencies/status to bypass the blocker. A foundation-only subincrement needs concrete integration value, checks and explicit scope approval; it does not complete the parent WBS.
+Apply readiness to the selected increment and its real dependency graph. Record each blocker with its affected branch, decision owner and finite closure condition in existing records; keep future refinements and release-only questions separate. Do not require the new implementation's runtime ATP evidence before implementation starts, but retain required predecessor evidence and any specifically mandated pre-implementation qualification. When blocked, surface one meaningful, independently verifiable alternative if available, without executing it unapproved or changing formal dependencies/status to bypass the blocker. A foundation-only subincrement needs a named existing or approved-scope consumer and integration path, or a concrete invariant, defect, or material risk it addresses, plus checks and explicit scope approval. A planned consumer need not already exist in source, but hypothetical reuse and isolated passing helper tests do not establish integration value. Such work does not complete the parent WBS.
 
 When authority records conflict, stop the affected work. Update the authoritative PRD, SRS, or ADR through `cabloy-spec-generation`, then propagate the change through WBS, ATP, evidence assumptions, and progress. Do not reconcile a conflict by silently editing a downstream status or implementation plan. A return to planning must name the new fact, material authority question or blocker to resolve and its exit condition; do not restart a preparation/review cycle merely to restate accepted direction. Batch related decisions and report stalled convergence if further refinement has no justified new value.
 
@@ -143,6 +143,10 @@ The coordinator may pass the dossier to the specialist; it should not duplicate
 
 Start with the narrowest meaningful check, then execute linked ATP procedures and only the required release gates. Explicitly preserve test-owned fixture cleanup, separate `mockCtx(...)` boundaries for competing Vona operations, synthetic/redacted data, and the test plan’s database/flavor requirements.
 
+Verify the approved connected outcome, not merely supporting helper behavior. Once that outcome and its applicable required checks are satisfied, stop optional abstraction, hardening, and cleanup; report remaining improvements without automatically implementing them. Keep any outstanding acceptance or release gates explicit rather than claiming full completion. This does not waive necessary security, tenant isolation, privacy, lifecycle correctness, migration, or mandatory evidence requirements.
+
+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.
+
 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;

package/repo-agent-governance/skills/cabloy-spec-generation/SKILL.md

@@ -75,7 +75,7 @@ For the next bounded increment, keep a finite blocker/exit checklist in the exis
 
 Before proposing more planning, identify the blocker or material uncertainty it addresses, the new fact or decision value expected, and the exit condition or resulting implementation handoff. If another pass merely restates accepted direction or leaves the same blockers without a justified new approach, report the stalled convergence and recommend a concrete decision, bounded feasibility check or scope disposition instead of another micro-plan. Do not impose a fixed round limit or weaken security requirements to force code.
 
-Apply blockers only along actual dependencies, not to the whole suite by default. Surface one meaningful, independently verifiable implementation candidate on an unaffected branch when available; do not invent one or use empty scaffolding/document counts as progress. A foundation-only increment must have explicit integration value and its own checks, and must not be reported as completion of its parent feature. If none is ready, state the exact reason.
+Apply blockers only along actual dependencies, not to the whole suite by default. Surface one meaningful, independently verifiable implementation candidate on an unaffected branch when available; do not invent one or use empty scaffolding/document counts as progress. Prefer a thin connected slice of the approved business, framework, or tooling outcome over horizontal infrastructure milestones. A foundation-only increment must name an existing or approved-scope consumer and integration path, or a concrete invariant, defect, or material risk it addresses, with checks demonstrating that value; hypothetical reuse and isolated passing helper tests are insufficient justification. A planned consumer need not already exist in source. Such work must not be reported as completion of its parent feature. If none is ready, state the exact reason.
 
 Stop refining when the selected increment's material contracts, dependencies, scope, safety constraints and verification plan are sufficient. Request only missing execution approval, or hand off within existing explicit approval whose scope and conditions remain valid. Reopen settled decisions only for a material change or newly observed risk. Generation/design approval alone still does not authorize implementation; runtime ATP proof and release approval remain later gates, not proof that must already exist for the new implementation to start.
 

package/repo-docs/ai/ai-spec-driven-development.md

@@ -67,7 +67,9 @@ Readiness gates, evidence gates, and release gates are also distinct:
 
 ## Deliver bounded, verified vertical increments
 
-The controlled execution unit is one named WBS item or an explicitly approved finite phase with a defined closure boundary—not an open-ended request to finish a suite or continue automatically.
+The controlled execution unit is one named WBS item or an explicitly approved finite phase with a defined closure boundary—not an open-ended request to finish a suite or continue automatically. Prefer the smallest connected slice that delivers the approved business, framework, or tooling outcome, with supporting work limited to that path and its concrete risks.
+
+For example, a tool integration can demonstrate discovery → guarded invocation → an existing business operation → a bounded result. An unattached configuration helper with passing isolated tests does not establish that flow. The helper can still be a valid increment when it serves a named existing or approved-scope integration, or resolves a concrete defect or material risk; a planned consumer need not already exist in source. This example does not authorize a particular tool or public endpoint.
 
 Before source work begins, an **execution dossier** makes the unit explicit: target and revision, linked authority, dependencies, scope and exclusions, safety and ownership constraints, permitted verification, expected evidence, allowed record updates, blockers, and one next action. After work, a **resumable handoff** records the implemented scope, procedures actually run, resulting evidence and status, any gap or blocker, and exactly one next action.
 
@@ -79,10 +81,12 @@ Planning should resolve the material blockers of the next bounded increment, not
 
 Before adding a planning pass, explain which blocker or material uncertainty it addresses, what new fact or decision value it should provide, and how it ends. If the next pass only restates an accepted direction without a justified new approach to the remaining blockers, report stalled convergence and recommend a concrete decision, bounded feasibility check, or scope disposition. A larger document or another review is not delivery progress by itself.
 
-Blockers follow actual dependencies, not the whole suite by default. A blocked identity integration does not necessarily block an independent capability whose own contracts, dependencies, safety boundary, and verification plan are ready. Conversely, a frontend change that depends on an unresolved response contract cannot bypass that dependency by calling itself an independent increment. Surface a meaningful, independently verifiable candidate for approval when available; if none exists, state why. Foundation-only work is useful only when it has explicit integration value and checks, not merely an empty scaffold presented as feature completion.
+Blockers follow actual dependencies, not the whole suite by default. A blocked identity integration does not necessarily block an independent capability whose own contracts, dependencies, safety boundary, and verification plan are ready. Conversely, a frontend change that depends on an unresolved response contract cannot bypass that dependency by calling itself an independent increment. Surface a meaningful, independently verifiable candidate for approval when available; if none exists, state why. Foundation-only work needs a named existing or approved-scope consumer and integration path, or a concrete invariant, defect, or material risk it addresses, with checks demonstrating that value. Hypothetical future reuse, local elegance, document counts, or isolated passing helper tests are not enough; supporting work must not be presented as parent-feature completion.
 
 Planning is sufficient for an increment when its material contracts, dependencies, scope, safety constraints, and verification plan are settled. At that point, request any missing execution approval or proceed within valid existing approval. Reuse an unchanged approved dossier after checking current revision, worktree attribution, and evidence applicability; a skill handoff, resumed session, or ordinary implementation substep is not a reason to request the same permission again. Material changes, newly observed risks, and the approval's own conditions can require renewed approval; prior approval never covers unrelated tasks or unapproved external/destructive operations.
 
+Convergence also applies during implementation: once the approved outcome and applicable required checks are satisfied, stop optional abstraction, hardening, and cleanup. Report remaining improvements without automatically executing them, and keep outstanding acceptance or release gates explicit. After user correction, redirect the affected approach rather than rename or repackage rejected work; correction does not itself authorize destructive cleanup or a different feature.
+
 This is not a fixed limit on planning rounds or a relaxation of security requirements. Preserve mandatory reviews, predecessor proof, and any specifically required pre-implementation qualification. The new implementation's runtime ATP proof normally follows implementation; it must not become an impossible prerequisite to writing that implementation. Evidence and release gates still control later verification and release claims. A genuine new risk can reopen planning, but the return should name the affected blocker and its exit condition rather than restart open-ended refinement.
 
 ## Contract Loop is complementary

package/repo-docs/backend/quickstart.md

@@ -16,14 +16,14 @@ Use this page when you are contributing backend work in the framework repository
 
 ## Prerequisites
 
-| Name       | Version  |
-| ---------- | -------- |
-| pnpm       | >=11.5.2 |
-| Node.js    | >=24.8.0 |
-| Redis      | >=7.2.6  |
-| Sqlite3    | Built-in |
-| MySQL      | >=8      |
-| Postgresql | >=16     |
+| Name       | Version   |
+| ---------- | --------- |
+| pnpm       | >=12.14.0 |
+| Node.js    | >=24.8.0  |
+| Redis      | >=7.2.6   |
+| Sqlite3    | Built-in  |
+| MySQL      | >=8       |
+| Postgresql | >=16      |
 
 Notes:
 

package/repo-docs/fullstack/quickstart.md

@@ -6,14 +6,14 @@ This guide explains the fastest way to start a Cabloy fullstack project.
 
 Before creating a new Cabloy project, make sure your environment has:
 
-| Name         | Version    |
-| ------------ | ---------- |
-| `pnpm`       | `>=11.5.2` |
-| `Node.js`    | `>=24.4.0` |
-| `Redis`      | `>=7.2.6`  |
-| `SQLite3`    | `Built-in` |
-| `MySQL`      | `>=8`      |
-| `PostgreSQL` | `>=16`     |
+| Name         | Version     |
+| ------------ | ----------- |
+| `pnpm`       | `>=12.14.0` |
+| `Node.js`    | `>=24.4.0`  |
+| `Redis`      | `>=7.2.6`   |
+| `SQLite3`    | `Built-in`  |
+| `MySQL`      | `>=8`       |
+| `PostgreSQL` | `>=16`      |
 
 - `Redis`: powers queue, schedule, startup, broadcast, caching, two-layer cache, and redlock
 - `SQLite3`: if you use `better-sqlite3`, set up `node-gyp` before installing dependencies
@@ -36,9 +36,9 @@ For the Start onboarding distinction, read [Cabloy Editions: Cabloy Start](/edit
 
 If you are not sure which edition you are using or which one to choose, read [Cabloy Editions](/editions/overview).
 
-### pnpm 11 supply-chain protection note
+### pnpm 12 supply-chain protection note
 
-`pnpm` 11 enables the `minimumReleaseAge` supply-chain protection by default. Newly published packages may be blocked for a short time window before `pnpm` allows installation.
+`pnpm` 12 enables the `minimumReleaseAge` supply-chain protection by default. Newly published packages may be blocked for a short time window before `pnpm` allows installation.
 
 This matters for `npm create cabloy` because the command downloads Cabloy from npm and then automatically runs `npm run init`. If your environment blocks newly published packages during that flow, temporarily set `pnpm_config_minimum_release_age=0` for the current shell session and rerun the command.
 
@@ -46,7 +46,7 @@ This matters for `npm create cabloy` because the command downloads Cabloy from n
 
 ```powershell
 $env:pnpm_config_minimum_release_age = "0"
-npm create cabloy
+npm create cabloy@latest
 ```
 
 #### Windows Command Prompt

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

@@ -44,9 +44,8 @@ Cabloy Basic exposes these shared root scripts:
 - `npm run contract:generate:isolated`
 - `npm run db:reset`
 - `npm run tsc`
-- `npm run tsc:force`
-- `npm run tsc:native`
-- `npm run tsc:legacy`
+- `npm run tsc:zova`
+- `npm run tsc:vona`
 - `npm run test:typecheck`
 - `npm run docs:dev`
 - `npm run docs:build`
@@ -58,28 +57,28 @@ Cabloy Basic exposes these shared root scripts:
 
 Cabloy Basic keeps two TypeScript toolchains: root `@typescript/native` is the exact npm alias `npm:typescript@7.0.2`, while classic `typescript` 5.9.3 remains available for compiler-API consumers and existing tooling. The alias changes the dependency name, not the executable name: its package still declares `bin.tsc`, not a separate `native` or `tsgo` command.
 
-Use the explicit root commands to select the verification toolchain:
+Use the root commands to select the workspace scope:
 
-| Root command                         | Scope                                                                                                                              |
-| ------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------- |
-| `npm run tsc` / `npm run tsc:native` | Check Zova, then the complete Vona graph, with native TypeScript; reuse Vona incremental results.                                  |
-| `npm run tsc:force`                  | Check the same scopes with native TypeScript, forcing Vona to rebuild.                                                             |
-| `npm run tsc:legacy`                 | Check the same scopes with classic TypeScript.                                                                                     |
-| `npm run tsc:zova:native`            | Check Zova with native TypeScript.                                                                                                 |
-| `npm run tsc:zova:legacy`            | Check Zova with classic TypeScript.                                                                                                |
-| `npm run tsc:vona:native`            | Check the complete Vona graph with native TypeScript, reusing incremental results.                                                 |
-| `npm run tsc:vona:native:force`      | Force native checking of the complete Vona graph.                                                                                  |
-| `npm run test:typecheck`             | Test compiler selection, argument and failure propagation, Vona graph traversal, and installed compiler versions/API availability. |
+| Root command             | Scope                                                                                                                                                                     |
+| ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `npm run tsc`            | Check Zova, then Vona, through their workspace defaults: single-project, no-emit checks with native TypeScript and incremental caching disabled.                          |
+| `npm run tsc:zova`       | Check Zova through its workspace `tsc` script.                                                                                                                            |
+| `npm run tsc:vona`       | Check Vona through its workspace `tsc` script.                                                                                                                            |
+| `npm run test:typecheck` | Test compiler selection, argument and failure propagation, daily-check configuration/scripts, CLI command registration, and installed compiler versions/API availability. |
 
-`scripts/typecheck.ts` delegates to the package-resolving runner in `vona/packages-cli/cli-set-api/src/lib/typescriptRunner.ts`. It resolves `@typescript/native` or `typescript` from the target workspace, reads that package's `bin.tsc`, and invokes it directly with Node. Native Vona checks use the same runner. This avoids relying on `PATH` or a shared `.bin/tsc` name to identify the selected compiler.
+`scripts/typecheck.ts` delegates to the package-resolving runner in `scripts/typescriptRunner.ts`. It resolves `@typescript/native` or `typescript` from the target workspace, reads that package's `bin.tsc`, and invokes it directly with Node. Native Vona checks use the same runner. This avoids relying on `PATH` or a shared `.bin/tsc` name to identify the selected compiler.
 
-Both explicit Zova checks use `tsconfig.vue-tsc.json` with `--noEmit --incremental false`. Native Vona checks retain build mode (`-b`), visiting the project, every local suite, and every standalone local module, rather than replacing that graph with a root-only no-emit check. The default native check omits `--force`; `tsc:force` adds it without changing the traversal scope. Zova's cache policy is unchanged, so the force distinction applies to Vona. The explicit legacy check continues to force a rebuild. Vona's emitted files and build-info artifacts are shared between compiler versions: run native and legacy checks **serially**, and coordinate them with other operations writing the same artifacts. After switching from TS5 back to native, run `npm run tsc:force` before relying on incremental checks. Forced rebuilding prevents one compiler's incremental state from standing in for verification by the other; it does not isolate their output.
+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.
 
-Root `npm run tsc` delegates to incremental `tsc:native` for daily development; use `tsc:force` for full forced verification and `tsc:legacy` for comparison or fallback. The nested Vona and Zova `tsc` defaults, frontend `prerun`, build commands, package publish emitters, and REST emitters remain unchanged. Classic TypeScript remains installed for compiler-JavaScript-API consumers, including SWC configuration loading, Rollup integration, and OpenAPI generation; the existing REST native-preview emitter dependency is also retained.
+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.
 
-The native alias is installed at the repository root, not in either nested workspace. Run `pnpm install` at the root after updating the checkout; a missing alias fails with an installation diagnostic rather than silently selecting the legacy compiler. A standalone Vona project using `--compiler=native` must install that alias in its project or an ancestor. Do not use a bare root `tsc`/`pnpm exec tsc` to choose a compiler, because both packages declare the same binary name.
+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.
 
-The `vona-tsc` CI workflow runs root `npm run test:typecheck`, then root `npm run tsc:force`, after its existing initialization. The root release workflow also runs `tsc:force` before versioning/publishing (excluding changelog-only and GitHub-release-only runs), and its post-release compensation verification uses the same forced entrypoint. These gates retain forced verification even though daily checking is incremental. Check the active repository before assuming the same aliases or commands exist in Cabloy Start.
+Zova development and build entrypoints call `npm run prerun` before Quasar or REST emission to prepare dependencies and generated metadata without automatically running a typecheck. Run `npm run tsc`, `npm run tsc:native`, or `npm run tsc:legacy` explicitly inside the Zova workspace when source typechecking is needed. The former multi-project Vona CLI command `:bin:tsc` has been removed; use the project checking scripts instead. Module publication configurations and REST emitters are unchanged. Classic TypeScript remains installed for compiler-JavaScript-API consumers, including SWC configuration loading, Rollup integration, and OpenAPI generation; the existing REST native-preview emitter dependency is also retained.
+
+The native alias is installed at the repository root, not in either nested workspace. Run `pnpm install` at the root after updating the checkout; a missing alias fails with an installation diagnostic rather than silently selecting the legacy compiler. Do not use a bare root `tsc`/`pnpm exec tsc` to choose a compiler, because both packages declare the same binary name.
+
+The `vona-tsc` CI workflow runs root `npm run test:typecheck`, then root `npm run tsc`, after its existing initialization. The root release workflow runs `npm run tsc` before versioning/publishing (excluding changelog-only and GitHub-release-only runs), and its post-release compensation verification uses the same default entrypoint. CI and release checks therefore both use native TypeScript source checks through the workspace defaults, with incremental caching disabled. Check the active repository before assuming the same aliases or commands exist in Cabloy Start.
 
 ## Test isolation and development data {#test-isolation-and-development-data}
 
@@ -137,7 +136,7 @@ For deliberate **dev-mode** database preparation, `npm run db:reset` is a separa
 
 <span id="native-windows-unit-tests"></span>
 
-The Cabloy Basic SQLite unit-test workflow and Chromium application E2E workflow configure native Windows runners alongside Ubuntu and macOS. Each E2E suite has its own three-OS matrix with `fail-fast: false`, Node.js 24, pnpm 11.5.2, and SQLite. Basic selects `cabloy-basic home-user-account`; Commerce selects `a-commerce markdown` and retains its explicit Commerce artifact build and Vona dependency synchronization. A configured matrix is not proof of a successful run: inspect the focused gates, real Windows Chromium lifecycle regressions, and all six hosted Basic/Commerce suite-and-OS results before claiming verified platform compatibility.
+The Cabloy Basic SQLite unit-test workflow and Chromium application E2E workflow configure native Windows runners alongside Ubuntu and macOS. Each E2E suite has its own three-OS matrix with `fail-fast: false`, Node.js 24, pnpm 12.14.0, and SQLite. Basic selects `cabloy-basic home-user-account`; Commerce selects `a-commerce markdown` and retains its explicit Commerce artifact build and Vona dependency synchronization. A configured matrix is not proof of a successful run: inspect the focused gates, real Windows Chromium lifecycle regressions, and all six hosted Basic/Commerce suite-and-OS results before claiming verified platform compatibility.
 
 On Windows, the managed test entrypoints require Node.js with npm, PowerShell 7 (`pwsh.exe` on `PATH`), local NTFS storage, and a reachable Redis service. E2E also requires Playwright's Chromium installation and current SSR/REST artifacts with Vona dependencies synchronized. PowerShell is an internal helper dependency, not a required interactive terminal. From either CMD or PowerShell, use the same public commands:
 

package/scripts/init.ts

@@ -19,7 +19,7 @@ const ROOT_DIR = resolve(__dirname, '..');
 const VONA_DIR = resolve(ROOT_DIR, 'vona');
 const ZOVA_DIR = resolve(ROOT_DIR, 'zova');
 const REPO_DOCS_DIR = resolve(ROOT_DIR, 'repo-docs');
-const PNPM_VERSION = '11.5.2';
+const PNPM_VERSION = '12.14.0';
 const VERSION_MARKER_FILE = '.cabloy-version';
 
 // --- Helpers ---
@@ -52,11 +52,10 @@ function pnpmInstall(cwd = ROOT_DIR): void {
 
 function checkPnpm(): void {
   const version = execQuiet('pnpm --version').trimEnd();
-  const [major, minor, patch] = version.split('.').map(item => Number.parseInt(item, 10) || 0);
-  const lowerMajor = major < 11;
-  const lowerMinor = major === 11 && minor < 5;
-  const lowerPatch = major === 11 && minor === 5 && patch < 2;
-  if (lowerMajor || lowerMinor || lowerPatch) {
+  const [major, minor] = version.split('.').map(item => Number.parseInt(item, 10) || 0);
+  const lowerMajor = major < 12;
+  const lowerMinor = major === 12 && minor < 14;
+  if (lowerMajor || lowerMinor) {
     throw new Error(`pnpm should >= ${PNPM_VERSION}, current: ${version}`);
   }
 }