cabloy 5.1.145 → 5.1.147

package/.cabloy-version

@@ -1 +1 @@
-5.1.145
+5.1.147

package/.claude/skills/cabloy-backend-scaffold/SKILL.md

@@ -49,7 +49,7 @@ Inspect these surfaces before proposing implementation:
 - the repository or workspace `package.json` that owns the scripts
 - `npm run vona`
 - Vona command families such as `create:*`, `init:*`, `tools:*`, and `bin:*`
-- `cabloy-docs/backend/` for the relevant backend thread
+- `repo-docs/backend/` for the relevant backend thread
 
 For deeper reference material, read:
 
@@ -152,7 +152,7 @@ When the active edition and installed modules provide `@Passport.rbac(...)` and
 - treat summary/description as presentation metadata, not authorization identity or enforcement
 - verify the explicit server-side catalog/editor projection; do not assume OpenAPI metadata is automatically displayed by a policy editor
 
-For the authoring example and metadata boundary, read [Controller Guide](../../../cabloy-docs/backend/controller-guide.md#rbac-presentation-metadata) and [Controller AOP Guide](../../../cabloy-docs/backend/controller-aop-guide.md#rbac-presentation-metadata).
+For the authoring example and metadata boundary, read [Controller Guide](../../../repo-docs/backend/controller-guide.md#rbac-presentation-metadata) and [Controller AOP Guide](../../../repo-docs/backend/controller-aop-guide.md#rbac-presentation-metadata).
 
 ### Persistence and schema lifecycle
 
@@ -172,7 +172,7 @@ For normal resource persistence, preserve Vona's default active-instance scope:
 - use `disableInstance`, plain builders, or raw SQL only for an explicit global/system or otherwise authorized contract
 - model a future multi-merchant requirement as a separate boundary within an instance, with its own ownership and authorization rules
 
-For the canonical explanation, read [Multi-Instance and Instance Resolution](../../../cabloy-docs/backend/multi-instance-and-instance-resolution.md) and [Model Guide](../../../cabloy-docs/backend/model-guide.md).
+For the canonical explanation, read [Multi-Instance and Instance Resolution](../../../repo-docs/backend/multi-instance-and-instance-resolution.md) and [Model Guide](../../../repo-docs/backend/model-guide.md).
 
 ### Cross-module resource lookup
 
@@ -190,7 +190,7 @@ Then distinguish runtime lookup from a true module dependency:
 - do not add a dependency declaration merely because code looks up another module's service, model, config, locale, or other resource
 - scope lookup cannot make an absent module available; validate application/suite composition separately when the target must exist
 
-For the canonical decision guide, read [Vona Module Dependencies](../../../cabloy-docs/backend/module-dependencies.md), with [Backend Foundation](../../../cabloy-docs/backend/foundation.md#scope-lookup-vs-module-dependencies) and [Package Map](../../../cabloy-docs/reference/package-map.md) as companions.
+For the canonical decision guide, read [Vona Module Dependencies](../../../repo-docs/backend/module-dependencies.md), with [Backend Foundation](../../../repo-docs/backend/foundation.md#scope-lookup-vs-module-dependencies) and [Package Map](../../../repo-docs/reference/package-map.md) as companions.
 
 ### Verification
 
@@ -219,18 +219,18 @@ Use the docs to decide what the generated backend thread still needs.
 
 Especially relevant pages include:
 
-- `cabloy-docs/backend/controller-guide.md`
-- `cabloy-docs/backend/service-guide.md`
-- `cabloy-docs/backend/model-guide.md`
-- `cabloy-docs/backend/entity-guide.md`
-- `cabloy-docs/backend/dto-guide.md`
-- `cabloy-docs/backend/crud-workflow.md`
-- `cabloy-docs/backend/migration-and-changes.md`
-- `cabloy-docs/backend/field-indexes.md`
-- `cabloy-docs/backend/unit-testing.md`
-- `cabloy-docs/backend/validation-guide.md`
-- `cabloy-docs/backend/openapi-guide.md`
-- `cabloy-docs/backend/dto-infer-generation.md`
+- `repo-docs/backend/controller-guide.md`
+- `repo-docs/backend/service-guide.md`
+- `repo-docs/backend/model-guide.md`
+- `repo-docs/backend/entity-guide.md`
+- `repo-docs/backend/dto-guide.md`
+- `repo-docs/backend/crud-workflow.md`
+- `repo-docs/backend/migration-and-changes.md`
+- `repo-docs/backend/field-indexes.md`
+- `repo-docs/backend/unit-testing.md`
+- `repo-docs/backend/validation-guide.md`
+- `repo-docs/backend/openapi-guide.md`
+- `repo-docs/backend/dto-infer-generation.md`
 
 ## Step 7: Verification guidance
 

package/.claude/skills/cabloy-backend-scaffold/references/follow-up-checklist.md

@@ -19,7 +19,7 @@ After generating or extending a backend thread, check which follow-up layers app
 - when a narrowed DTO or OpenAPI schema is expected to remove physical response fields, separately shape and verify the action response; declaration narrowing alone does not guarantee runtime field stripping
 - when stable Entity, Model, relation, or query truth exists, define the DTO projection first with `$Dto.*` and, where needed, `columns`, `include`, or `dtoClass`
 - for an inferred field, use `$makeMetadata(...)` for metadata-only refinement and `$makeSchema(...)` for schema or validation refinement; use a class-body `@Api.field(...)` member only for a genuinely new field
-- when inference cannot express the contract clearly, choose an explicit DTO deliberately; see [Default-first three-layer DTO authoring](../../../../cabloy-docs/backend/dto-infer-generation.md#default-first-three-layer-dto-authoring)
+- when inference cannot express the contract clearly, choose an explicit DTO deliberately; see [Default-first three-layer DTO authoring](../../../../repo-docs/backend/dto-infer-generation.md#default-first-three-layer-dto-authoring)
 - frontend contract impact
 - `@Api.field(...)` / `$makeSchema(...)` ordering: framework guards now preserve previously attached OpenAPI metadata across schema rebuilds, but structure-shaping schemaLike is still order-sensitive
 - when an explicit zod/custom schema or other structure-defining schemaLike is present, put that structure-defining schemaLike last because `makeSchemaLikes(...)` applies arguments right-to-left and later structure changes can otherwise alter or replace the intended schema
@@ -49,7 +49,7 @@ When the active edition and installed modules provide `@Passport.rbac(...)` and
 - keep the dependency graph acyclic and free of duplicate edges; do not declare both forms for the same edge because propagation is transitive and current runtime collection does not deduplicate targets
 - when `modelsClearedByFn` is required, treat it as replacement behavior and explicitly own the target clear and any necessary downstream propagation
 - prefer normal Model/service mutation paths so source invalidation, commit-time re-clear, and configured double-delete remain active
-- add a warm-query → mutate-source → repeat-query regression test for each new dependency path; read [Vona Cross-Model Query-Cache Dependencies](../../../../.docs-internal/architecture/vona-cross-model-query-cache-dependencies.md) for the source-backed decision rules
+- add a warm-query → mutate-source → repeat-query regression test for each new dependency path; read [Vona Cross-Model Query-Cache Dependencies](../../../../repo-docs-internal/architecture/vona-cross-model-query-cache-dependencies.md) for the source-backed decision rules
 - transaction behavior
 
 ## Test resource lifecycle follow-up
@@ -73,7 +73,7 @@ When the active edition and installed modules provide `@Passport.rbac(...)` and
 - add `vonaModule.dependencies` only for a genuine target-module availability, dependency-first ordering, or minimum-version requirement
 - startup, lifecycle, or `monkey.ts` integration can require dependency-first ordering, but are not the only valid dependency case
 - when adding an edge, verify package/suite composition, the target relative module name, the minimum compatible version, and that the graph remains acyclic
-- do not create speculative dependency edges or circular declarations merely to document a lookup; read [Vona Module Dependencies](../../../../cabloy-docs/backend/module-dependencies.md) for the canonical decision guide
+- do not create speculative dependency edges or circular declarations merely to document a lookup; read [Vona Module Dependencies](../../../../repo-docs/backend/module-dependencies.md) for the canonical decision guide
 
 ## Verification follow-up
 

package/.claude/skills/cabloy-contract-loop/SKILL.md

@@ -7,7 +7,7 @@ description: Use this skill whenever a Cabloy task crosses the Vona-to-Zova cont
 
 Use this skill when a backend contract change needs to be reflected in frontend consumers, when frontend-owned metadata or resources need to be reflected back into backend consumers, or when either side appears stale and you need to diagnose where drift actually lives.
 
-Read the public [Contract Loop Playbook](../../../cabloy-docs/fullstack/contract-loop-playbook.md) for the canonical bidirectional model. This skill is the branching orchestration guide.
+Read the public [Contract Loop Playbook](../../../repo-docs/fullstack/contract-loop-playbook.md) for the canonical bidirectional model. This skill is the branching orchestration guide.
 
 ## Important recovery note for stale local file consumers
 
@@ -110,14 +110,14 @@ Inspect these surfaces before proposing workflow:
 - backend contract-defining code in Vona
 - `npm run zova`
 - frontend generation or consumption path in Zova
-- relevant docs in `cabloy-docs/fullstack/`, `cabloy-docs/backend/`, and `cabloy-docs/frontend/`
+- relevant docs in `repo-docs/fullstack/`, `repo-docs/backend/`, and `repo-docs/frontend/`
 
 For deeper reference material, read:
 
 - `references/contract-loop-map.md`
 - `references/verification-checklist.md`
 - `references/resource-custom-state-pattern.md`
-- `../../../cabloy-docs/fullstack/admin-resource-and-web-self-service.md`
+- `../../../repo-docs/fullstack/admin-resource-and-web-self-service.md`
 
 ## Step 3: Identify the contract source of truth deliberately
 
@@ -241,7 +241,7 @@ When the regenerated contract feeds a form or another metadata-driven UI, decide
 5. Keep reusable query, cache, mutation, invalidation, and resource state in `ModelResource` or a model. A page-specific action may call generated `$api` directly when it has no shared state or cache ownership; do not add an infrequently used operation to a shared model only for API indirection.
 6. If the page needs a custom renderer, layout, or behavior, determine whether that resource is frontend-owned and referenced by backend metadata. If so, follow the reverse-chain flavor build and `deps:vona` handoff rather than treating the change as frontend-only.
 
-Read the [API Schema Guide](../../../cabloy-docs/frontend/api-schema-guide.md), [Form Guide](../../../cabloy-docs/frontend/form-guide.md), [A-OpenAPI Under the Hood](../../../cabloy-docs/frontend/a-openapi-under-the-hood.md), and [Model Resource Owner Pattern](../../../cabloy-docs/frontend/model-resource-owner-pattern.md) for the ownership and runtime details. Use `references/contract-loop-map.md` and `references/verification-checklist.md` for the contract-loop proof steps.
+Read the [API Schema Guide](../../../repo-docs/frontend/api-schema-guide.md), [Form Guide](../../../repo-docs/frontend/form-guide.md), [A-OpenAPI Under the Hood](../../../repo-docs/frontend/a-openapi-under-the-hood.md), and [Model Resource Owner Pattern](../../../repo-docs/frontend/model-resource-owner-pattern.md) for the ownership and runtime details. Use `references/contract-loop-map.md` and `references/verification-checklist.md` for the contract-loop proof steps.
 
 ### Path C: Downstream frontend alignment
 
@@ -262,7 +262,7 @@ For one persisted domain with both Admin Resource and Web self-service consumers
 - **Admin/custom-resource branch:** the endpoint remains part of the Admin Resource authority, projection, and generic page state, so reuse `rest-resource.model.resource` through a thin semantic facade.
 - **Separate Web self-service branch:** the consumer has different authority, server-derived owner scope, DTO projection, operation names, UX, or SSR behavior, so expose explicit self-service operations and use a dedicated Web model and purpose-built pages.
 
-Share domain persistence and lifecycle logic, not necessarily HTTP projections or frontend state ownership. Read `../../../cabloy-docs/fullstack/admin-resource-and-web-self-service.md` for the complete architecture. Reuse the resource-owned custom state pattern in `references/resource-custom-state-pattern.md` for the Admin/custom-resource branch.
+Share domain persistence and lifecycle logic, not necessarily HTTP projections or frontend state ownership. Read `../../../repo-docs/fullstack/admin-resource-and-web-self-service.md` for the complete architecture. Reuse the resource-owned custom state pattern in `references/resource-custom-state-pattern.md` for the Admin/custom-resource branch.
 
 ## Step 6: Keep edition-aware differences explicit
 

package/.claude/skills/cabloy-contract-loop/references/contract-loop-map.md

@@ -103,7 +103,7 @@ After generation, choose the consumer shape by boundary:
 | Admin custom operation with the same authority, projection, and Resource page semantics | thin module facade → `rest-resource.model.resource` → schema-driven Resource UI |
 | Web self-service operation with different authority, server-derived owner scope, DTO projection, or page/SSR semantics | dedicated Web model → purpose-built self-service pages |
 
-The Web model is valid only for the separate self-service state domain. It must not become a parallel owner for Admin `select`/`view`, schemas, permissions, or generic Resource page state. See `../../../../cabloy-docs/fullstack/admin-resource-and-web-self-service.md` for the complete architecture.
+The Web model is valid only for the separate self-service state domain. It must not become a parallel owner for Admin `select`/`view`, schemas, permissions, or generic Resource page state. See `../../../../repo-docs/fullstack/admin-resource-and-web-self-service.md` for the complete architecture.
 
 ## Forward chain artifact map
 

package/.claude/skills/cabloy-contract-loop/references/resource-custom-state-pattern.md

@@ -147,7 +147,7 @@ Use that branch only when all of these are true:
 - the Web model owns only its self-service query keys and purpose-built page state, not Admin Resource schemas, permissions, or generic page state;
 - Web UX or private SSR behavior needs a dedicated admission and post-hydration boundary.
 
-This does not justify a parallel owner for a custom Admin endpoint. It establishes a separate Web state domain beside the Admin Resource boundary. Read `../../../../cabloy-docs/fullstack/admin-resource-and-web-self-service.md` for the complete cross-stack pattern.
+This does not justify a parallel owner for a custom Admin endpoint. It establishes a separate Web state domain beside the Admin Resource boundary. Read `../../../../repo-docs/fullstack/admin-resource-and-web-self-service.md` for the complete cross-stack pattern.
 
 ## Quick checklist
 

package/.claude/skills/cabloy-domain-planning/SKILL.md

@@ -48,7 +48,7 @@ Do not use this skill once naming is already confirmed and the request is clearl
 
 For real business work, prefer the suite-first path described in:
 
-- `cabloy-docs/fullstack/suites-and-modules.md`
+- `repo-docs/fullstack/suites-and-modules.md`
 
 Use this practical rule:
 
@@ -75,8 +75,8 @@ If the user already provides names, validate them instead of replacing them sile
 
 Reuse the durable naming rules from:
 
-- `cabloy-docs/fullstack/suites-and-modules.md`
-- `cabloy-docs/frontend/modules-and-suites.md`
+- `repo-docs/fullstack/suites-and-modules.md`
+- `repo-docs/frontend/modules-and-suites.md`
 
 ### Suite short name rule
 

package/.claude/skills/cabloy-frontend-scaffold/SKILL.md

@@ -55,7 +55,7 @@ Inspect these surfaces before proposing implementation:
 - the repository or workspace `package.json` that owns the scripts
 - `npm run zova`
 - Zova command families such as `create:*`, `init:*`, `refactor:*`, `tools:*`, `openapi:*`, and `bin:*`
-- `cabloy-docs/frontend/` for the relevant frontend thread
+- `repo-docs/frontend/` for the relevant frontend thread
 
 For deeper reference material, read:
 
@@ -241,31 +241,31 @@ Use the docs to decide what the generated frontend thread still needs.
 
 Especially relevant pages include:
 
-- `cabloy-docs/frontend/page-guide.md`
-- `cabloy-docs/frontend/page-query-guide.md`
-- `cabloy-docs/frontend/page-params-guide.md`
-- `cabloy-docs/frontend/page-route-guide.md`
-- `cabloy-docs/frontend/route-alias-guide.md`
-- `cabloy-docs/frontend/navigation-guards-guide.md`
-- `cabloy-docs/frontend/component-guide.md`
-- `cabloy-docs/frontend/form-layout-guide.md` for schema-driven field placement, Grid/flow selection, groups, tabs, or embedded filter actions
-- `cabloy-docs/frontend/component-props-guide.md`
-- `cabloy-docs/frontend/component-v-model-guide.md`
-- `cabloy-docs/frontend/generic-component-guide.md`
-- `cabloy-docs/frontend/api-guide.md`
-- `cabloy-docs/frontend/model-architecture.md`
-- `cabloy-docs/frontend/model-state-guide.md`
-- `cabloy-docs/frontend/openapi-sdk-guide.md`
-- `cabloy-docs/frontend/api-schema-guide.md`
-- `cabloy-docs/frontend/sdk-guide.md`
-- `cabloy-docs/frontend/ssr-overview.md`
-- `cabloy-docs/frontend/ssr-init-data.md`
-- `cabloy-docs/frontend/ssr-client-only.md`
-- `cabloy-docs/frontend/ssr-seo-meta.md`
-- `cabloy-docs/frontend/ssr-env.md`
-- `cabloy-docs/frontend/css-in-js-guide.md`
-- `cabloy-docs/frontend/theme-guide.md`
-- `cabloy-docs/frontend/icon-engine-guide.md`
+- `repo-docs/frontend/page-guide.md`
+- `repo-docs/frontend/page-query-guide.md`
+- `repo-docs/frontend/page-params-guide.md`
+- `repo-docs/frontend/page-route-guide.md`
+- `repo-docs/frontend/route-alias-guide.md`
+- `repo-docs/frontend/navigation-guards-guide.md`
+- `repo-docs/frontend/component-guide.md`
+- `repo-docs/frontend/form-layout-guide.md` for schema-driven field placement, Grid/flow selection, groups, tabs, or embedded filter actions
+- `repo-docs/frontend/component-props-guide.md`
+- `repo-docs/frontend/component-v-model-guide.md`
+- `repo-docs/frontend/generic-component-guide.md`
+- `repo-docs/frontend/api-guide.md`
+- `repo-docs/frontend/model-architecture.md`
+- `repo-docs/frontend/model-state-guide.md`
+- `repo-docs/frontend/openapi-sdk-guide.md`
+- `repo-docs/frontend/api-schema-guide.md`
+- `repo-docs/frontend/sdk-guide.md`
+- `repo-docs/frontend/ssr-overview.md`
+- `repo-docs/frontend/ssr-init-data.md`
+- `repo-docs/frontend/ssr-client-only.md`
+- `repo-docs/frontend/ssr-seo-meta.md`
+- `repo-docs/frontend/ssr-env.md`
+- `repo-docs/frontend/css-in-js-guide.md`
+- `repo-docs/frontend/theme-guide.md`
+- `repo-docs/frontend/icon-engine-guide.md`
 
 ## Step 7: Verification guidance
 

package/.claude/skills/cabloy-master-detail/SKILL.md

@@ -7,7 +7,7 @@ description: This skill should be used when the main Cabloy task is parent-owned
 
 Use this skill when the user wants to add, extend, analyze, or preserve a Cabloy master-detail or nested-detail backend workflow.
 
-Read the public [Master-Detail Workflow](../../../cabloy-docs/backend/master-detail-workflow.md) for the canonical operational explanation and [Master-Detail Source Reading Map](../../../cabloy-docs/backend/master-detail-source-reading-map.md) for the current source evidence. This skill is the thinner orchestration layer: it should classify the detail shape, choose the generator-first path, preserve the naming and placement invariants, and finish with the right verification path.
+Read the public [Master-Detail Workflow](../../../repo-docs/backend/master-detail-workflow.md) for the canonical operational explanation and [Master-Detail Source Reading Map](../../../repo-docs/backend/master-detail-source-reading-map.md) for the current source evidence. This skill is the thinner orchestration layer: it should classify the detail shape, choose the generator-first path, preserve the naming and placement invariants, and finish with the right verification path.
 
 ## Goals
 
@@ -161,7 +161,7 @@ Master-detail ownership is separate from Vona's tenant/instance boundary:
 - treat a missing parent or detail from the normal scoped aggregate flow as absent; do not add unscoped existence probes merely to distinguish a foreign-instance row
 - if a future multi-merchant design is needed, model merchant ownership explicitly within the instance in addition to the aggregate relation
 
-For the canonical tenancy explanation, read [Multi-Instance and Instance Resolution](../../../cabloy-docs/backend/multi-instance-and-instance-resolution.md) and [Model Guide](../../../cabloy-docs/backend/model-guide.md).
+For the canonical tenancy explanation, read [Multi-Instance and Instance Resolution](../../../repo-docs/backend/multi-instance-and-instance-resolution.md) and [Model Guide](../../../repo-docs/backend/model-guide.md).
 
 ## Step 7: Keep fullstack boundaries explicit
 

package/.claude/skills/cabloy-module-removal/SKILL.md

@@ -7,7 +7,7 @@ description: Use this skill whenever the user wants to remove or delete an exist
 
 Use this skill when the user wants to remove an existing module from the Cabloy monorepo.
 
-Read the public [Module Removal Playbook](../../../cabloy-docs/ai/playbook-module-removal.md) for the canonical user/agent-facing workflow. This skill is the thinner orchestration layer: it should classify the removal path, choose the right cleanup branch, and point back to the playbook for the shared operational sequence.
+Read the public [Module Removal Playbook](../../../repo-docs/ai/playbook-module-removal.md) for the canonical user/agent-facing workflow. This skill is the thinner orchestration layer: it should classify the removal path, choose the right cleanup branch, and point back to the playbook for the shared operational sequence.
 
 ## Goals
 
@@ -128,7 +128,7 @@ Ask or confirm whether the task is:
 - code/runtime removal only
 - code/runtime removal plus docs/examples scrub
 
-If docs cleanup is in scope, update `cabloy-docs/` separately from the runtime cleanup and keep maintainer rationale in `.docs-internal/`.
+If docs cleanup is in scope, update `repo-docs/` separately from the runtime cleanup and keep maintainer rationale in `repo-docs-internal/`.
 
 ## Response pattern
 

package/.claude/skills/cabloy-resource-field-update/SKILL.md

@@ -214,7 +214,7 @@ If the user explicitly wants to **demonstrate** the custom renderer workflow, br
 Use these references:
 
 - `references/custom-renderer-demo-checklist.md`
-- `.docs-internal/architecture/backend-resource-field-workflow.md`
+- `repo-docs-internal/architecture/backend-resource-field-workflow.md`
 
 Recommended shape:
 

package/.claude/skills/cabloy-workflow/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: cabloy-workflow
-description: This skill should be used when the main Cabloy problem is workflow routing before implementation: deciding between Vona backend scaffolding, Zova frontend scaffolding, contract-loop work, or docs/AI-enablement homes such as cabloy-docs, .docs-internal, CLAUDE.md, commands, or skills, including cases where Cabloy Basic vs Cabloy Start assumptions affect that routing. Trigger on requests to route, classify, choose a workflow, choose an edition-specific path, or decide where Cabloy guidance should live. Do not use it once the task is already clearly a backend scaffold, frontend scaffold, or contract-loop job.
+description: This skill should be used when the main Cabloy problem is workflow routing before implementation: deciding between Vona backend scaffolding, Zova frontend scaffolding, contract-loop work, or docs/AI-enablement homes such as repo-docs, repo-docs-internal, CLAUDE.md, commands, or skills, including cases where Cabloy Basic vs Cabloy Start assumptions affect that routing. Trigger on requests to route, classify, choose a workflow, choose an edition-specific path, or decide where Cabloy guidance should live. Do not use it once the task is already clearly a backend scaffold, frontend scaffold, or contract-loop job.
 ---
 
 # Cabloy Workflow
@@ -69,8 +69,8 @@ Use the frontend path when the task is about:
 
 Use the docs/AI path when the task is about:
 
-- `cabloy-docs/`
-- `.docs-internal/`
+- `repo-docs/`
+- `repo-docs-internal/`
 - `CLAUDE.md`
 - `.claude/commands/`
 - `.claude/skills/`
@@ -84,8 +84,8 @@ Before inventing a workflow, inspect these shared surfaces:
 - `npm run vona`
 - `npm run zova`
 - root `CLAUDE.md` if present
-- `cabloy-docs/` for public guidance
-- `.docs-internal/` for maintainer rationale
+- `repo-docs/` for public guidance
+- `repo-docs-internal/` for maintainer rationale
 
 If the request spans backend and frontend, classify it as fullstack by default unless the user clearly wants only one side.
 
@@ -100,7 +100,7 @@ The reason is simple: these files are where Cabloy already encodes its real work
 
 ### Parallel worktree environment setup
 
-When a request involves a second worktree, concurrent Vona/Zova development, isolated ordinary tests, or managed clean E2E, classify it as fullstack workflow setup. Read [Parallel Worktree Environment](../../../cabloy-docs/fullstack/parallel-worktree-environment.md), the canonical shared recipe maintained in Cabloy Basic for both editions.
+When a request involves a second worktree, concurrent Vona/Zova development, isolated ordinary tests, or managed clean E2E, classify it as fullstack workflow setup. Read [Parallel Worktree Environment](../../../repo-docs/fullstack/parallel-worktree-environment.md), the canonical shared recipe maintained in Cabloy Basic for both editions.
 
 This routing skill provides read-only guidance only. Do not infer an `APP_NAME` or ports, edit local overrides, or run `npm run init` from a generic worktree request. When the user wants confirmation-gated local environment setup, ask them to explicitly invoke `/cabloy-worktree-environment`.
 
@@ -152,7 +152,7 @@ When the user is asking for guidance or automation assets, route the work to the
 
 ### Public docs
 
-Use `cabloy-docs/` for:
+Use `repo-docs/` for:
 
 - user-facing explanations
 - reusable AI-facing workflow guidance
@@ -160,7 +160,7 @@ Use `cabloy-docs/` for:
 
 ### Internal engineering docs
 
-Use `.docs-internal/` for:
+Use `repo-docs-internal/` for:
 
 - ADRs
 - architecture notes
@@ -196,8 +196,8 @@ When the request is about whether a backend base class belongs in `src/lib`, `sr
 
 For these requests:
 
-- put the durable operational explanation in `cabloy-docs/`
-- put rationale and invariants in `.docs-internal/`
+- put the durable operational explanation in `repo-docs/`
+- put rationale and invariants in `repo-docs-internal/`
 - keep `CLAUDE.md` short and behavioral
 - do not treat `@Service()` as a business-layer naming decision only; for B2 it is a runtime-anchor placement choice
 

package/.claude/skills/cabloy-workflow/evals/evals.json

@@ -15,7 +15,7 @@
     },
     {
       "id": 3,
-      "prompt": "Please help me decide whether this new AI guidance belongs in public docs, .docs-internal, CLAUDE.md, or a skill. The guidance is about when to use npm run zova instead of hand-written scaffolding.",
+      "prompt": "Please help me decide whether this new AI guidance belongs in public docs, repo-docs-internal, CLAUDE.md, or a skill. The guidance is about when to use npm run zova instead of hand-written scaffolding.",
       "expected_output": "Routes the request to the right knowledge homes, prefers public docs plus Claude rules/skills as appropriate, and reinforces the CLI-first principle.",
       "files": []
     },
@@ -33,7 +33,7 @@
     },
     {
       "id": 6,
-      "prompt": "I created a second Cabloy Basic worktree and need to run Vona, Zova Admin, and test:e2e:basic:clean in parallel with the first worktree. Which environment files and exact variables should I configure without changing shared defaults?",
+      "prompt": "I created a second Cabloy Basic worktree and need to run Vona, Zova Admin, and test:e2e in parallel with the first worktree. Which environment files and exact variables should I configure without changing shared defaults?",
       "expected_output": "Classifies this as fullstack parallel-worktree environment setup and routes to the canonical shared Parallel Worktree Environment guide. Explains that generic routing is read-only: it must not inspect env content, infer or write local values, or run npm run init. Directs the user to explicitly invoke /cabloy-worktree-environment for confirmation-gated setup. The invoked skill uses Git worktree metadata, the worktree basename, and fixed baseline ports to recommend APP_NAME, SERVER_LISTEN_PORT, DEV_SERVER_PORT, DEV_SERVER_HMR_PORT, and a derived API_BASE_URL, then writes only vona/env/.env.local and zova/env/.env.local after confirmation. It does not use a flavor-specific local file or reserve ports; Admin and Web are alternative non-concurrent commands using the shared tuple.",
       "files": []
     },

package/.claude/skills/cabloy-worktree-environment/SKILL.md

@@ -31,12 +31,12 @@ Interpretation:
 
 | Marker | Edition | Managed clean E2E command |
 | --- | --- | --- |
-| `__CABLOY_BASIC__` only | Cabloy Basic | `npm run test:e2e:basic:clean` |
+| `__CABLOY_BASIC__` only | Cabloy Basic | `npm run test:e2e` |
 | `__CABLOY_START__` only | Cabloy Start | `npm run test:e2e:start:clean` |
 
 Stop without edits when both markers are present, neither marker is present, the checkout is primary/unregistered, required environment directories are missing, or the selected edition's required scripts are unavailable.
 
-Read [Parallel Worktree Environment](../../../cabloy-docs/fullstack/parallel-worktree-environment.md) as the canonical shared recipe. Edition detection chooses command names and labels; it does not change the two-file environment model. Never change committed defaults, including `vona/env/.env` and `zova/env/.env`.
+Read [Parallel Worktree Environment](../../../repo-docs/fullstack/parallel-worktree-environment.md) as the canonical shared recipe. Edition detection chooses command names and labels; it does not change the two-file environment model. Never change committed defaults, including `vona/env/.env` and `zova/env/.env`.
 
 ## Step 2: Generate the standard environment recommendation
 
@@ -182,7 +182,7 @@ Run the edition-appropriate managed clean E2E command:
 
 ```bash
 # Cabloy Basic
-npm run test:e2e:basic:clean
+npm run test:e2e
 
 # Cabloy Start
 npm run test:e2e:start:clean

package/.claude/skills/cabloy-zova-source-reading/SKILL.md

@@ -74,17 +74,17 @@ That order reduces the risk of drifting into premature analogy before the source
 
 Do not begin by forcing the problem into generic Vue terminology.
 
-Start from the public frontend reading docs in `cabloy-docs/frontend/`.
+Start from the public frontend reading docs in `repo-docs/frontend/`.
 
 ### Primary reading surfaces
 
-- `cabloy-docs/frontend/reading-zova-for-vue-developers.md`
-- `cabloy-docs/frontend/zova-vs-vue3-comparison.md`
-- `cabloy-docs/frontend/zova-reactivity-under-the-hood.md`
-- `cabloy-docs/frontend/zova-source-reading-map.md`
-- `cabloy-docs/frontend/page-guide.md`
-- `cabloy-docs/frontend/component-guide.md`
-- `cabloy-docs/frontend/css-in-js-guide.md`
+- `repo-docs/frontend/reading-zova-for-vue-developers.md`
+- `repo-docs/frontend/zova-vs-vue3-comparison.md`
+- `repo-docs/frontend/zova-reactivity-under-the-hood.md`
+- `repo-docs/frontend/zova-source-reading-map.md`
+- `repo-docs/frontend/page-guide.md`
+- `repo-docs/frontend/component-guide.md`
+- `repo-docs/frontend/css-in-js-guide.md`
 
 For compact procedural summaries inside the skill bundle, also use:
 
@@ -93,25 +93,25 @@ For compact procedural summaries inside the skill bundle, also use:
 
 For locale-sensitive schema/form questions, also read:
 
-- `cabloy-docs/frontend/api-schema-guide.md`
-- `cabloy-docs/frontend/a-openapi-under-the-hood.md`
-- `cabloy-docs/frontend/form-guide.md`
-- `cabloy-docs/frontend/zova-form-under-the-hood.md`
+- `repo-docs/frontend/api-schema-guide.md`
+- `repo-docs/frontend/a-openapi-under-the-hood.md`
+- `repo-docs/frontend/form-guide.md`
+- `repo-docs/frontend/zova-form-under-the-hood.md`
 
 ### Core architecture surfaces
 
 Use these when the question needs broader architectural context:
 
-- `cabloy-docs/frontend/introduction.md`
-- `cabloy-docs/frontend/foundation.md`
-- `cabloy-docs/frontend/design-principles.md`
-- `cabloy-docs/frontend/ioc-and-beans.md`
-- `cabloy-docs/frontend/page-guide.md`
-- `cabloy-docs/frontend/component-guide.md`
-- `cabloy-docs/frontend/model-architecture.md`
-- `cabloy-docs/frontend/page-route-guide.md`
-- `cabloy-docs/frontend/behavior-guide.md`
-- `cabloy-docs/frontend/ssr-architecture-overview.md`
+- `repo-docs/frontend/introduction.md`
+- `repo-docs/frontend/foundation.md`
+- `repo-docs/frontend/design-principles.md`
+- `repo-docs/frontend/ioc-and-beans.md`
+- `repo-docs/frontend/page-guide.md`
+- `repo-docs/frontend/component-guide.md`
+- `repo-docs/frontend/model-architecture.md`
+- `repo-docs/frontend/page-route-guide.md`
+- `repo-docs/frontend/behavior-guide.md`
+- `repo-docs/frontend/ssr-architecture-overview.md`
 
 ## Step 4: Choose the shortest correct source-reading path
 
@@ -122,7 +122,7 @@ Use these bundled references to keep the workflow compact:
 - `references/analysis-modes.md`
 - `references/core-reading-paths.md`
 
-Use the public `cabloy-docs/frontend/zova-source-reading-map.md` as the fuller explanation layer, but use the bundled references first when they are enough for the current task.
+Use the public `repo-docs/frontend/zova-source-reading-map.md` as the fuller explanation layer, but use the bundled references first when they are enough for the current task.
 
 ### Locale-sensitive schema and form path
 

package/.claude/skills/cabloy-zova-source-reading/references/analysis-modes.md

@@ -15,7 +15,7 @@ Use this mode when the user is mainly asking:
 
 1. detect the active edition if UI-sensitive assumptions might matter
 2. start from the public frontend docs first
-3. pick the smallest matching thread from `cabloy-docs/frontend/zova-source-reading-map.md`
+3. pick the smallest matching thread from `repo-docs/frontend/zova-source-reading-map.md`
 4. cite the initial source files in the recommended reading order
 5. stop before tracing deeper runtime layers unless the user also wants runtime-flow analysis
 

package/.claude/skills/cabloy-zova-source-reading/references/core-reading-paths.md

@@ -103,9 +103,9 @@ Use when the question is about:
 
 Read in this order:
 
-1. `cabloy-docs/frontend/api-schema-guide.md`
-2. `cabloy-docs/frontend/a-openapi-under-the-hood.md`
-3. `cabloy-docs/frontend/form-guide.md` and `cabloy-docs/frontend/zova-form-under-the-hood.md` when a form consumes the schema
+1. `repo-docs/frontend/api-schema-guide.md`
+2. `repo-docs/frontend/a-openapi-under-the-hood.md`
+3. `repo-docs/frontend/form-guide.md` and `repo-docs/frontend/zova-form-under-the-hood.md` when a form consumes the schema
 4. `zova/src/suite-vendor/a-zova/modules/a-openapi/src/monkey.ts`
 5. `zova/src/suite-vendor/a-zova/modules/a-openapi/src/model/sdk.ts`
 6. `zova/src/suite-vendor/a-zova/modules/a-openapi/src/bean/sys.sdk.ts`

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

@@ -4,7 +4,7 @@ on:
     branches:
       - main
     paths:
-      - 'cabloy-docs/**'
+      - 'repo-docs/**'
       - 'README.md'
       - '.github/workflows/docs-pages.yml'
   workflow_dispatch:
@@ -32,19 +32,19 @@ jobs:
         with:
           node-version: 24
           cache: pnpm
-          cache-dependency-path: cabloy-docs/pnpm-lock.yaml
+          cache-dependency-path: repo-docs/pnpm-lock.yaml
       - name: install docs dependencies
-        run: pnpm --dir cabloy-docs install --frozen-lockfile
+        run: pnpm --dir repo-docs install --frozen-lockfile
       - name: build docs
         env:
           GA_MEASUREMENT_ID: ${{ vars.GA_MEASUREMENT_ID }}
-        run: pnpm --dir cabloy-docs docs:build
+        run: pnpm --dir repo-docs docs:build
       - name: setup pages
         uses: actions/configure-pages@v5
       - name: upload pages artifact
         uses: actions/upload-pages-artifact@v4
         with:
-          path: cabloy-docs/.vitepress/dist
+          path: repo-docs/.vitepress/dist
 
   deploy:
     needs: build

package/CHANGELOG.md

@@ -1,5 +1,18 @@
 # Changelog
 
+## 5.1.147
+
+### Improvements
+
+- Refactor repository-related components.
+
+## 5.1.146
+
+### Improvements
+
+- Refresh the Zova lockfile to prepare for compensation reruns.
+- Update the Vona Zova Core patch dependency to version 5.1.88.
+
 ## 5.1.145
 
 ### Features