cabloy 5.1.220 → 5.1.222

package/.cabloy-version

@@ -1 +1 @@
-5.1.220
+5.1.222

package/.github/workflows/agent-governance.yml

@@ -17,9 +17,9 @@ jobs:
       PNPM_CONFIG_MINIMUM_RELEASE_AGE: 0
     steps:
       - uses: actions/checkout@v6
-      - uses: pnpm/action-setup@v5
+      - uses: pnpm/action-setup@v6
         with:
-          version: 11.5.2
+          version: '12.14.0'
       - uses: actions/setup-node@v6
         with:
           node-version: 24

package/.github/workflows/create-cabloy.yml

@@ -35,9 +35,9 @@ jobs:
       - uses: actions/setup-node@v6
         with:
           node-version: 24
-      - uses: pnpm/action-setup@v5
+      - uses: pnpm/action-setup@v6
         with:
-          version: 11.5.2
+          version: '12.14.0'
       - name: start Redis on macOS
         if: runner.os == 'macOS'
         shell: bash

package/.github/workflows/docs-pages.yml

@@ -29,9 +29,9 @@ jobs:
       PNPM_CONFIG_MINIMUM_RELEASE_AGE: 0
     steps:
       - uses: actions/checkout@v6
-      - uses: pnpm/action-setup@v5
+      - uses: pnpm/action-setup@v6
         with:
-          version: 11.5.2
+          version: '12.14.0'
       - uses: actions/setup-node@v6
         with:
           node-version: 24

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

@@ -28,9 +28,9 @@ jobs:
       - uses: actions/setup-node@v6
         with:
           node-version: 24
-      - uses: pnpm/action-setup@v5
+      - uses: pnpm/action-setup@v6
         with:
-          version: 11.5.2
+          version: '12.14.0'
       - name: start Redis on macOS
         if: runner.os == 'macOS'
         shell: bash
@@ -136,9 +136,9 @@ jobs:
       - uses: actions/setup-node@v6
         with:
           node-version: 24
-      - uses: pnpm/action-setup@v5
+      - uses: pnpm/action-setup@v6
         with:
-          version: 11.5.2
+          version: '12.14.0'
       - name: start Redis on macOS
         if: runner.os == 'macOS'
         shell: bash

package/.github/workflows/vona-cov-pg.yml

@@ -29,9 +29,9 @@ jobs:
       - uses: actions/setup-node@v6
         with:
           node-version: ${{ matrix.node-version }}
-      - uses: pnpm/action-setup@v5
+      - uses: pnpm/action-setup@v6
         with:
-          version: 11.5.2
+          version: '12.14.0'
       - name: init
         run: npm run init
       - name: cov

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

@@ -22,9 +22,9 @@ jobs:
       - uses: actions/setup-node@v6
         with:
           node-version: ${{ matrix.node-version }}
-      - uses: pnpm/action-setup@v5
+      - uses: pnpm/action-setup@v6
         with:
-          version: 11.5.2
+          version: '12.14.0'
       - name: init
         run: npm run init
       - run: npm run vona :create:module demo-student2 -- --suite --ci

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

@@ -29,9 +29,9 @@ jobs:
       - uses: actions/setup-node@v6
         with:
           node-version: ${{ matrix.node-version }}
-      - uses: pnpm/action-setup@v5
+      - uses: pnpm/action-setup@v6
         with:
-          version: 11.5.2
+          version: '12.14.0'
       - name: init
         run: npm run init
       - name: run Commerce lifecycle gate

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

@@ -29,9 +29,9 @@ jobs:
       - uses: actions/setup-node@v6
         with:
           node-version: ${{ matrix.node-version }}
-      - uses: pnpm/action-setup@v5
+      - uses: pnpm/action-setup@v6
         with:
-          version: 11.5.2
+          version: '12.14.0'
       - name: init
         run: npm run init
       - name: run A-Pay focused gate

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

@@ -29,9 +29,9 @@ jobs:
       - uses: actions/setup-node@v6
         with:
           node-version: ${{ matrix.node-version }}
-      - uses: pnpm/action-setup@v5
+      - uses: pnpm/action-setup@v6
         with:
-          version: 11.5.2
+          version: '12.14.0'
       - name: start Redis on macOS
         if: runner.os == 'macOS'
         shell: bash

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

@@ -17,9 +17,9 @@ jobs:
       - uses: actions/setup-node@v6
         with:
           node-version: ${{ matrix.node-version }}
-      - uses: pnpm/action-setup@v5
+      - uses: pnpm/action-setup@v6
         with:
-          version: 11.5.2
+          version: '12.14.0'
       - name: init
         run: npm run init
       - name: tsc

package/.github/workflows/zova-ui.yml

@@ -17,9 +17,9 @@ jobs:
       - uses: actions/setup-node@v6
         with:
           node-version: ${{ matrix.node-version }}
-      - uses: pnpm/action-setup@v5
+      - uses: pnpm/action-setup@v6
         with:
-          version: 11.5.2
+          version: '12.14.0'
       - name: init
         run: npm run init
       - name: suite

package/CHANGELOG.md

@@ -1,5 +1,27 @@
 # 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
+
+- Incorporate updates from MCP.
+- Incorporate updates from the specification.
+
+### Improvements
+
+- Update pnpm.
+
 ## 5.1.220
 
 ### Features

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "cabloy",
-  "version": "5.1.220",
+  "version": "5.1.222",
   "gitHead": "2c5c19284bab738e492856189acb6fad74b8a7b7",
   "description": "A Node.js fullstack framework",
   "keywords": [
@@ -106,7 +106,8 @@
     "typescript": "^5.9.3"
   },
   "engines": {
-    "node": ">=24.4.0"
+    "node": ">=24.4.0",
+    "pnpm": ">=11.5.2"
   },
-  "packageManager": "pnpm@11.5.2"
+  "packageManager": "pnpm@12.14.0"
 }

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/openapi-sdk-guide.md

@@ -73,6 +73,8 @@ npm run contract:generate:isolated -- training-student
 
 The isolated command uses the same generator and preserves module ownership validation, but manages a disposable service, claim, and test resources without starting Playwright. Generated files under `zova/src/**` are shared workspace output, not run-owned temporary files; serialize concurrent SDK generation and do not expect automatic rollback.
 
+For an explicitly authorized run that must skip historical-claim reaping, use the standalone `--skip-expired-claim-reaping` flag. In this strict lane, generated environment source contains selected keys rather than resolved values, configuration reaches the bootstrap child in memory, service/generator stdout and stderr are discarded, and framework file logging is prevented before transport construction. Failures remain failures with categorical diagnostics and retained current-run claims/resources; there is no automatic retry or fallback to development Swagger. This is not a network or arbitrary-filesystem sandbox, and it does not authorize Provider operations or prove custom seed/logging behavior. See [Strict isolated generation](/reference/repo-scripts#test-isolation-and-development-data) for resource and diagnostic boundaries.
+
 The project-level source resolver accepts `OPENAPI_SOURCE_URL` as a complete OpenAPI document URL. It takes precedence over `API_BASE_URL` for generation only and does not change runtime `OPENAPI_BASE_URL_*` request targets:
 
 ```bash

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/repo-docs/reference/repo-scripts.md

@@ -92,7 +92,11 @@ The wrapper consumes this standalone flag rather than forwarding it to Zova; `--
 
 The opt-in lane requires strict freshness after application configuration and before module loading: run-owned public/runtime/SQLite directories must be absent or empty, shared and static-isolate database namespaces must be absent, and persistent Redis namespaces must be empty. Read-only discovery failures or preexisting resources fail closed rather than authorizing deletion. Startup requires per-application freshness proof to bypass normal test clearing; database preparation rechecks the namespace, never drops existing databases in this lane, and reuses only a database creation recorded by that application.
 
-This still loads environment configuration, initializes newly allocated test databases and Redis/runtime resources, and runs normal module seeds. Successful runs clean only their inventoried current-run resources after verified shutdown; failed runs retain their claim/resources, without automatic generation retry or fallback. Generated consumers remain shared checkout writes. Freshness is a snapshot, **not an exclusive lease**, zero-mutation mode, network sandbox, blanket log-redaction guarantee, or authorization to contact a Provider. Independently configured external resources and Provider operations retain their separate ownership and approval requirements. This shared flag does not extend Basic's separately scoped Windows verification to Start.
+In the strict opt-in lane, generated `env.ts` contains a selected-key projection of the bootstrap process environment, not serialized configuration values. The CLI passes its resolved configuration to the bootstrap child in memory, preserving resolved-value precedence without exposing every inherited environment key through `app.meta.env`. Strict generation requires test mode and matching run-owned directories before configuration loading or generated-file writes. Ordinary dev/build/test and default contract generation keep their existing environment generation behavior.
+
+Strict service and generator stdout/stderr are discarded, not captured for later redaction. Framework logger access bypasses client configuration and transport construction; direct file-transport construction fails before filesystem or rotation access. Parent failures report categorical stages instead of raw child errors, causes or response bodies. Windows output still drains through the native bridges into discard streams; this implementation policy and synthetic coverage are not native Windows runtime verification. Custom filesystem writers, external logging sinks and seed behavior remain outside this framework diagnostic boundary: it is not a universal secret sandbox or secret scanner.
+
+This still loads environment configuration, initializes newly allocated test databases and Redis/runtime resources, and runs normal module seeds. Successful runs clean only their inventoried current-run resources after verified shutdown; failed runs retain their claim/resources, without automatic generation retry or fallback. Discarded diagnostics are not recoverable from a retained claim. Generated consumers remain shared checkout writes. Freshness is a snapshot, **not an exclusive lease**, zero-mutation mode, network sandbox, blanket log-redaction guarantee, or authorization to contact a Provider. Independently configured external resources and Provider operations retain their separate ownership and approval requirements. This shared flag does not extend Basic's separately scoped Windows verification to Start.
 
 For Vona integrated SSR, the allocated E2E origin is supplied to Zova at runtime as server `SSR_API_BASE_URL` and browser `API_BASE_URL`. Do not edit Zova `.env` files or rebuild solely to match the test port. The current root `npm run test:e2e` consumes prebuilt frontend artifacts; refresh affected SSR/REST output and synchronize dependencies when their inputs change. See [Runtime API origins in Vona integrated SSR](/fullstack/ssr-entry-modes#runtime-api-origins-in-vona-integrated-ssr) for configuration overrides and scope.
 

package/scripts/generateOpenapiIsolated.ts

@@ -7,6 +7,7 @@ import {
   withIsolatedVona,
   withIsolatedRun,
 } from './runIsolatedTest.ts';
+import { strictGenerationFailure } from './strictGenerationDiagnostics.ts';
 
 const OPENAPI_VERSION = 'V31';
 const SOURCE_TIMEOUT_MS = 30_000;
@@ -78,6 +79,15 @@ export async function validateOpenapiSource(source: string) {
 }
 
 export async function generateOpenapiIsolated(args: string[]) {
+  const strict = args.some(arg => /^--skip-expired-claim-reaping(?:=|$)/.test(arg));
+  try {
+    return await generateOpenapiIsolatedInternal(args);
+  } catch (error) {
+    throw strict ? strictGenerationFailure('run', error) : error;
+  }
+}
+
+async function generateOpenapiIsolatedInternal(args: string[]) {
   const { generatorArgs, skipExpiredClaimReaping } = parseIsolatedOpenapiArgs(args);
   const command = getOpenapiGeneratorCommand(generatorArgs);
   if (process.env.E2E_BASE_URL !== undefined) {
@@ -104,5 +114,12 @@ export async function generateOpenapiIsolated(args: string[]) {
 }
 
 if (process.argv[1] && fileURLToPath(import.meta.url) === resolve(process.argv[1])) {
-  await generateOpenapiIsolated(process.argv.slice(2));
+  const args = process.argv.slice(2);
+  try {
+    await generateOpenapiIsolated(args);
+  } catch (error) {
+    if (!args.some(arg => /^--skip-expired-claim-reaping(?:=|$)/.test(arg))) throw error;
+    console.error(strictGenerationFailure('run', error).message);
+    process.exitCode = 1;
+  }
 }

package/scripts/runIsolatedTest.test.ts

@@ -46,6 +46,7 @@ import {
   waitForReady,
   withIsolatedRun,
 } from './runIsolatedTest.ts';
+import { StrictGenerationError } from './strictGenerationDiagnostics.ts';
 
 const isolationSource = resolve(
   ROOT_DIR,
@@ -367,7 +368,14 @@ for (const marker of ['__CABLOY_BASIC__', '__CABLOY_START__']) {
             root,
             { skipExpiredClaimReaping: true },
           ),
-          /generator failed/,
+          error => {
+            assert.ok(error instanceof StrictGenerationError);
+            assert.equal(error.stage, 'run');
+            assert.equal(error.message, 'Strict contract generation failed: run');
+            assert.doesNotMatch(error.stack ?? '', /generator failed/);
+            assert.equal(error.cause, undefined);
+            return true;
+          },
         );
         assert.equal((await loadTestClaim(claimPath)).status, 'failed');
         assert.equal(existsSync(dataRoot), true);