cabloy 5.1.227 → 5.1.228

package/.cabloy-version

@@ -1 +1 @@
-5.1.227
+5.1.228

package/CHANGELOG.md

@@ -1,5 +1,21 @@
 # Changelog
 
+## 5.1.228
+
+### Features
+
+- Add trade ship order support.
+- Update node-related functionality.
+
+### Bug Fixes
+
+- Ensure the commerce locale schema is ready before opening dialogs.
+
+### Improvements
+
+- Clarify isolated migration verification and development database updates in the documentation.
+- Update CLI REST build tooling.
+
 ## 5.1.227
 
 ### 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 `>=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`.
+You need Git, Node.js `>=24.11.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

package/package.json

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

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

@@ -18,14 +18,14 @@
     {
       "adapter": "codex",
       "category": "skill",
-      "sha256": "11a02f57b7fbccc004e2a8d9cacb0e2af9e6f9a881e53852b9d74cb6309f4fc3",
+      "sha256": "5b5aaee730fbc585388840327de41cd8cdfd2fc6419a1dc99a9c32c2fa9676bb",
       "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": "45ac18019b253a8313b5a229528f6373f1a6814d90f27a70783f787b23936aa0",
+      "sha256": "ad7d88df6dc9bd7196ce894883f292537754aefe7c037d05330d6c02d0420e98",
       "source": "skills/cabloy-backend-scaffold/SKILL.md",
       "target": ".agents/skills/cabloy-backend-scaffold/SKILL.md"
     },
@@ -95,14 +95,14 @@
     {
       "adapter": "codex",
       "category": "skill",
-      "sha256": "af5f73b8c1d52bf0bdd0464c9b29c1f9eccdddece2142da73657d164ab927f95",
+      "sha256": "b883f2b01ab79d51b23e899be43a1c90a821db916490f50c4b28958eedf36b6e",
       "source": "skills/cabloy-frontend-scaffold/SKILL.md",
       "target": ".agents/skills/cabloy-frontend-scaffold/SKILL.md"
     },
     {
       "adapter": "codex",
       "category": "skill",
-      "sha256": "a284541b88adf5034129866b793eab74f92d01c14cc0f25a15672e796b485185",
+      "sha256": "ec828440c4169b2c0235531744ded554db24a71b18082c2b96788c25e4c23ded",
       "source": "skills/cabloy-master-detail/SKILL.md",
       "target": ".agents/skills/cabloy-master-detail/SKILL.md"
     },
@@ -137,28 +137,28 @@
     {
       "adapter": "codex",
       "category": "skill",
-      "sha256": "ca061b134cdcb2574b542f98ca4f93a7a39af57b6587e12a5fae0fb4f431de0e",
+      "sha256": "7922a45b7f9553e5b7a405b41b5d8f173d39481dff38a08d34fb7d99a5979ebb",
       "source": "skills/cabloy-resource-field-update/references/follow-up-checklist.md",
       "target": ".agents/skills/cabloy-resource-field-update/references/follow-up-checklist.md"
     },
     {
       "adapter": "codex",
       "category": "skill",
-      "sha256": "c45978194ce988456656a9d54900c70ce1efc375655ee6f0e2f3003439594a43",
+      "sha256": "980550915f494cf8e6a5110f84bd518a51378111a3cef49a2772ff62c60dd715",
       "source": "skills/cabloy-resource-field-update/references/verification-checklist.md",
       "target": ".agents/skills/cabloy-resource-field-update/references/verification-checklist.md"
     },
     {
       "adapter": "codex",
       "category": "skill",
-      "sha256": "a2cacd13c46bff3116661df32cfcd595a1dac71945e0345a081350e01068c0f7",
+      "sha256": "3423b7bbce2662acbd7d8f31a3607f14fcaee31470b0156cca33b4bfe0a1ab3c",
       "source": "skills/cabloy-resource-field-update/SKILL.md",
       "target": ".agents/skills/cabloy-resource-field-update/SKILL.md"
     },
     {
       "adapter": "codex",
       "category": "skill",
-      "sha256": "c17feccdf3e3528ba9a8006b03135a581a98bc264412885544acd5e8d089c4bc",
+      "sha256": "780105ec2e56a5460664836aab98b6dfc610ca1f9951becc165c524f80d52ff6",
       "source": "skills/cabloy-spec-execution/evals/evals.json",
       "target": ".agents/skills/cabloy-spec-execution/evals/evals.json"
     },
@@ -179,7 +179,7 @@
     {
       "adapter": "codex",
       "category": "skill",
-      "sha256": "a7aae017823a738fbf031424bb68b6cd982f0832102dfbe7320eacaf713919f8",
+      "sha256": "4f1b4b87b2c0d2ff485c58c8f891189fd3dc7914d66af806c1a808d22cd94124",
       "source": "skills/cabloy-spec-execution/references/execution-protocol.md",
       "target": ".agents/skills/cabloy-spec-execution/references/execution-protocol.md"
     },
@@ -354,14 +354,14 @@
     {
       "adapter": "claude",
       "category": "skill",
-      "sha256": "11a02f57b7fbccc004e2a8d9cacb0e2af9e6f9a881e53852b9d74cb6309f4fc3",
+      "sha256": "5b5aaee730fbc585388840327de41cd8cdfd2fc6419a1dc99a9c32c2fa9676bb",
       "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": "45ac18019b253a8313b5a229528f6373f1a6814d90f27a70783f787b23936aa0",
+      "sha256": "ad7d88df6dc9bd7196ce894883f292537754aefe7c037d05330d6c02d0420e98",
       "source": "skills/cabloy-backend-scaffold/SKILL.md",
       "target": ".claude/skills/cabloy-backend-scaffold/SKILL.md"
     },
@@ -431,14 +431,14 @@
     {
       "adapter": "claude",
       "category": "skill",
-      "sha256": "af5f73b8c1d52bf0bdd0464c9b29c1f9eccdddece2142da73657d164ab927f95",
+      "sha256": "b883f2b01ab79d51b23e899be43a1c90a821db916490f50c4b28958eedf36b6e",
       "source": "skills/cabloy-frontend-scaffold/SKILL.md",
       "target": ".claude/skills/cabloy-frontend-scaffold/SKILL.md"
     },
     {
       "adapter": "claude",
       "category": "skill",
-      "sha256": "a284541b88adf5034129866b793eab74f92d01c14cc0f25a15672e796b485185",
+      "sha256": "ec828440c4169b2c0235531744ded554db24a71b18082c2b96788c25e4c23ded",
       "source": "skills/cabloy-master-detail/SKILL.md",
       "target": ".claude/skills/cabloy-master-detail/SKILL.md"
     },
@@ -473,28 +473,28 @@
     {
       "adapter": "claude",
       "category": "skill",
-      "sha256": "ca061b134cdcb2574b542f98ca4f93a7a39af57b6587e12a5fae0fb4f431de0e",
+      "sha256": "7922a45b7f9553e5b7a405b41b5d8f173d39481dff38a08d34fb7d99a5979ebb",
       "source": "skills/cabloy-resource-field-update/references/follow-up-checklist.md",
       "target": ".claude/skills/cabloy-resource-field-update/references/follow-up-checklist.md"
     },
     {
       "adapter": "claude",
       "category": "skill",
-      "sha256": "c45978194ce988456656a9d54900c70ce1efc375655ee6f0e2f3003439594a43",
+      "sha256": "980550915f494cf8e6a5110f84bd518a51378111a3cef49a2772ff62c60dd715",
       "source": "skills/cabloy-resource-field-update/references/verification-checklist.md",
       "target": ".claude/skills/cabloy-resource-field-update/references/verification-checklist.md"
     },
     {
       "adapter": "claude",
       "category": "skill",
-      "sha256": "a2cacd13c46bff3116661df32cfcd595a1dac71945e0345a081350e01068c0f7",
+      "sha256": "3423b7bbce2662acbd7d8f31a3607f14fcaee31470b0156cca33b4bfe0a1ab3c",
       "source": "skills/cabloy-resource-field-update/SKILL.md",
       "target": ".claude/skills/cabloy-resource-field-update/SKILL.md"
     },
     {
       "adapter": "claude",
       "category": "skill",
-      "sha256": "c17feccdf3e3528ba9a8006b03135a581a98bc264412885544acd5e8d089c4bc",
+      "sha256": "780105ec2e56a5460664836aab98b6dfc610ca1f9951becc165c524f80d52ff6",
       "source": "skills/cabloy-spec-execution/evals/evals.json",
       "target": ".claude/skills/cabloy-spec-execution/evals/evals.json"
     },
@@ -515,7 +515,7 @@
     {
       "adapter": "claude",
       "category": "skill",
-      "sha256": "a7aae017823a738fbf031424bb68b6cd982f0832102dfbe7320eacaf713919f8",
+      "sha256": "4f1b4b87b2c0d2ff485c58c8f891189fd3dc7914d66af806c1a808d22cd94124",
       "source": "skills/cabloy-spec-execution/references/execution-protocol.md",
       "target": ".claude/skills/cabloy-spec-execution/references/execution-protocol.md"
     },
@@ -683,7 +683,7 @@
     {
       "adapter": "cursor",
       "category": "policy",
-      "sha256": "27ddaa18de3cd88e11dc20c0ad626fe07d5b6231f08243e3fbece7242dcbdc9a",
+      "sha256": "162dc7bf2d01964a249bc11b29c429af2d379e29c2d61c748ce332f35a224a8e",
       "source": "policies/repository.md",
       "target": ".cursor/rules/cabloy-governance.mdc"
     },
@@ -704,14 +704,14 @@
     {
       "adapter": "cursor",
       "category": "skill",
-      "sha256": "11a02f57b7fbccc004e2a8d9cacb0e2af9e6f9a881e53852b9d74cb6309f4fc3",
+      "sha256": "5b5aaee730fbc585388840327de41cd8cdfd2fc6419a1dc99a9c32c2fa9676bb",
       "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": "45ac18019b253a8313b5a229528f6373f1a6814d90f27a70783f787b23936aa0",
+      "sha256": "ad7d88df6dc9bd7196ce894883f292537754aefe7c037d05330d6c02d0420e98",
       "source": "skills/cabloy-backend-scaffold/SKILL.md",
       "target": ".cursor/skills/cabloy-backend-scaffold/SKILL.md"
     },
@@ -781,14 +781,14 @@
     {
       "adapter": "cursor",
       "category": "skill",
-      "sha256": "af5f73b8c1d52bf0bdd0464c9b29c1f9eccdddece2142da73657d164ab927f95",
+      "sha256": "b883f2b01ab79d51b23e899be43a1c90a821db916490f50c4b28958eedf36b6e",
       "source": "skills/cabloy-frontend-scaffold/SKILL.md",
       "target": ".cursor/skills/cabloy-frontend-scaffold/SKILL.md"
     },
     {
       "adapter": "cursor",
       "category": "skill",
-      "sha256": "a284541b88adf5034129866b793eab74f92d01c14cc0f25a15672e796b485185",
+      "sha256": "ec828440c4169b2c0235531744ded554db24a71b18082c2b96788c25e4c23ded",
       "source": "skills/cabloy-master-detail/SKILL.md",
       "target": ".cursor/skills/cabloy-master-detail/SKILL.md"
     },
@@ -823,28 +823,28 @@
     {
       "adapter": "cursor",
       "category": "skill",
-      "sha256": "ca061b134cdcb2574b542f98ca4f93a7a39af57b6587e12a5fae0fb4f431de0e",
+      "sha256": "7922a45b7f9553e5b7a405b41b5d8f173d39481dff38a08d34fb7d99a5979ebb",
       "source": "skills/cabloy-resource-field-update/references/follow-up-checklist.md",
       "target": ".cursor/skills/cabloy-resource-field-update/references/follow-up-checklist.md"
     },
     {
       "adapter": "cursor",
       "category": "skill",
-      "sha256": "c45978194ce988456656a9d54900c70ce1efc375655ee6f0e2f3003439594a43",
+      "sha256": "980550915f494cf8e6a5110f84bd518a51378111a3cef49a2772ff62c60dd715",
       "source": "skills/cabloy-resource-field-update/references/verification-checklist.md",
       "target": ".cursor/skills/cabloy-resource-field-update/references/verification-checklist.md"
     },
     {
       "adapter": "cursor",
       "category": "skill",
-      "sha256": "a2cacd13c46bff3116661df32cfcd595a1dac71945e0345a081350e01068c0f7",
+      "sha256": "3423b7bbce2662acbd7d8f31a3607f14fcaee31470b0156cca33b4bfe0a1ab3c",
       "source": "skills/cabloy-resource-field-update/SKILL.md",
       "target": ".cursor/skills/cabloy-resource-field-update/SKILL.md"
     },
     {
       "adapter": "cursor",
       "category": "skill",
-      "sha256": "c17feccdf3e3528ba9a8006b03135a581a98bc264412885544acd5e8d089c4bc",
+      "sha256": "780105ec2e56a5460664836aab98b6dfc610ca1f9951becc165c524f80d52ff6",
       "source": "skills/cabloy-spec-execution/evals/evals.json",
       "target": ".cursor/skills/cabloy-spec-execution/evals/evals.json"
     },
@@ -865,7 +865,7 @@
     {
       "adapter": "cursor",
       "category": "skill",
-      "sha256": "a7aae017823a738fbf031424bb68b6cd982f0832102dfbe7320eacaf713919f8",
+      "sha256": "4f1b4b87b2c0d2ff485c58c8f891189fd3dc7914d66af806c1a808d22cd94124",
       "source": "skills/cabloy-spec-execution/references/execution-protocol.md",
       "target": ".cursor/skills/cabloy-spec-execution/references/execution-protocol.md"
     },
@@ -1005,14 +1005,14 @@
     {
       "adapter": "codex",
       "category": "policy",
-      "sha256": "e5929a9b3fa63d76faa596fcd24a9faa4fc8bcadd3eae2e99507ac0b33567efe",
+      "sha256": "af4c50c261114d494961bd30a75c2a7baf999a43644d0aa9c218fbd8ad83c53d",
       "source": "policies/repository.md",
       "target": "AGENTS.md"
     },
     {
       "adapter": "claude",
       "category": "policy",
-      "sha256": "e5929a9b3fa63d76faa596fcd24a9faa4fc8bcadd3eae2e99507ac0b33567efe",
+      "sha256": "af4c50c261114d494961bd30a75c2a7baf999a43644d0aa9c218fbd8ad83c53d",
       "source": "policies/repository.md",
       "target": "CLAUDE.md"
     }

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

@@ -109,4 +109,4 @@ Before inventing a custom implementation path:
 - 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.
+- Verify changes to migration, initialization, or seed behavior through the managed isolated test entrypoint, preferably with focused tests covering the affected behavior. Do not require the full suite solely because `meta.version.ts` changed; expand coverage according to actual impact. Isolated tests do not update development databases: apply pending migrations through normal startup, require explicit approval to reset disposable dev data when replaying an already-applied positive-numbered branch, and use a new migration when existing data must be preserved.

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

@@ -200,7 +200,7 @@ For persisted test data, classify each record as a durable module seed or a test
 Check whether the feature needs:
 
 - unit tests
-- `db:reset` or migration verification
+- managed isolated migration verification and a separate development-database update decision
 - controller action testing
 - broader `test` / `tsc` / `build` checks
 
@@ -239,7 +239,7 @@ Always end with a verification path that matches the scope of the backend change
 
 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).
+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, and precise fixture cleanup. Verify migration, initialization, or seed changes through managed isolated tests covering the affected behavior; focused tests still prepare the test database, so a `meta.version.ts` edit alone does not require the full suite. Tests do not update development databases; decide the development migration/reset path separately using [Migration and Changes](../../../repo-docs/backend/migration-and-changes.md#local-development-workflow). 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:
 
@@ -251,7 +251,7 @@ Narrower checks may include:
 
 - module test updates
 - route/controller action verification
-- migration reset flow
+- focused managed migration tests; development reset only with separate explicit approval
 - CRUD workflow test coverage
 
 ## Response pattern

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

@@ -83,8 +83,8 @@ When the active edition and installed modules provide `@Passport.rbac(...)` and
 - 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
+- managed isolated tests for affected migration, initialization, and seed behavior, preferably focused; expand to the full suite for actual impact, not merely a `meta.version.ts` edit
+- a separate development-database decision: normal startup applies pending migrations, while replaying an already-applied positive-numbered branch on disposable dev data requires an explicitly approved `db:reset`; preserve existing data with a new migration
 - `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

@@ -205,6 +205,7 @@ Check whether the feature needs:
 - style/theme/icon updates
 - wrapper usage review
 - async interaction ownership: for a button-only action, return or await the complete action through `ZButton onPerform`, choose one error presentation owner rather than combining its generic alert with local query/error UI, and do not mirror the same lifecycle with button-local `loading` / `disabled` state; retain explicit state only for independently initiated or broader shared work
+- business row actions that require additional input: prefer a compact trigger and a focused dialog unless deliberate inline editing is intended; follow the [TableCell dialog pattern](../../../repo-docs/frontend/table-cell-cookbook.md#collect-input-for-a-business-row-action-in-a-dialog) for schema-backed forms where suitable, existing mutation ownership, success-only closure, failure input retention, and dialog-scoped E2E verification
 - async-loading or controllerRef implications
 
 ### Verification

package/repo-agent-governance/skills/cabloy-master-detail/SKILL.md

@@ -194,7 +194,8 @@ Typical checks include:
 - confirm detail schema/index support is present
 - confirm both modules’ `.metadata/index.ts` outputs reflect the expected nested detail DTOs
 - if standalone mode applies, confirm the detail module still exposes its standalone resource surface
-- if this workflow changes `meta.version.ts`, run `npm run test` so the test database is reinitialized and schema/data consistency issues surface early
+- verify migration, initialization, or seed changes through managed isolated tests covering the affected aggregate and detail behavior; focused runs still prepare the test database, so a `meta.version.ts` edit alone does not require the full suite
+- decide development-database updates separately: isolated tests do not update dev data, normal startup applies pending migrations, and replaying an already-applied positive-numbered branch on disposable dev data requires explicit reset approval; use a new migration to preserve existing data
 
 ## Response pattern
 

package/repo-agent-governance/skills/cabloy-resource-field-update/SKILL.md

@@ -115,6 +115,8 @@ Then:
 2. fold the schema change into the current version path
 3. do not create a new migration branch
 
+An already-applied positive-numbered migration branch does not replay during normal startup. Managed focused tests exercise the edited branch on a fresh isolated test database, not the development database. Recreating disposable dev data requires separate explicit reset approval; a no-bump decision does not grant it. If existing data must be preserved, resolve a new incremental migration strategy instead. See [Migration and Changes](../../../repo-docs/backend/migration-and-changes.md#local-development-workflow).
+
 ## Step 4: Inspect the current backend thread first
 
 Before proposing or making edits, inspect the existing thread:

package/repo-agent-governance/skills/cabloy-resource-field-update/references/follow-up-checklist.md

@@ -55,14 +55,20 @@ Apply when the user explicitly wants to demonstrate custom renderer development:
 
 ## Verification follow-up
 
-### If persistence changed
+### Backend checks
 
-- `npm run test`
+- relevant typecheck, such as `cd vona && npm run tsc`
+- focused managed tests, such as `npm run test -- 'src/module/<module-name>/test/**/*.ts'` from the repository root; resolve the actual path for suite-owned modules
+- if persistence, initialization, or seed behavior changed, cover that behavior in the managed run; focused tests still prepare a fresh isolated test database, so a `meta.version.ts` edit alone does not require the full suite
+- expand coverage according to actual impact, including upgrade behavior when applicable
 
-### If the change is narrower
+### Development-database follow-up
 
-- `cd vona && npm run tsc`
-- `cd vona && npm test -- <resource-test>.test.ts`
+- isolated tests do not update development data
+- normal startup applies pending migrations to existing prepared databases
+- an already-applied positive-numbered migration branch does not replay on startup; recreating disposable dev data requires separate explicit reset approval, even after a no-bump decision
+- use a new incremental migration when existing data must be preserved
+- see [Migration and Changes](../../../../repo-docs/backend/migration-and-changes.md#local-development-workflow) for lifecycle and reset safety
 
 ### If custom frontend renderers were introduced
 

package/repo-agent-governance/skills/cabloy-resource-field-update/references/verification-checklist.md

@@ -11,32 +11,28 @@ This means the task changed storage shape, such as:
 - `meta.version.ts`
 - module `fileVersion`
 
-Run:
+Verify affected migration, initialization, or seed behavior through the managed isolated test entrypoint. Prefer focused tests that cover the changed resource:
 
 ```bash
-npm run test
+npm run test -- 'src/module/<module-name>/test/**/*.ts'
 ```
 
-Reason:
+Resolve the actual test path for suite-owned modules. A focused managed run still recreates its isolated test database and runs migrations, initialization, and seeds; a `meta.version.ts` edit alone does not require the full suite. Expand coverage according to actual impact, including upgrade behavior when applicable; fresh-database preparation alone does not prove an existing-data upgrade.
 
-- the test database should be reinitialized so schema/version mismatches surface early
+Development-database updates are a separate decision. Tests do not update dev data. Normal startup applies pending migrations to existing prepared databases, but does not replay an already-applied positive-numbered branch. Recreating disposable dev data requires explicit reset approval; a no-bump decision is not authorization. Use a new incremental migration when data must be preserved. See [Migration and Changes](../../../../repo-docs/backend/migration-and-changes.md#local-development-workflow).
 
-## 2. If the change is narrower
+## 2. For all backend field changes
 
-Start with the narrowest meaningful checks first.
+Start with the narrowest meaningful checks, including when persistence changed.
 
-Typical sequence:
+Typical root-level sequence:
 
 ```bash
-cd vona && npm run tsc
-cd vona && npm test -- <resource-test>.test.ts
+npm run tsc:vona
+npm run test -- 'src/module/<module-name>/test/**/*.ts'
 ```
 
-Use this for:
-
-- validation-only refinement
-- locale updates for a field
-- renderer metadata changes on an existing persisted field
+For validation-only refinements, locale updates, or renderer metadata changes on an existing field, select relevant checks without inventing a migration requirement.
 
 ## 3. If custom frontend renderers were introduced
 

package/repo-agent-governance/skills/cabloy-spec-execution/evals/evals.json

@@ -35,11 +35,13 @@
     {
       "id": 4,
       "prompt": "Implement WBS-ABC-30-01, which adds a persisted field to an existing entity. Just choose the migration version that seems consistent with nearby modules and continue.",
-      "expected_output": "Requires an explicit decision about whether vonaModule.fileVersion increments before editing migration metadata, does not invent migration history, and includes the required full test consequence if meta.version.ts changes.",
+      "expected_output": "Requires an explicit decision about whether vonaModule.fileVersion increments before editing migration metadata, does not invent migration history, and plans managed isolated verification of affected migration behavior, preferably with focused tests. Separates development-database updates from test verification and preserves explicit reset approval.",
       "files": ["files/scenarios.json"],
       "expectations": [
         "Asks direct fileVersion strategy before migration edits.",
-        "Includes npm run test consequence if meta.version.ts changes."
+        "Plans managed focused tests for affected migration behavior without requiring the full suite solely for a meta.version.ts edit.",
+        "States that isolated tests do not update dev data; normal startup applies pending migrations, not already-applied positive-numbered branches.",
+        "Keeps reset approval separate from the fileVersion decision and uses a new migration when data must be preserved."
       ]
     },
     {

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

@@ -79,7 +79,7 @@ When authority records conflict, stop the affected work. Update the authoritativ
 
 ### Persisted schema and file version
 
-If implementation may add or alter a persisted field, table, relation, index, or `meta.version.ts` path, ask before editing whether `vonaModule.fileVersion` should increment. Do not infer the answer from neighboring modules. If `meta.version.ts` changes, the repository rule requires `npm run test` after the change; include this in the dossier and evidence plan.
+If implementation may add or alter a persisted field, table, relation, index, or `meta.version.ts` path, ask before editing whether `vonaModule.fileVersion` should increment. Do not infer the answer from neighboring modules. Include managed isolated verification of affected migration, initialization, or seed behavior in the dossier and evidence plan; focused tests still prepare the test database, and a `meta.version.ts` edit alone does not require the full suite. Record development-database updates separately: tests do not update dev data, normal startup applies pending migrations, and replaying an already-applied positive-numbered branch on disposable dev data requires separate explicit reset approval. A no-bump decision is not reset authorization; use a new migration when existing data must be preserved.
 
 ### Contract loop
 

package/repo-agent-governance/tests/evidence-paths.test.mjs

@@ -369,24 +369,95 @@ test('stream fatal UTF-8 and line limit never emit raw fragments of the failing
 test('stream rejects binary control bytes on complete and final lines without raw fragments', async () => {
   for (const byte of [0, 1, 27, 127]) {
     for (const ending of ['', '\n']) {
-      const bytes = Buffer.concat([
-        Buffer.from('/Users/Secret/file '),
-        Buffer.from([byte]),
-        Buffer.from(ending),
-      ]);
+      for (const prefix of ['', '/Users/Secret/file ']) {
+        const bytes = Buffer.concat([
+          Buffer.from(prefix),
+          Buffer.from([byte]),
+          Buffer.from(ending),
+        ]);
+        const bytePosition = Buffer.byteLength(prefix) + 1;
+        const output = sink();
+        await assert.rejects(
+          sanitizeStream(Readable.from([bytes]), output.stream, { matcher }),
+          error => {
+            assert.equal(String(error), 'Error: BINARY');
+            assert.equal(error.code, 'BINARY');
+            assert.deepEqual(error.details, { byte, line: 1, bytePosition });
+            return true;
+          },
+        );
+        assert.equal(output.text(), '');
+        const result = cli(['sanitize'], bytes);
+        assert.equal(result.status, 2);
+        assert.equal(result.stdout, '');
+        assert.equal(
+          result.stderr,
+          `evidence-paths: BINARY byte=${byte} line=1 byte-position=${bytePosition}\n`,
+        );
+      }
+    }
+  }
+  assert.equal(await streamed([Buffer.from('plain\ttext\f\r\n')]), 'plain\ttext\f\r\n');
+});
+
+test('binary diagnostics use original byte positions across chunks and input lines', async () => {
+  for (const ending of ['', '\n']) {
+    const bytes = Buffer.concat([
+      Buffer.from('ok\r\n\r\né🙂'),
+      Buffer.from([27, 0]),
+      Buffer.from('/Users/Secret/file'),
+      Buffer.from(ending),
+    ]);
+    for (const chunks of [[bytes], Array.from(bytes, byte => Buffer.from([byte]))]) {
       const output = sink();
       await assert.rejects(
-        sanitizeStream(Readable.from([bytes]), output.stream, { matcher }),
-        /^Error: BINARY$/u,
+        sanitizeStream(Readable.from(chunks), output.stream, { matcher }),
+        error => {
+          assert.equal(String(error), 'Error: BINARY');
+          assert.equal(error.code, 'BINARY');
+          assert.deepEqual(error.details, { byte: 27, line: 3, bytePosition: 7 });
+          return true;
+        },
       );
-      assert.equal(output.text(), '');
-      const result = cli(['sanitize'], bytes);
-      assert.equal(result.status, 2);
-      assert.equal(result.stdout, '');
-      assert.equal(result.stderr, 'evidence-paths: BINARY\n');
+      assert.equal(output.text(), 'ok\r\n\r\n');
+      const cliOutput = sink();
+      const errors = sink();
+      assert.equal(
+        await runCli(['sanitize'], {
+          input: Readable.from(chunks),
+          output: cliOutput.stream,
+          error: errors.stream,
+        }),
+        2,
+      );
+      assert.equal(cliOutput.text(), 'ok\r\n\r\n');
+      assert.equal(errors.text(), 'evidence-paths: BINARY byte=27 line=3 byte-position=7\n');
     }
+    const result = cli(['sanitize'], bytes);
+    assert.equal(result.status, 2);
+    assert.equal(result.stdout, 'ok\r\n\r\n');
+    assert.equal(result.stderr, 'evidence-paths: BINARY byte=27 line=3 byte-position=7\n');
+  }
+});
+
+test('line limits retain precedence over binary diagnostics', async () => {
+  for (const ending of ['', '\n']) {
+    const bytes = Buffer.concat([
+      Buffer.from([27]),
+      Buffer.alloc(LINE_LIMIT, 97),
+      Buffer.from(ending),
+    ]);
+    const output = sink();
+    await assert.rejects(
+      sanitizeStream(Readable.from([bytes]), output.stream, { matcher }),
+      /^Error: LINE_LIMIT$/u,
+    );
+    assert.equal(output.text(), '');
+    const result = cli(['sanitize'], bytes);
+    assert.equal(result.status, 2);
+    assert.equal(result.stdout, '');
+    assert.equal(result.stderr, 'evidence-paths: LINE_LIMIT\n');
   }
-  assert.equal(await streamed([Buffer.from('plain\ttext\f\r\n')]), 'plain\ttext\f\r\n');
 });
 
 test('stream input/output failures and CLI diagnostics never expose raw exception text or stacks', async () => {