cabloy 5.1.221 → 5.1.222

package/.cabloy-version

@@ -1 +1 @@
-5.1.221
+5.1.222

package/CHANGELOG.md

@@ -1,5 +1,16 @@
 # Changelog
 
+## 5.1.222
+
+### Features
+
+- Apply feature updates, including MCP-related changes.
+
+### Improvements
+
+- Add end-to-end tests and email-sending tests.
+- Update the pnpm lockfile.
+
 ## 5.1.221
 
 ### Features

package/package.json

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

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

@@ -18,14 +18,14 @@
     {
       "adapter": "codex",
       "category": "skill",
-      "sha256": "73e068093dfc88d57dc484582e0c20b1dd5d48bdbe12e860ac6343a64883cf5e",
+      "sha256": "11a02f57b7fbccc004e2a8d9cacb0e2af9e6f9a881e53852b9d74cb6309f4fc3",
       "source": "skills/cabloy-backend-scaffold/references/follow-up-checklist.md",
       "target": ".agents/skills/cabloy-backend-scaffold/references/follow-up-checklist.md"
     },
     {
       "adapter": "codex",
       "category": "skill",
-      "sha256": "e874fe06a1d9a0c5d50fcb3184e7c616e3f4e0b7d8ebada2f165119110955ede",
+      "sha256": "45ac18019b253a8313b5a229528f6373f1a6814d90f27a70783f787b23936aa0",
       "source": "skills/cabloy-backend-scaffold/SKILL.md",
       "target": ".agents/skills/cabloy-backend-scaffold/SKILL.md"
     },
@@ -81,7 +81,7 @@
     {
       "adapter": "codex",
       "category": "skill",
-      "sha256": "409edb90ce79c81752dffd3b4ded365e9551259d5fc194859200471d43608f09",
+      "sha256": "2bdeea2869862d1e52300da6b946b4b4cd2489b9271144e94e85d8377175c6af",
       "source": "skills/cabloy-frontend-scaffold/references/follow-up-checklist.md",
       "target": ".agents/skills/cabloy-frontend-scaffold/references/follow-up-checklist.md"
     },
@@ -95,7 +95,7 @@
     {
       "adapter": "codex",
       "category": "skill",
-      "sha256": "edd0014d787e03f9f37df9e67e42bf14bef9f8ca629e3aa3633d7130364020e7",
+      "sha256": "af5f73b8c1d52bf0bdd0464c9b29c1f9eccdddece2142da73657d164ab927f95",
       "source": "skills/cabloy-frontend-scaffold/SKILL.md",
       "target": ".agents/skills/cabloy-frontend-scaffold/SKILL.md"
     },
@@ -354,14 +354,14 @@
     {
       "adapter": "claude",
       "category": "skill",
-      "sha256": "73e068093dfc88d57dc484582e0c20b1dd5d48bdbe12e860ac6343a64883cf5e",
+      "sha256": "11a02f57b7fbccc004e2a8d9cacb0e2af9e6f9a881e53852b9d74cb6309f4fc3",
       "source": "skills/cabloy-backend-scaffold/references/follow-up-checklist.md",
       "target": ".claude/skills/cabloy-backend-scaffold/references/follow-up-checklist.md"
     },
     {
       "adapter": "claude",
       "category": "skill",
-      "sha256": "e874fe06a1d9a0c5d50fcb3184e7c616e3f4e0b7d8ebada2f165119110955ede",
+      "sha256": "45ac18019b253a8313b5a229528f6373f1a6814d90f27a70783f787b23936aa0",
       "source": "skills/cabloy-backend-scaffold/SKILL.md",
       "target": ".claude/skills/cabloy-backend-scaffold/SKILL.md"
     },
@@ -417,7 +417,7 @@
     {
       "adapter": "claude",
       "category": "skill",
-      "sha256": "409edb90ce79c81752dffd3b4ded365e9551259d5fc194859200471d43608f09",
+      "sha256": "2bdeea2869862d1e52300da6b946b4b4cd2489b9271144e94e85d8377175c6af",
       "source": "skills/cabloy-frontend-scaffold/references/follow-up-checklist.md",
       "target": ".claude/skills/cabloy-frontend-scaffold/references/follow-up-checklist.md"
     },
@@ -431,7 +431,7 @@
     {
       "adapter": "claude",
       "category": "skill",
-      "sha256": "edd0014d787e03f9f37df9e67e42bf14bef9f8ca629e3aa3633d7130364020e7",
+      "sha256": "af5f73b8c1d52bf0bdd0464c9b29c1f9eccdddece2142da73657d164ab927f95",
       "source": "skills/cabloy-frontend-scaffold/SKILL.md",
       "target": ".claude/skills/cabloy-frontend-scaffold/SKILL.md"
     },
@@ -683,7 +683,7 @@
     {
       "adapter": "cursor",
       "category": "policy",
-      "sha256": "050769a0c11ce7706b6dc0d526aad3ecd9d5a2ca1edd4d3eab699aac5eec9996",
+      "sha256": "b8453cbb90a6b75014615dea5ffb8f8e6b31be1e5c3392c1dc4bc0f4456adb57",
       "source": "policies/repository.md",
       "target": ".cursor/rules/cabloy-governance.mdc"
     },
@@ -704,14 +704,14 @@
     {
       "adapter": "cursor",
       "category": "skill",
-      "sha256": "73e068093dfc88d57dc484582e0c20b1dd5d48bdbe12e860ac6343a64883cf5e",
+      "sha256": "11a02f57b7fbccc004e2a8d9cacb0e2af9e6f9a881e53852b9d74cb6309f4fc3",
       "source": "skills/cabloy-backend-scaffold/references/follow-up-checklist.md",
       "target": ".cursor/skills/cabloy-backend-scaffold/references/follow-up-checklist.md"
     },
     {
       "adapter": "cursor",
       "category": "skill",
-      "sha256": "e874fe06a1d9a0c5d50fcb3184e7c616e3f4e0b7d8ebada2f165119110955ede",
+      "sha256": "45ac18019b253a8313b5a229528f6373f1a6814d90f27a70783f787b23936aa0",
       "source": "skills/cabloy-backend-scaffold/SKILL.md",
       "target": ".cursor/skills/cabloy-backend-scaffold/SKILL.md"
     },
@@ -767,7 +767,7 @@
     {
       "adapter": "cursor",
       "category": "skill",
-      "sha256": "409edb90ce79c81752dffd3b4ded365e9551259d5fc194859200471d43608f09",
+      "sha256": "2bdeea2869862d1e52300da6b946b4b4cd2489b9271144e94e85d8377175c6af",
       "source": "skills/cabloy-frontend-scaffold/references/follow-up-checklist.md",
       "target": ".cursor/skills/cabloy-frontend-scaffold/references/follow-up-checklist.md"
     },
@@ -781,7 +781,7 @@
     {
       "adapter": "cursor",
       "category": "skill",
-      "sha256": "edd0014d787e03f9f37df9e67e42bf14bef9f8ca629e3aa3633d7130364020e7",
+      "sha256": "af5f73b8c1d52bf0bdd0464c9b29c1f9eccdddece2142da73657d164ab927f95",
       "source": "skills/cabloy-frontend-scaffold/SKILL.md",
       "target": ".cursor/skills/cabloy-frontend-scaffold/SKILL.md"
     },
@@ -1005,14 +1005,14 @@
     {
       "adapter": "codex",
       "category": "policy",
-      "sha256": "4056d436da610d0438fe8aa4c873cd23442613de800799b358b1c1a2483d7402",
+      "sha256": "18d072d31b706f8eadda5d757ee3db7d69c4a7ea5e4c14dc33ab3ac307ae89e0",
       "source": "policies/repository.md",
       "target": "AGENTS.md"
     },
     {
       "adapter": "claude",
       "category": "policy",
-      "sha256": "4056d436da610d0438fe8aa4c873cd23442613de800799b358b1c1a2483d7402",
+      "sha256": "18d072d31b706f8eadda5d757ee3db7d69c4a7ea5e4c14dc33ab3ac307ae89e0",
       "source": "policies/repository.md",
       "target": "CLAUDE.md"
     }

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

@@ -106,4 +106,5 @@ Before inventing a custom implementation path:
 - For docs changes: run the docs build and verify links/navigation where practical.
 - For code-generation or workflow guidance changes: verify that the referenced scripts and command families still exist.
 - For code changes: prefer the narrowest meaningful verification first, then use shared root scripts when broader confidence is needed.
+- Keep frontend and backend verification proportional to the change: cover critical behavior using existing infrastructure, not exhaustive upfront test matrices or bespoke source-evaluation/mock harnesses. Prefer a few critical-flow E2E scenarios for frontend work and the smallest meaningful service/model/API/integration tests for backend work; add focused regressions for actual defects. Preserve applicable security, SSR, data-consistency, migration, and acceptance requirements.
 - Any change to `meta.version.ts` requires running `npm run test` so the test database is reinitialized and schema/data consistency issues surface early.

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

@@ -237,7 +237,11 @@ Especially relevant pages include:
 
 Always end with a verification path that matches the scope of the backend change.
 
-Typical shared checks include:
+Prefer focused tests of critical business behavior using the existing Vona testing infrastructure. Choose the smallest meaningful service/model, controller/API, or integration boundary for the changed contract; browser E2E is not the default backend test layer. Avoid exhaustive upfront mock/fake matrices and bespoke harnesses. Add focused regression coverage when actual defects are fixed; targeted unit and framework tests remain useful when they directly prove new or changed behavior.
+
+Keep relevant static checks scope-dependent and preserve applicable authentication/authorization, tenant-isolation, transaction, concurrency, idempotency, migration, and acceptance requirements. These are selected by the affected behavior, not a mandatory matrix for every change. Retain `mockCtx(...)` ownership, test-resource isolation, precise fixture cleanup, and the required `npm run test` after `meta.version.ts` changes. Missing runtime access is a reported gap, not permission to reset resources or invent substitute test machinery. See [Unit Testing](../../../repo-docs/backend/unit-testing.md).
+
+Shared checks, when applicable, include:
 
 - `npm run test`
 - `npm run tsc`

package/repo-agent-governance/skills/cabloy-backend-scaffold/references/follow-up-checklist.md

@@ -79,11 +79,13 @@ When the active edition and installed modules provide `@Passport.rbac(...)` and
 
 ## Verification follow-up
 
-- unit tests
-- `db:reset` or migration verification
-- `npm run test`
-- `npm run tsc`
-- `npm run build`
+- focused critical-business-path tests using existing Vona service/model, controller/API, or integration infrastructure; browser E2E is not the default backend layer
+- focused regressions for actual defects; avoid exhaustive upfront mock/fake matrices and bespoke harnesses
+- applicable authentication/authorization, tenant-isolation, transaction, concurrency, idempotency, migration, and acceptance checks
+- relevant format, lint, and type checks using the smallest supported scope
+- `npm run test`, including the required run after `meta.version.ts` changes
+- migration verification when affected; `db:reset` remains destructive and requires explicit approval
+- `npm run build` only when the affected artifact or acceptance boundary requires it
 
 ## Escalation rule
 

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

@@ -278,7 +278,11 @@ Especially relevant pages include:
 
 Always end with a verification path that matches the scope of the frontend change.
 
-Typical shared checks include:
+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.
+
+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:
 
 - `npm run tsc`
 - `npm run build:zova`

package/repo-agent-governance/skills/cabloy-frontend-scaffold/references/follow-up-checklist.md

@@ -42,10 +42,12 @@ After generating or extending a frontend thread, check which follow-up layers ap
 
 ## Verification follow-up
 
-- `npm run tsc`
-- `npm run build:zova`
-- flavor-specific checks
-- route or SSR verification
+- relevant format, lint, and type checks using the smallest supported scope
+- a few affected critical user flows through existing E2E scenarios, selected by spec, tag, or `--grep`
+- focused regressions for actual defects; no exhaustive upfront fake matrices or custom source-evaluation harnesses
+- affected-flavor artifact preparation when runtime verification needs updated output
+- applicable route, SSR/hydration, authentication, authorization, and contract checks; do not replace server-side enforcement with UI coverage
+- report unavailable or unauthorized runtime proof explicitly; do not create substitute test machinery
 
 ## Escalation rule
 

package/repo-docs/backend/unit-testing.md

@@ -4,7 +4,11 @@ This guide explains the most important Vona testing workflows in the Cabloy mono
 
 ## Why testing is emphasized
 
-Test-driven development remains a strong default in the Cabloy monorepo.
+Keep testing proportional to the backend change: cover critical business behavior using the existing Vona testing infrastructure, and add focused regression coverage when actual problems are fixed. Choose the smallest meaningful service/model, controller/API, or integration boundary for the changed contract; browser E2E is not the default backend test layer.
+
+Test-driven development and targeted unit or framework tests remain useful when they clarify and directly prove new or changed behavior. Exhaustive upfront mock/fake matrices and bespoke harnesses are not a delivery prerequisite.
+
+Preserve applicable authentication/authorization, tenant-isolation, transaction, concurrency, idempotency, migration, and acceptance checks without turning them into an unrelated mandatory matrix. The context, fixture, and resource-isolation rules below still apply, including the required `npm run test` after `meta.version.ts` changes. Missing runtime access must be reported, not worked around with unauthorized resets or substitute test machinery.
 
 Vona’s testing story is valuable because it is closely integrated with:
 

package/repo-docs/frontend/scripts.md

@@ -49,6 +49,14 @@ npm run build:zova:commerce:admin
 
 The `dev:zova:*` commands start the Zova development server, which uses `9000` in the Cabloy Basic default environment. Use this Zova standalone SSR entry for page, route, and hydration iteration. It may be used as Vona's development proxy target, but direct access to `9000` does not prove the Vona request boundary or integrated acceptance.
 
+## Proportionate frontend verification
+
+For frontend changes, prefer a few critical user flows through the existing E2E infrastructure, together with relevant lightweight format, lint, and type checks. Select scenarios by the behavior being changed rather than running every spec or building exhaustive isolated-test matrices. Reuse the edition-aware preparation and spec/tag/`--grep` filtering below; prepare only the affected artifacts when they have changed.
+
+Do not introduce custom source-evaluation loaders or extensive fake dependencies by default for ordinary page interactions. When an actual problem is fixed, add a focused regression test that reproduces it. Targeted unit and framework tests remain useful when they provide direct, low-cost proof; comprehensive upfront coverage is not a delivery prerequisite.
+
+This preference does not relax applicable SSR/hydration, authentication, authorization, contract, or acceptance requirements, and UI coverage never replaces server-side enforcement. Managed E2E resource isolation remains required. If runtime verification is unavailable or not authorized, report the gap rather than adding substitute test machinery; live Provider and destructive operations retain their separate authorization boundaries.
+
 ## Vona integrated SSR browser acceptance
 
 The default Basic Web and Admin sites have browser smoke commands that exercise Vona integrated SSR through Vona SSR dispatch at the managed run's dynamically allocated test listener, not through the ordinary Vona development listener (`7102` by default) or the Zova standalone SSR development-server port. Vona supplies the API origin at runtime, so no Zova `.env` change or rebuild is needed solely for the test port; see [Runtime API origins in Vona integrated SSR](/fullstack/ssr-entry-modes#runtime-api-origins-in-vona-integrated-ssr).

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

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

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

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

package/vona/packages-utils/process-helper/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@cabloy/process-helper",
-  "version": "3.1.8",
+  "version": "3.1.9",
   "gitHead": "a79189b882c17af5911573896a781bbb0046d37d",
   "description": "cabloy process-helper",
   "keywords": [

package/vona/packages-utils/process-helper/src/index.test.ts

@@ -0,0 +1,62 @@
+import assert from 'node:assert/strict';
+import ChildProcess from 'node:child_process';
+import { PassThrough } from 'node:stream';
+import { describe, it } from 'node:test';
+
+import { ProcessHelper } from './index.ts';
+
+describe('ProcessHelper child termination', { concurrency: false }, () => {
+  for (const { code, signal } of [
+    { code: 0, signal: null },
+    { code: 7, signal: null },
+    { code: null, signal: 'SIGKILL' },
+    { code: null, signal: null },
+  ] as const) {
+    it(`handles exit code ${code} and signal ${signal}`, async t => {
+      const child = new ChildProcess.ChildProcess();
+      t.mock.method(ChildProcess, 'spawn', () => child);
+      const result = new ProcessHelper().spawn({ cmd: 'test-owned-command' });
+      child.emit('exit', code, signal);
+      if (code === 0) {
+        assert.equal(await result, '');
+      } else {
+        await assert.rejects(result, (error: Error & { code?: number; signal?: string }) => {
+          if (code !== null) {
+            assert.equal(error.code, 10000 + code);
+            assert.match(error.message, /exit code: 7/);
+          } else {
+            assert.equal(error.signal, signal);
+            assert.match(error.message, signal ? /SIGKILL/ : /exit code: null/);
+          }
+          return true;
+        });
+      }
+    });
+  }
+
+  it('retains the termination signal alongside stderr', async t => {
+    const child = new ChildProcess.ChildProcess();
+    child.stderr = new PassThrough();
+    t.mock.method(ChildProcess, 'spawn', () => child);
+    const helper = new ProcessHelper();
+    t.mock.method(helper.console, 'log', async () => {});
+    const result = helper.spawn({ cmd: 'test-owned-command' });
+    child.stderr.emit('data', Buffer.from('controlled_stderr'));
+    child.emit('exit', null, 'SIGTERM');
+    await assert.rejects(result, (error: Error & { signal?: string }) => {
+      assert.equal(error.signal, 'SIGTERM');
+      assert.match(error.message, /controlled_stderr/);
+      assert.match(error.message, /SIGTERM/);
+      return true;
+    });
+  });
+
+  it('preserves spawn failures', async t => {
+    const child = new ChildProcess.ChildProcess();
+    t.mock.method(ChildProcess, 'spawn', () => child);
+    const failure = new Error('controlled_spawn_failure');
+    const result = new ProcessHelper().spawn({ cmd: 'test-owned-command' });
+    child.emit('error', failure);
+    await assert.rejects(result, error => error === failure);
+  });
+});

package/vona/packages-utils/process-helper/src/index.ts

@@ -172,12 +172,17 @@ export class ProcessHelper {
       proc.once('error', err => {
         reject(err);
       });
-      proc.once('exit', code => {
+      proc.once('exit', (code, signal) => {
         // if (options.gracefull) childs.delete(proc);
-        if (code) {
-          const message = stderr || `spawn ${cmd} ${args.join(' ')} fail, exit code: ${code}`;
+        if (code !== 0) {
+          const status = signal ? `signal: ${signal}` : `exit code: ${code}`;
+          const message =
+            signal || code === null
+              ? `${stderr ? `${stderr}\n` : ''}spawn ${cmd} ${args.join(' ')} fail, ${status}`
+              : stderr || `spawn ${cmd} ${args.join(' ')} fail, ${status}`;
           const err = new Error(message);
-          (err as any).code = 10000 + Number(code);
+          if (code !== null) (err as any).code = 10000 + code;
+          (err as any).signal = signal;
           return reject(err);
         }
         resolve(stdout);

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

@@ -1,6 +1,6 @@
 {
   "name": "vona",
-  "version": "5.1.112",
+  "version": "5.1.113",
   "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.49",
+  "version": "5.1.50",
   "gitHead": "a79189b882c17af5911573896a781bbb0046d37d",
   "description": "vona",
   "keywords": [