cabloy 5.1.155 → 5.1.156

package/.cabloy-version

@@ -1 +1 @@
-5.1.155
+5.1.156

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

@@ -225,7 +225,7 @@ Important Cabloy Basic reverse-sync rule:
 - if the change was consumer-side, low-confidence, cross-edition, or happened outside the Claude hook path, run the reverse sync flow deliberately yourself
 - prefer visible proof under `zova/src/**/.metadata/**` when it is available; if the effective handoff only appears in `.zova-rest`, treat the safeguard as conservative reminder/auto-sync assistance rather than strict proof
 
-For Cabloy Start, verify the exact Start-specific flavor names, paths, SSR site baselines, and project assets in the licensed Start repo.
+For Cabloy Start, verify the exact Start-specific flavor names, paths, SSR site baselines, and project assets in the active Start repository.
 
 ### Schema-driven UI decision branch
 

package/.claude/skills/cabloy-spec-generation/SKILL.md

@@ -35,7 +35,7 @@ From the repository root, inspect:
 Interpret the markers as follows:
 
 - `__CABLOY_BASIC__` present: use Cabloy Basic source and public-doc assumptions;
-- `__CABLOY_START__` present: use Cabloy Start source and resolve its own licensed-site, UI, flavor, and command details;
+- `__CABLOY_START__` present: use Cabloy Start source and resolve its own site, UI, flavor, and command details;
 - neither present: do not make strong edition-specific assumptions; inspect the nearby project shape and ask the user to confirm the edition.
 
 Never copy Basic flavor names, SSR assumptions, UI-library assumptions, or exact command lines into a Start record without verifying them in the active Start repository. The document architecture is shared; edition-specific runtime facts are not.

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

@@ -267,12 +267,12 @@ Bias toward:
 
 Bias toward:
 
-- the private commercial edition
+- the public MIT-licensed edition maintained in its own repository
 - the Start repo marker
-- the licensed private repository source
+- the active Start repository source
 - Vuetify-sensitive examples
 - Start-specific frontend flavor names
-- Start-specific suites/modules, SSR site baselines, project assets, and licensed private-repo structure
+- Start-specific suites/modules, SSR site baselines, project assets, and separate-repository structure
 
 Do not silently reuse Basic examples when Start-specific assumptions matter.
 

package/CHANGELOG.md

@@ -1,5 +1,18 @@
 # Changelog
 
+## 5.1.156
+
+### Features
+
+- Add a `bean.role` adapter.
+- Update queue push capabilities.
+- Move documentation from `docs.cabloy.com` to `cabloy.com`.
+
+### Improvements
+
+- Refresh basic getting-started documentation and README content.
+- Update repository scripts documentation and package configuration.
+
 ## 5.1.155
 
 ### Features

package/CLAUDE.md

@@ -5,7 +5,7 @@
 Detect the active edition from the repository-root marker before making edition-sensitive assumptions:
 
 - exactly `__CABLOY_BASIC__` present → Cabloy Basic, the public framework/reference edition
-- exactly `__CABLOY_START__` present → Cabloy Start, the private commercial edition delivered as licensed source
+- exactly `__CABLOY_START__` present → Cabloy Start, the public MIT-licensed edition maintained in its own repository
 - both markers present → treat the checkout as invalid or ambiguous and stop before giving edition-specific guidance
 - neither marker present → inspect the owning `package.json` and nearby repository structure, then ask before making an edition-specific assumption
 

package/README.md

@@ -3,16 +3,16 @@
 [![License MIT](https://img.shields.io/badge/license-MIT-blue.svg)](https://github.com/cabloy/cabloy/blob/main/LICENSE)
 [![npm version](https://img.shields.io/npm/v/cabloy.svg?style=flat-square&label=cabloy)](https://www.npmjs.com/package/cabloy)
 [![npm downloads](https://img.shields.io/npm/dm/cabloy?color=orange&label=downloads)](https://www.npmjs.com/package/cabloy)
-[![Docs](https://img.shields.io/badge/docs-cabloy-4f46e5.svg?style=flat-square)](https://docs.cabloy.com)
+[![Docs](https://img.shields.io/badge/docs-cabloy-4f46e5.svg?style=flat-square)](https://cabloy.com)
 [![Demo](https://img.shields.io/badge/demo-cabloy.com-059669.svg?style=flat-square)](https://cabloy.com)
 
 Cabloy is a Node.js fullstack framework for AI vibe coding.
 
 **One fullstack system for AI vibe coding—bidirectional type sync, CLI-first workflows, docs, and skills.**
 
-Instead of stitching separate backend and frontend stacks together, Cabloy keeps their contracts, tooling, and guidance connected in one repository. Vona, Zova, and suite-based modules provide the aligned architecture behind that workflow.
+Instead of stitching separate backend and frontend stacks together, Cabloy keeps their contracts, tooling, and guidance connected in one repository. Vona is its backend framework and runtime layer, and Zova is its frontend framework and application layer. Cabloy Basic and Cabloy Start are related, complete edition baselines built on that shared architecture; see [Editions Overview](https://cabloy.com/editions/overview) for their deliberate differences.
 
-[Documentation](https://docs.cabloy.com) · [npm](https://www.npmjs.com/package/cabloy) · [Web Demo](https://cabloy.com) · [Admin Demo](https://cabloy.com/admin) · [GitHub](https://github.com/cabloy/cabloy)
+[Documentation](https://cabloy.com) · [npm](https://www.npmjs.com/package/cabloy) · [Web Demo](https://cabloy.com) · [Admin Demo](https://cabloy.com/admin) · [GitHub](https://github.com/cabloy/cabloy)
 
 ## Fullstack Principles
 
@@ -27,7 +27,7 @@ Cabloy’s fullstack model is built around two core principles:
    - **Backend -> Frontend**: Vona emits Swagger/OpenAPI contracts that Zova can use to generate SDKs and related schema-aware helpers
    - **Frontend -> Backend**: Zova generates structural metadata and typing surfaces such as routes, components, and icons that can improve backend-side tooling and type hints
 
-For the complete explanation, see [Fullstack Introduction](https://docs.cabloy.com/fullstack/introduction), [Vona + Zova Integration](https://docs.cabloy.com/fullstack/vona-zova-integration), [Backend OpenAPI to Frontend SDK](https://docs.cabloy.com/fullstack/openapi-to-sdk), and [Frontend Metadata Back to Backend](https://docs.cabloy.com/fullstack/frontend-metadata-to-backend).
+For the complete explanation, see [Fullstack Introduction](https://cabloy.com/fullstack/introduction), [Vona + Zova Integration](https://cabloy.com/fullstack/vona-zova-integration), [Backend OpenAPI to Frontend SDK](https://cabloy.com/fullstack/openapi-to-sdk), and [Frontend Metadata Back to Backend](https://cabloy.com/fullstack/frontend-metadata-to-backend).
 
 ## Get Started
 
@@ -82,17 +82,17 @@ pnpm_config_minimum_release_age=0 npm create cabloy
 
 If you already created the project directory and only need to rerun initialization, use the same environment variable with `npm run init`.
 
-For **Cabloy Start**, purchase access to the licensed private repository, clone `git@github.com:cabloy/cabloy-start.git`, and run `npm run init`. For the complete Start onboarding flow, read the [Cabloy Start](https://docs.cabloy.com/editions/cabloy-start) page.
+For **Cabloy Start**, clone the public MIT-licensed repository at `https://github.com/cabloy/cabloy-start`, then run `npm run init`. For the complete Start onboarding flow, read the [Cabloy Start](https://cabloy.com/editions/cabloy-start) page.
 
 Then continue with the framework docs:
 
-- [Fullstack Quickstart](https://docs.cabloy.com/fullstack/quickstart)
-- [Documentation](https://docs.cabloy.com)
-- [Fullstack Introduction](https://docs.cabloy.com/fullstack/introduction)
-- [Backend Introduction](https://docs.cabloy.com/backend/introduction)
-- [Frontend Introduction](https://docs.cabloy.com/frontend/introduction)
-- [Editions Overview](https://docs.cabloy.com/editions/overview)
-- [Choosing Between Cabloy Basic and Cabloy Start](https://docs.cabloy.com/editions/choosing-between-basic-and-start)
+- [Fullstack Quickstart](https://cabloy.com/fullstack/quickstart)
+- [Documentation](https://cabloy.com)
+- [Fullstack Introduction](https://cabloy.com/fullstack/introduction)
+- [Backend Introduction](https://cabloy.com/backend/introduction)
+- [Frontend Introduction](https://cabloy.com/frontend/introduction)
+- [Editions Overview](https://cabloy.com/editions/overview)
+- [Choosing Between Cabloy Basic and Cabloy Start](https://cabloy.com/editions/choosing-between-basic-and-start)
 
 To upgrade an existing Cabloy project:
 
@@ -168,16 +168,16 @@ npm run build
 
 For more details, see:
 
-- [Editions Overview](https://docs.cabloy.com/editions/overview)
-- [Choosing Between Cabloy Basic and Cabloy Start](https://docs.cabloy.com/editions/choosing-between-basic-and-start)
-- [Repo Scripts](https://docs.cabloy.com/reference/repo-scripts)
-- [Package Map](https://docs.cabloy.com/reference/package-map)
-- [AI Development Introduction](https://docs.cabloy.com/ai/introduction)
+- [Editions Overview](https://cabloy.com/editions/overview)
+- [Choosing Between Cabloy Basic and Cabloy Start](https://cabloy.com/editions/choosing-between-basic-and-start)
+- [Repo Scripts](https://cabloy.com/reference/repo-scripts)
+- [Package Map](https://cabloy.com/reference/package-map)
+- [AI Development Introduction](https://cabloy.com/ai/introduction)
 
 Contribution guidelines:
 
 - prefer CLI-backed workflows with `npm run vona` and `npm run zova`
-- put user-facing and agent-facing guidance in [docs.cabloy.com](https://docs.cabloy.com)
+- put user-facing and agent-facing guidance in [cabloy.com](https://cabloy.com)
 - put maintainer rationale, architecture notes, and engineering ADRs in [repo-docs-internal/](https://github.com/cabloy/cabloy/tree/main/repo-docs-internal)
 - put product and business specifications, delivery plans, and suite-local ADRs in [repo-specs/](https://github.com/cabloy/cabloy/tree/main/repo-specs)
 - verify framework changes with the narrowest meaningful checks first, then shared root scripts when broader confidence is needed

package/package.json

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

package/repo-docs/.vitepress/public/CNAME

@@ -1 +1 @@
-docs.cabloy.com
+cabloy.com

package/repo-docs/ai/edition-consistency-checklist.md

@@ -16,8 +16,8 @@ Before checking details, confirm that the content still tells the same baseline
 
 - **Cabloy Basic** is the public framework/reference edition
 - `npm create cabloy` creates the default Cabloy Basic project route
-- **Cabloy Start** is the private commercial edition
-- Cabloy Start is used by cloning the licensed private repository source directly
+- **Cabloy Start** is the public MIT-licensed edition maintained in its own repository
+- Cabloy Start is used by cloning its public repository directly and following its initialization workflow
 - both editions share the same Cabloy fullstack core
 - both editions share a frontend engineering layer built around Zova, Vue, Vite, Quasar tooling, and related libraries
 - the editions diverge in UI layer, frontend flavors, suites/modules, SSR site baselines, project assets, and some generated outputs
@@ -38,13 +38,13 @@ Confirm that the content:
 Confirm that the content states or implies the right project-entry model:
 
 - **Cabloy Basic** → `npm create cabloy`
-- **Cabloy Start** → licensed private repository clone
+- **Cabloy Start** → public repository clone and edition-specific initialization workflow
 
 Watch for drift such as:
 
 - implying that Cabloy Start is created through `npm create cabloy`
 - implying that both editions use the same bootstrap path
-- omitting the Start licensing/private-repo model when it matters to the workflow
+- omitting the Start public-repository and edition-specific initialization model when it matters to the workflow
 
 ## Checklist 3: shared core vs edition divergence is separated cleanly
 
@@ -88,7 +88,7 @@ Avoid wording that makes Quasar sound like the edition UI component library when
 For scripts, flavors, paths, and examples, confirm that:
 
 - Basic examples use Basic markers and Basic flavor names
-- Start examples tell the reader to verify the Start repo directly
+- Start examples tell the reader to verify the active Start repository directly
 - Start workflows do not silently reuse Basic script or flavor assumptions
 - SSR site baseline assumptions match the edition being discussed
 - project-asset references match the repo being discussed
@@ -119,7 +119,7 @@ When content ends with verification steps, confirm that it reminds the reader or
 - generated outputs
 - project assets
 
-For Start-sensitive workflows, confirm that verification points back to the licensed Start repository rather than pretending the current Basic repo is the direct source of truth.
+For Start-sensitive workflows, confirm that verification points back to the active Start repository rather than pretending the current Basic repo is the direct source of truth.
 
 ## Checklist 8: wording about system size stays appropriately scoped
 
@@ -137,7 +137,7 @@ Before you finish an edition-aware change, ask:
 1. Did I clearly separate shared core from edition-specific divergence?
 2. Did I preserve the correct Basic vs Start creation path?
 3. Did I avoid turning UI difference into the whole story?
-4. Did I point Start-specific operational truth back to the licensed Start repo where needed?
+4. Did I point Start-specific operational truth back to the active Start repository where needed?
 5. Do docs, rules, and skills each play their proper role?
 
 ## Read together with

package/repo-docs/backend/quickstart.md

@@ -87,7 +87,7 @@ Legacy Vona docs described creating projects from templates such as `cabloy-basi
 That history still matters, because it explains why the Cabloy ecosystem now supports two editions:
 
 - **Cabloy Basic**: the public framework/reference edition, including the project route created by `npm create cabloy`, with a shared frontend engineering layer and a DaisyUI + Tailwind CSS oriented UI layer in the current public examples
-- **Cabloy Start**: the private commercial edition, accessed by cloning the licensed private repository source, with a Vuetify-oriented UI layer plus edition-specific SSR site baselines and project assets
+- **Cabloy Start**: the public MIT-licensed edition maintained in its own repository, accessed by cloning that repository and following its initialization workflow, with a Vuetify-oriented UI layer plus edition-specific SSR site baselines and project assets
 
 In the current monorepo docs, do not treat these as just template names. Treat them as edition boundaries that affect frontend integration, scripts, UI assumptions, and examples.
 

package/repo-docs/blogs/ai-react-nextjs-enterprise-architecture-cabloy/index.md

@@ -163,15 +163,15 @@ npm run dev:zova:admin
 npm run dev:zova:web
 ```
 
-Then follow the [Cabloy Fullstack Quick Start Tutorials](https://docs.cabloy.com/fullstack/tutorials-overview). Start with a small module and experience how CRUD, frontend/backend contract sharing, and a fullstack workflow connect in practice.
+Then follow the [Cabloy Fullstack Quick Start Tutorials](https://cabloy.com/fullstack/tutorials-overview). Start with a small module and experience how CRUD, frontend/backend contract sharing, and a fullstack workflow connect in practice.
 
-If you are looking not for another component library or another Next.js starter, but for a framework built for enterprise fullstack collaboration, start with the [Cabloy Fullstack Quickstart](https://docs.cabloy.com/fullstack/quickstart) and give CabloyJS a try.
+If you are looking not for another component library or another Next.js starter, but for a framework built for enterprise fullstack collaboration, start with the [Cabloy Fullstack Quickstart](https://cabloy.com/fullstack/quickstart) and give CabloyJS a try.
 
 ## Further reading
 
-- [Cabloy Fullstack Introduction](https://docs.cabloy.com/fullstack/introduction)
-- [Cabloy Fullstack Quickstart](https://docs.cabloy.com/fullstack/quickstart)
-- [Cabloy Suites and Modules](https://docs.cabloy.com/fullstack/suites-and-modules)
-- [Cabloy Vona + Zova Integration](https://docs.cabloy.com/fullstack/vona-zova-integration)
-- [Cabloy Contract Loop Playbook](https://docs.cabloy.com/fullstack/contract-loop-playbook)
-- [Cabloy Fullstack Quick Start Tutorials](https://docs.cabloy.com/fullstack/tutorials-overview)
+- [Cabloy Fullstack Introduction](https://cabloy.com/fullstack/introduction)
+- [Cabloy Fullstack Quickstart](https://cabloy.com/fullstack/quickstart)
+- [Cabloy Suites and Modules](https://cabloy.com/fullstack/suites-and-modules)
+- [Cabloy Vona + Zova Integration](https://cabloy.com/fullstack/vona-zova-integration)
+- [Cabloy Contract Loop Playbook](https://cabloy.com/fullstack/contract-loop-playbook)
+- [Cabloy Fullstack Quick Start Tutorials](https://cabloy.com/fullstack/tutorials-overview)

package/repo-docs/blogs/cabloy-fullstack-resource-addressing/index.md

@@ -36,7 +36,7 @@ This is not one universal string that travels through every layer, nor is it zer
 
 IoC asks a focused question: **who creates, owns, disposes of, and supplies a runtime capability?**
 
-In Zova, a Bean may be held in the `sys`, `app`, or `ctx` container scope. Code can use `@Use` for injection or use containers and Scope for dependency lookup. This single model keeps state sharing, lifecycle behavior, and cross-module collaboration from drifting into unrelated mechanisms. [IoC and Beans](https://docs.cabloy.com/frontend/ioc-and-beans) explains that model in detail.
+In Zova, a Bean may be held in the `sys`, `app`, or `ctx` container scope. Code can use `@Use` for injection or use containers and Scope for dependency lookup. This single model keeps state sharing, lifecycle behavior, and cross-module collaboration from drifting into unrelated mechanisms. [IoC and Beans](https://cabloy.com/frontend/ioc-and-beans) explains that model in detail.
 
 Addressing asks a broader question: **when one layer needs something, which identity expresses the target, who resolves it, and what kind of resource results?**
 
@@ -66,7 +66,7 @@ Cabloy defines a **suite** as a business-domain composition boundary and a **mod
 
 In the Student sample, the domain is `a-training` and the module is `training-student`. Vona and Zova both have corresponding suite/module structures, so backend Controllers, Services, Models, Entities, and DTOs can evolve along the same business boundary as frontend pages, APIs, Models, and metadata. What is shared first is a **business coordinate**, not a block of memory shared by Node.js and the browser.
 
-That is why a module name matters more than a directory position. Directories can be reorganized and implementation files can move, while a stable module namespace can continue to carry the logical identity of Services, Models, APIs, locales, errors, Resources, and frontend render resources. See [Suites and Modules](https://docs.cabloy.com/fullstack/suites-and-modules) for the boundary between suites and modules.
+That is why a module name matters more than a directory position. Directories can be reorganized and implementation files can move, while a stable module namespace can continue to carry the logical identity of Services, Models, APIs, locales, errors, Resources, and frontend render resources. See [Suites and Modules](https://cabloy.com/fullstack/suites-and-modules) for the boundary between suites and modules.
 
 ## Coordinate two: Bean full names and the Scope facade
 
@@ -101,7 +101,7 @@ const students = await this.scope.model.student.select();
 const sku = await this.$scope.commerceCatalog.model.sku.getById(id);
 ```
 
-Scope does not create another identity system. It raises a container-level full name into an everyday way to navigate a module’s resource catalog. Backend Scope can organize services, models, entities, configuration, locales, and errors; frontend Scope commonly exposes facades for configuration, constants, locales, errors, APIs, and API Schemas. Both [Vona Backend Foundation](https://docs.cabloy.com/backend/foundation) and [Zova Module Scope](https://docs.cabloy.com/frontend/module-scope) describe that division of responsibility.
+Scope does not create another identity system. It raises a container-level full name into an everyday way to navigate a module’s resource catalog. Backend Scope can organize services, models, entities, configuration, locales, and errors; frontend Scope commonly exposes facades for configuration, constants, locales, errors, APIs, and API Schemas. Both [Vona Backend Foundation](https://cabloy.com/backend/foundation) and [Zova Module Scope](https://cabloy.com/frontend/module-scope) describe that division of responsibility.
 
 There is an important limit: Scope lookup can resolve only resources from modules that have already been composed into the active application. A correct string does not install, load, or order an absent module. Module dependencies, suite/application composition, and runtime lookup are related but different concerns. The first establishes availability, ordering, and versioning; only then can the latter retrieve a resource from the composed modules.
 
@@ -187,7 +187,7 @@ If this field needs specialized controls instead of the default Renderer, it can
 
 That does not mean each field automatically grows a complete UI, nor that every presentation decision belongs in the backend. It means the field’s business meaning, data contract, and permitted exposure do not have to be copied into backend DTOs, frontend request types, form rules, table columns, and response post-processing—and then manually kept aligned.
 
-In this **forward contract chain**, backend Controllers, DTOs, Entities, and validation rules are the source of truth. Vona generates OpenAPI; Zova then generates or consumes SDK/Schema contract material. When a backend contract changes, the recommended path is to propagate that truth forward rather than hand-edit multiple frontend copies. [Backend OpenAPI to Frontend SDK](https://docs.cabloy.com/fullstack/openapi-to-sdk) and [One Contract Surface, Four Uses](https://docs.cabloy.com/fullstack/tutorial-6-one-contract-four-uses) describe the boundary of that chain.
+In this **forward contract chain**, backend Controllers, DTOs, Entities, and validation rules are the source of truth. Vona generates OpenAPI; Zova then generates or consumes SDK/Schema contract material. When a backend contract changes, the recommended path is to propagate that truth forward rather than hand-edit multiple frontend copies. [Backend OpenAPI to Frontend SDK](https://cabloy.com/fullstack/openapi-to-sdk) and [One Contract Surface, Four Uses](https://cabloy.com/fullstack/tutorial-6-one-contract-four-uses) describe the boundary of that chain.
 
 ## Coordinate five: routes choose a UI scene; Resource identities choose business context
 
@@ -280,7 +280,7 @@ This has two practical benefits:
 
 For example, a `training-student` frontend Model can initialize the generic owner with `training-student:student`, then add semantic entry points for business actions such as `summary(id)` or `deleteForce(id)` while reusing that owner’s item query, mutation, and invalidation boundary.
 
-One more distinction matters: a call-site value such as `['select', ...]` or `['item', id, action]` is only a logical query key. The effective cache identity also incorporates Model Bean identity and selector. A short query key is therefore not an address that is globally unique across the application. [Model Resource Internals Deep Dive](https://docs.cabloy.com/frontend/model-resource-internals-deep-dive) and [Model State Guide](https://docs.cabloy.com/frontend/model-state-guide) explain this owner/state identity layer.
+One more distinction matters: a call-site value such as `['select', ...]` or `['item', id, action]` is only a logical query key. The effective cache identity also incorporates Model Bean identity and selector. A short query key is therefore not an address that is globally unique across the application. [Model Resource Internals Deep Dive](https://cabloy.com/frontend/model-resource-internals-deep-dive) and [Model State Guide](https://cabloy.com/frontend/model-state-guide) explain this owner/state identity layer.
 
 ## Coordinate seven: Schema metadata selects concrete UI capabilities
 
@@ -336,7 +336,7 @@ In other words, `schemaRow` is the current select-response row Schema, and `rest
 
 Cabloy resource addressing therefore does not stop at an API. Table cells, form fields, image scenes, and Behaviors can also be selected through module-qualified, scene-aware frontend resource identities. Field metadata can, for example, refer to `training-student:formFieldLevel`, which a registered frontend capability resolves and renders.
 
-This does not mean backend code executes frontend components. More precisely, backend contracts or metadata can declare which frontend rendering resource should be selected at a point; the frontend still owns the renderer implementation and runtime. Frontend-owned facts such as routes, components, icons, table cells, and form fields also have a reverse contract handoff: refresh the frontend metadata/build output first, then let Vona consume the synchronized local dependency result. [Frontend Metadata Back to Backend](https://docs.cabloy.com/fullstack/frontend-metadata-to-backend) describes that reverse chain.
+This does not mean backend code executes frontend components. More precisely, backend contracts or metadata can declare which frontend rendering resource should be selected at a point; the frontend still owns the renderer implementation and runtime. Frontend-owned facts such as routes, components, icons, table cells, and form fields also have a reverse contract handoff: refresh the frontend metadata/build output first, then let Vona consume the synchronized local dependency result. [Frontend Metadata Back to Backend](https://cabloy.com/fullstack/frontend-metadata-to-backend) describes that reverse chain.
 
 The two directions are distinct:
 
@@ -407,13 +407,13 @@ IoC is one runtime foundation of that chain, but not the whole chain. The engine
 
 ### Concepts and workflows
 
-- [Cabloy: Suites and Modules](https://docs.cabloy.com/fullstack/suites-and-modules)
-- [Cabloy: Vona Backend Foundation](https://docs.cabloy.com/backend/foundation)
-- [Cabloy: Zova IoC and Beans](https://docs.cabloy.com/frontend/ioc-and-beans)
-- [Cabloy: Zova Module Scope](https://docs.cabloy.com/frontend/module-scope)
-- [Cabloy: Backend OpenAPI to Frontend SDK](https://docs.cabloy.com/fullstack/openapi-to-sdk)
-- [Cabloy: Frontend Metadata Back to Backend](https://docs.cabloy.com/fullstack/frontend-metadata-to-backend)
-- [Cabloy: Model Resource Internals Deep Dive](https://docs.cabloy.com/frontend/model-resource-internals-deep-dive)
+- [Cabloy: Suites and Modules](https://cabloy.com/fullstack/suites-and-modules)
+- [Cabloy: Vona Backend Foundation](https://cabloy.com/backend/foundation)
+- [Cabloy: Zova IoC and Beans](https://cabloy.com/frontend/ioc-and-beans)
+- [Cabloy: Zova Module Scope](https://cabloy.com/frontend/module-scope)
+- [Cabloy: Backend OpenAPI to Frontend SDK](https://cabloy.com/fullstack/openapi-to-sdk)
+- [Cabloy: Frontend Metadata Back to Backend](https://cabloy.com/fullstack/frontend-metadata-to-backend)
+- [Cabloy: Model Resource Internals Deep Dive](https://cabloy.com/frontend/model-resource-internals-deep-dive)
 
 ### Source samples verified for this article
 

package/repo-docs/blogs/vue-object-oriented-zova-beginner-mental-model/index.md

@@ -475,9 +475,9 @@ If you already know Vue 3, try writing one small Zova feature: one Controller, o
 
 ## Further reading
 
-- [Zova Frontend Foundation](https://docs.cabloy.com/frontend/foundation)
-- [Reading Zova for Vue Developers](https://docs.cabloy.com/frontend/reading-zova-for-vue-developers)
-- [Zova vs Vue 3 Comparison](https://docs.cabloy.com/frontend/zova-vs-vue3-comparison)
-- [IoC and Beans](https://docs.cabloy.com/frontend/ioc-and-beans)
-- [State Architecture for Vue Developers](https://docs.cabloy.com/frontend/state-architecture-for-vue-developers)
-- [Model Architecture](https://docs.cabloy.com/frontend/model-architecture)
+- [Zova Frontend Foundation](https://cabloy.com/frontend/foundation)
+- [Reading Zova for Vue Developers](https://cabloy.com/frontend/reading-zova-for-vue-developers)
+- [Zova vs Vue 3 Comparison](https://cabloy.com/frontend/zova-vs-vue3-comparison)
+- [IoC and Beans](https://cabloy.com/frontend/ioc-and-beans)
+- [State Architecture for Vue Developers](https://cabloy.com/frontend/state-architecture-for-vue-developers)
+- [Model Architecture](https://cabloy.com/frontend/model-architecture)

package/repo-docs/editions/cabloy-start.md

@@ -1,6 +1,6 @@
 # Cabloy Start
 
-Cabloy Start is the private commercial edition. It is a sibling private repository that shares the Cabloy fullstack direction while intentionally differing from Cabloy Basic.
+Cabloy Start is the public MIT-licensed edition. It is a sibling repository that shares the Cabloy fullstack direction while intentionally differing from Cabloy Basic.
 
 ## Repository marker
 
@@ -14,27 +14,25 @@ Use that marker before choosing examples, UI assumptions, or automation behavior
 
 Use Cabloy Start as the edition-aware target when work depends on:
 
-- direct use of the licensed private repository source
+- direct use of the public Cabloy Start repository source
 - Vuetify-specific frontend workflows
 - Cabloy Start flavor names in frontend scripts
-- edition-specific module composition in the licensed Start repository
-- licensed private-repo structure and edition-specific project composition
+- edition-specific module composition in the active Start repository
+- separate-repository structure and edition-specific project composition
 - edition-specific SSR site baselines and project assets
 
-## Get access and initialize
+## Clone and initialize
 
-Cabloy Start is the private commercial edition. It does not use the default `npm create cabloy` project route.
+Cabloy Start is public and MIT-licensed. It does not use the default `npm create cabloy` project route.
 
 To use Cabloy Start:
 
-1. purchase a license and obtain repository access
-2. clone the private repository source directly
-3. run the edition initialization flow in the cloned project
+1. clone the public repository directly
+2. run the edition initialization flow in the cloned project
 
-Access surfaces:
+Repository:
 
-- Purchase page: `https://cabloy.com/module/cabloy-start`
-- Repository: `https://github.com/cabloy/cabloy-start`
+- `https://github.com/cabloy/cabloy-start`
 
 Clone the repository:
 

package/repo-docs/editions/choosing-between-basic-and-start.md

@@ -6,7 +6,7 @@ This guide helps you choose the right Cabloy edition before you start a new proj
 
 Choose **Cabloy Basic** when you want the public framework/reference edition, the default `npm create cabloy` project route, and a faster path for open, community-oriented, or small-to-medium system development.
 
-Choose **Cabloy Start** when you want the private commercial edition, purchase-based access to the licensed private repository source, and a stronger baseline for more complex business systems built around Start-oriented SSR sites, project assets, and a Vuetify-aligned UI layer.
+Choose **Cabloy Start** when you want the public MIT-licensed edition in its own repository and a stronger baseline for more complex business systems built around Start-oriented SSR sites, project assets, and a Vuetify-aligned UI layer.
 
 ## What stays the same in both editions
 
@@ -35,9 +35,8 @@ Cabloy Basic is usually the better fit when you want:
 
 Cabloy Start is usually the better fit when you want:
 
-- the private commercial edition
-- purchase-based access to the licensed private repository source
-- direct cloning of the Start repository after authorization
+- the public MIT-licensed edition maintained in its own repository
+- direct cloning of the public Start repository
 - Start-specific flavors, SSR site baselines, and project assets
 - a UI layer aligned with Vuetify
 - a stronger starting point for more complex business systems
@@ -48,7 +47,7 @@ Cabloy Start is usually the better fit when you want:
 ### Project creation path
 
 - **Cabloy Basic**: create the project with `npm create cabloy`
-- **Cabloy Start**: purchase access, clone the licensed private repository source directly, then run `npm run init`
+- **Cabloy Start**: clone the public repository directly, then run `npm run init`
 
 ### UI strategy
 
@@ -58,7 +57,7 @@ Cabloy Start is usually the better fit when you want:
 ### Repo and asset model
 
 - **Cabloy Basic**: public repository and public reference materials
-- **Cabloy Start**: private repository with edition-specific SSR sites and project assets
+- **Cabloy Start**: separate public repository with edition-specific SSR sites and project assets
 
 ### AI workflow assumptions
 
@@ -72,7 +71,7 @@ This is why edition detection matters so much for AI vibe coding.
 Use this rule when you need a fast decision:
 
 1. If you want the public, default, `npm create cabloy` path, choose **Cabloy Basic**.
-2. If you want the licensed private repo with Start-oriented assets, a Vuetify-based business-system baseline, and a clone-plus-`npm run init` onboarding path, choose **Cabloy Start**.
+2. If you want the public MIT-licensed Start repository with Start-oriented assets, a Vuetify-based business-system baseline, and a clone-plus-`npm run init` onboarding path, choose **Cabloy Start**.
 3. If AI workflow accuracy matters for UI generation, SSR site assumptions, or flavor-specific commands, confirm the edition before writing prompts, rules, skills, or docs.
 
 ## Read together with

package/repo-docs/editions/detection.md

@@ -16,7 +16,7 @@ The two editions share many concepts but differ in important operational details
 - frontend UI library assumptions
 - flavor-specific frontend scripts
 - module availability
-- value-add project content in the private Start repository
+- Start-specific value-add project content
 
 If an agent skips edition detection, it may generate the wrong instructions, recommend the wrong module, or use the wrong UI stack.
 

package/repo-docs/editions/overview.md

@@ -7,7 +7,19 @@ Cabloy currently supports two related but distinct editions:
 - **Cabloy Basic**
 - **Cabloy Start**
 
-They share one Cabloy fullstack architecture, but they are distributed, composed, and optimized differently.
+They share one Cabloy fullstack architecture, but they are composed and optimized differently.
+
+## How the names fit together
+
+| Name         | Functional role                                                                   |
+| ------------ | --------------------------------------------------------------------------------- |
+| Cabloy       | The coordinated Node.js fullstack system.                                         |
+| Vona         | Cabloy's backend framework and runtime layer.                                     |
+| Zova         | Cabloy's frontend framework and application layer.                                |
+| Cabloy Basic | The public reference and community edition baseline.                              |
+| Cabloy Start | The public MIT-licensed business-system edition baseline in a sibling repository. |
+
+Vona and Zova answer the architectural-layer question. Cabloy Basic and Cabloy Start answer the complete-edition-baseline question: both use the shared Cabloy architecture, but their UI, frontend flavors, modules, SSR baselines, project assets, generated outputs, root scripts, and onboarding paths can differ.
 
 If you need a recommendation path, start with [Choosing Between Cabloy Basic and Cabloy Start](/editions/choosing-between-basic-and-start).
 
@@ -26,7 +38,7 @@ Use this page as the main editions hub, then choose the path that matches your t
 
 ### Selection path
 
-Start here when the task is about choosing the right edition baseline or understanding distribution differences:
+Start here when the task is about choosing the right edition baseline or understanding their differences:
 
 - [Choosing Basic vs Start](/editions/choosing-between-basic-and-start)
 - [Cabloy Basic](/editions/cabloy-basic)
@@ -44,17 +56,17 @@ Use this path when the task is about repo-aware automation, flavor assumptions,
 
 Both editions are built around the same core direction:
 
-- **Vona** as the backend framework
-- **Zova** as the frontend framework
+- **Vona** as the backend framework and runtime layer
+- **Zova** as the frontend framework and application layer
 - suite-based modules across the stack
 - root-level `npm run vona` and `npm run zova` entrypoints
 - CLI-backed workflows for generation, refactoring, metadata, and verification
 
-This means the editions are related fullstack baselines, not unrelated products.
+This means the editions are related fullstack baselines, not unrelated products or alternatives to Vona and Zova.
 
 ## What "Basic" means
 
-Cabloy Basic is the public framework/reference edition.
+Cabloy Basic is the public reference and community edition of Cabloy.
 
 - this public repository is marked with `__CABLOY_BASIC__`
 - projects created with `npm create cabloy` follow the Cabloy Basic route
@@ -64,14 +76,13 @@ Cabloy Basic is the open-source community edition and is optimized for public re
 
 ## What "Start" means
 
-Cabloy Start is the private commercial edition.
+Cabloy Start is the public MIT-licensed edition maintained in its own repository.
 
-- the private repository is marked with `__CABLOY_START__`
-- users first purchase a license and obtain repository access, then clone the private repository source directly
-- after cloning, the project is initialized through the Start edition workflow
-- Start uses its own edition-specific flavors, SSR site baselines, and project assets for that edition
+- the public repository is marked with `__CABLOY_START__`
+- users clone the public repository source directly, then run `npm run init`
+- Start uses its own edition-specific flavors, SSR site baselines, and project assets
 
-Cabloy Start is optimized as a commercial baseline for more complex business systems while staying on the same Cabloy fullstack direction.
+Cabloy Start is optimized as a business-system baseline for more complex systems while staying on the same Cabloy fullstack direction.
 
 ## Architecture layering
 
@@ -105,7 +116,8 @@ The editions intentionally diverge in several surfaces:
 - frontend flavor names
 - suite and module composition
 - admin/web SSR site baselines
-- licensed private-repo structure and edition-specific project assets
+- separate-repository structure and edition-specific project assets
+- generated outputs and root scripts
 - rules, skills, and docs used for AI vibe coding
 
 For example:
@@ -134,5 +146,5 @@ Write shared explanations once. Split or annotate only when a workflow changes b
 - UI library assumptions
 - frontend flavor names
 - different modules or assets
-- distribution and authorization model
+- repository and initialization model
 - edition-specific scripts, generated outputs, or AI workflow guidance

package/repo-docs/frontend/foundation.md

@@ -28,7 +28,7 @@ That flexibility matters directly for Cabloy’s edition model:
 
 - **Shared frontend engineering layer**: both editions follow the same Zova-centered frontend direction, with Vue, Vite, Quasar tooling, and related libraries
 - **Cabloy Basic UI layer**: current public docs and examples align with DaisyUI + Tailwind CSS
-- **Cabloy Start UI layer**: the private commercial edition aligns with Vuetify-oriented frontend workflows and may use different module composition and SSR site baselines
+- **Cabloy Start UI layer**: the public MIT-licensed edition aligns with Vuetify-oriented frontend workflows and may use different module composition and SSR site baselines
 
 So docs and skills must separate shared Zova principles from edition-specific UI assumptions.
 

package/repo-docs/frontend/introduction.md

@@ -137,6 +137,6 @@ Frontend work is where Cabloy Basic and Cabloy Start differ most clearly.
 
 - **Shared frontend engineering layer**: both editions follow the same Zova-centered frontend direction, with Vue, Vite, Quasar tooling, and related libraries.
 - **Cabloy Basic UI layer**: current public docs and examples align with DaisyUI + Tailwind CSS.
-- **Cabloy Start UI layer**: the private commercial edition aligns with Vuetify and may use different frontend modules, SSR site baselines, and project assets.
+- **Cabloy Start UI layer**: the public MIT-licensed edition aligns with Vuetify and may use different frontend modules, SSR site baselines, and project assets.
 
 Because of this, automation and docs should always detect the active edition before recommending page-level, component-level, or UI-library-specific work.

package/repo-docs/frontend/scripts.md

@@ -84,7 +84,7 @@ For the complete tag vocabulary, managed-runner argument boundaries, and externa
 
 ## Cabloy Start root wrappers
 
-Cabloy Start is the licensed private edition. Its default root wrappers use the `cabloyStartAdmin` and `cabloyStartWeb` flavors:
+Cabloy Start is the public MIT-licensed edition. Its default root wrappers use the `cabloyStartAdmin` and `cabloyStartWeb` flavors:
 
 ```bash
 npm run dev:zova:admin
@@ -160,7 +160,7 @@ cd zova && npm run build:rest:cabloyBasicAdmin
 
 ## Cabloy Start
 
-The licensed private repository supports Start-specific flavors:
+The separate public Cabloy Start repository supports Start-specific flavors:
 
 - `cabloyStartAdmin`
 - `cabloyStartWeb`

package/repo-docs/fullstack/deploy-cloudflare-docker.md

@@ -124,7 +124,7 @@ For a public route, the default response header depends on whether the URL ident
 | missing or false `meta.locale` | `Cache-Control: no-cache, no-store, must-revalidate`                     | Not stored                        |
 | `session` profile              | `Cache-Control: private, no-store`                                       | Not stored                        |
 
-For Cabloy Start, verify the effective Web and Admin values in the licensed Start repository before creating the Cloudflare rule. The rule design remains the same: preserve and follow the origin `Cache-Control` response instead of replacing it.
+For Cabloy Start, verify the effective Web and Admin values in the active Start repository before creating the Cloudflare rule. The rule design remains the same: preserve and follow the origin `Cache-Control` response instead of replacing it.
 
 A route can override the flavor default through SSR route metadata. An explicit public `meta.ssrProfileOptions.responseCache` policy remains authoritative; the Cloudflare rule follows the resulting response contract and does not replace it.