cabloy 5.1.50 → 5.1.52

package/cabloy-docs/fullstack/comparison-with-other-frameworks.md

@@ -0,0 +1,117 @@
+# Comparison with Other Frameworks
+
+This page shows how **Cabloy** differs from several common framework choices, so readers can quickly see where Cabloy stands out as a Node.js fullstack framework system and which strengths come from the fullstack system as a whole versus the backend layer provided by **Vona**.
+
+## What is being compared
+
+Cabloy is a **Node.js fullstack framework system**.
+
+That means the comparison is not only about a backend runtime or only about a frontend stack. It is about how **Vona** on the backend and **Zova** on the frontend stay aligned through shared conventions, shared scripts, SSR-aware delivery modes, and cross-stack generation workflows.
+
+For the broader Cabloy model, start with these pages:
+
+- [Fullstack Introduction](/fullstack/introduction)
+- [Vona + Zova Integration](/fullstack/vona-zova-integration)
+- [Backend OpenAPI to Frontend SDK](/fullstack/openapi-to-sdk)
+- [Frontend Metadata Back to Backend](/fullstack/frontend-metadata-to-backend)
+
+## Comparison lens
+
+The sections below use the same comparison lens each time:
+
+- **System center** — what the framework treats as the main architectural center
+- **Backend model** — how much backend structure and infrastructure the framework provides by default
+- **Frontend and admin model** — how the UI side is expected to evolve
+- **Cross-stack workflow** — how backend/frontend contracts and generation workflows stay aligned
+- **Best fit** — the kind of team or project the framework fits most naturally
+
+## Cabloy vs Next.js
+
+| Perspective              | Cabloy                                                                                         | Next.js                                                                |
+| ------------------------ | ---------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------- |
+| System center            | One framework system with Vona on the backend and Zova on the frontend                         | Frontend-centric fullstack framework                                   |
+| Backend model            | Dedicated backend framework with its own runtime, contracts, infrastructure, and CLI workflows | Backend capabilities are typically centered around the web app runtime |
+| Frontend and admin model | Shared conventions across SSR, SPA, Web, and Admin applications                                | Strong fit for React-based web application delivery                    |
+| Cross-stack workflow     | Explicit backend OpenAPI output, frontend SDK generation, and frontend metadata feedback loops | Usually chosen per project or ecosystem tooling                        |
+| Best fit                 | Teams that want a coordinated fullstack system with a stronger dedicated backend layer         | Teams that want a React-centered fullstack web application path        |
+
+Cabloy and Next.js both target fullstack application development, but they organize the stack differently.
+
+Cabloy keeps the backend and frontend as **separate but coordinated framework layers**. That makes it a strong fit when a team wants one framework system with a dedicated backend layer and a dedicated frontend layer, without stitching together unrelated tools by hand.
+
+Representative Cabloy strengths in this comparison include:
+
+- a clear backend/frontend collaboration model rather than a single frontend-centered runtime
+- explicit contract workflows from backend OpenAPI output to frontend SDK generation
+- frontend-generated metadata that can flow back into backend-side tooling
+- shared delivery conventions for SSR, SPA, Web, and Admin applications
+
+If your main goal is a React-centered fullstack web app, Next.js may feel more direct. If your main goal is a **coordinated fullstack framework system** with a stronger backend layer and explicit cross-stack workflows, Cabloy is the better fit.
+
+## Cabloy vs NestJS
+
+| Perspective              | Cabloy                                                                                                | NestJS                                                                                  |
+| ------------------------ | ----------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------- |
+| System center            | Fullstack system                                                                                      | Backend framework                                                                       |
+| Backend model            | Vona provides backend runtime, contracts, infrastructure, and CLI workflows                           | NestJS focuses on backend application structure                                         |
+| Frontend and admin model | Frontend collaboration is built into the broader Cabloy system through Zova and shared docs/workflows | Usually paired with a separate frontend choice                                          |
+| Cross-stack workflow     | Backend contracts can feed frontend SDK generation inside the same framework system                   | Typically assembled from separate backend and frontend tooling choices                  |
+| Best fit                 | Teams that want backend strength inside a shared fullstack system                                     | Teams that want a backend-first framework and will choose the frontend stack separately |
+
+The most important difference here is **scope**.
+
+NestJS is primarily a backend framework. Cabloy is a **fullstack framework system**. So this comparison is not only “backend versus backend.” It is also “backend-first framework” versus “backend + frontend framework system with a shared collaboration model.”
+
+Within Cabloy, the backend-specific capabilities come from **Vona**. That is where backend-oriented strengths such as these belong:
+
+- unified validation and OpenAPI-oriented schema workflows
+- DTO inference and generation workflows
+- built-in multi-tenant, multi-database, and multi-datasource capabilities
+- broader infrastructure features such as queues, broadcast, schedule, and redlock
+- AOP-oriented backend programming capabilities
+
+If a team only needs a backend framework and wants to choose the frontend stack separately, NestJS remains a natural option. If a team wants those backend capabilities to live inside a **shared fullstack system** with Zova, SSR-aware delivery modes, and contract-loop workflows, Cabloy is the better fit.
+
+## Cabloy vs Django Admin
+
+| Perspective              | Cabloy                                                                                                                    | Django Admin                                                                             |
+| ------------------------ | ------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------- |
+| System center            | Typed Node.js fullstack framework system                                                                                  | Python server-centered admin framework experience                                        |
+| Backend model            | Dedicated backend runtime and infrastructure through Vona                                                                 | Django backend conventions centered on the admin stack                                   |
+| Frontend and admin model | Modern frontend layer through Zova with SSR, SPA, Web, and Admin delivery modes                                           | Admin experience is centered on server-rendered templates and built-in admin conventions |
+| Cross-stack workflow     | Backend and frontend stay aligned through generated contracts, metadata, and shared workflows                             | The default model is more tightly centered on the server-side admin stack                |
+| Best fit                 | Teams that want rapid admin development in Node.js without giving up typed frontend flexibility and richer UI interaction | Teams that want a fast server-centered admin path in the Python ecosystem                |
+
+This comparison is worth keeping even though the language ecosystems are different.
+
+In the Python ecosystem, **Django Admin** has long been one of the strongest choices for rapidly building CRUD-oriented admin systems. In the Node.js ecosystem, there has historically been no equally established framework that combines rapid admin development, full backend infrastructure, and a modern fullstack architecture in the same way.
+
+Cabloy is designed to fill that gap in the Node.js ecosystem.
+
+That is why this comparison matters: it is not only comparing features, but also explaining Cabloy’s **ecosystem role**. For teams that want Django-Admin-like development speed for admin systems but want to stay in Node.js, Cabloy aims to provide that missing fullstack option.
+
+At the same time, Cabloy does not stop at reproducing the server-centered admin model. With Vona on the backend and Zova on the frontend, Cabloy gives teams:
+
+- a typed modern frontend layer instead of relying only on server-rendered templates
+- richer interaction patterns for Admin and Web applications
+- a smoother path for deeper customization as business systems become more complex
+- a development experience that stays closer to modern Node.js fullstack workflows
+
+So although Django Admin remains a benchmark for rapid admin development, Cabloy aims to offer a stronger long-term fit for teams that want both **rapid CRUD-oriented admin delivery** and a more modern fullstack development and interaction model inside Node.js.
+
+For Cabloy’s frontend/runtime side of this comparison, see:
+
+- [Frontend SSR Overview](/frontend/ssr-overview)
+- [Editions Overview](/editions/overview)
+
+## How to read these comparisons
+
+These comparisons are most useful when your decision depends on questions like:
+
+- do you want one coordinated framework system instead of stitching backend and frontend frameworks together?
+- do you need a stronger dedicated backend layer inside a fullstack architecture?
+- do you want explicit contract-loop workflows between backend and frontend?
+- do you need shared conventions across SSR, SPA, Web, and Admin delivery modes?
+- do you want Django-Admin-like rapid admin development inside the Node.js ecosystem, but with a more modern frontend and interaction model?
+
+If those questions matter, Cabloy’s value is not just one isolated feature. It is the way **Vona**, **Zova**, shared scripts, and cross-stack workflows stay aligned as one framework system.

package/cabloy-docs/fullstack/edition-collaboration-differences.md

@@ -0,0 +1,62 @@
+# Edition Differences in Fullstack Collaboration
+
+This page makes the Basic/Start differences in the collaboration loop explicit.
+
+## Why this page matters
+
+Most Cabloy architecture can be explained once.
+
+But the fullstack collaboration path becomes confusing if docs or AI systems silently reuse Cabloy Basic assumptions inside Cabloy Start workflows.
+
+This page exists to keep those differences visible.
+
+## Shared collaboration model
+
+Both editions share the same broad collaboration loop:
+
+- Vona provides backend runtime and OpenAPI-facing contract output
+- Zova provides frontend application structure and generated metadata
+- root scripts and CLI commands coordinate build, generation, and verification
+
+## Where the editions diverge
+
+The most important differences show up in:
+
+- frontend UI layer assumptions
+- frontend flavor names
+- frontend module composition
+- admin/web SSR site baselines
+- private value-add content and project assets in Cabloy Start
+- potentially different generated output paths or integration details
+
+## Cabloy Basic
+
+In the current public monorepo, Basic examples commonly align with:
+
+- DaisyUI + TailwindCSS oriented frontend assumptions
+- Basic-specific Zova flavors such as `cabloyBasicAdmin` and `cabloyBasicWeb`
+
+## Cabloy Start
+
+In the sibling private repo, Start examples commonly align with:
+
+- Vuetify-oriented frontend assumptions
+- Start-specific Zova flavors such as `cabloyStartAdmin` and `cabloyStartWeb`
+
+## Safe documentation and AI rule
+
+When documenting or automating a fullstack collaboration flow:
+
+1. explain the shared model once
+2. detect the active edition
+3. branch only where the workflow actually diverges
+4. verify flavor names and generated output paths in the active repo
+
+## Practical implications for edition-aware workflow decisions
+
+This rule prevents a common failure mode:
+
+- the model understands the shared architecture correctly
+- but gives the wrong operational example because it assumes the wrong edition
+
+That is exactly the kind of mistake good fullstack docs should prevent.

package/cabloy-docs/fullstack/frontend-metadata-to-backend.md

@@ -0,0 +1,64 @@
+# Frontend Metadata Back to Backend
+
+This page documents the reverse direction of Cabloy’s fullstack collaboration loop: frontend-generated metadata that improves backend-side development and tooling.
+
+## Why this path matters
+
+The fullstack collaboration loop in Cabloy is not one-way.
+
+For the forward contract-bridge direction from backend OpenAPI to frontend consumption, also see [Backend OpenAPI to Frontend SDK](/fullstack/openapi-to-sdk).
+
+The backend does not only feed the frontend through OpenAPI. The frontend also generates information that can improve backend-side type hints and integration confidence.
+
+This is one of the unusual strengths of the Cabloy monorepo model.
+
+## What the frontend can generate
+
+The current script surface shows that Zova can generate metadata and type information for areas such as:
+
+- routes
+- components
+- icons
+- REST-related generated output
+
+That generated information can then be consumed by backend-side fullstack workflows and developer tooling.
+
+## Why this is valuable
+
+In a separated-repo world, this information is often harder to share, easier to stale, and more annoying for AI to rediscover.
+
+In the monorepo, the frontend-generated metadata can stay close to:
+
+- the frontend source that produced it
+- the backend workflows that consume or rely on it
+- the docs and skills that explain the collaboration path
+
+## Typical collaboration pattern
+
+A practical collaboration loop often looks like this:
+
+1. define or update frontend routes/components/icons
+2. regenerate the relevant frontend metadata or REST/type output
+3. let backend-side workflows, docs, or fullstack integration logic consume the generated information
+4. verify the collaboration path still matches the active edition
+
+## Edition awareness
+
+This path is especially sensitive to edition differences because Basic and Start do not expose the same frontend module and UI shape.
+
+So when AI reasons about frontend-generated metadata, it should verify:
+
+- which repo is active
+- which flavor is active
+- which generated output belongs to that edition
+
+## Implementation checks for frontend-metadata changes
+
+When changing frontend structural resources such as routes or components, ask:
+
+1. does metadata need regeneration?
+2. does backend-side tooling or fullstack integration rely on that metadata?
+3. is this a Basic-specific or Start-specific workflow?
+4. should the next action be generation and verification rather than only source edits?
+
+That keeps the reverse contract loop visible instead of accidental.

package/cabloy-docs/fullstack/introduction.md

@@ -0,0 +1,81 @@
+# Fullstack Introduction
+
+Cabloy is a Node.js fullstack framework for AI vibe coding.
+
+Use one fullstack framework instead of stitching together separate backend and frontend stacks.
+
+With Vona, Zova, suite-based modules, and CLI-first workflows, Cabloy turns common scaffolding, metadata, refactors, and verification into explicit commands for faster, more accurate AI vibe coding.
+
+## What Cabloy emphasizes
+
+- **One framework system** — build backend and frontend in one fullstack architecture
+- **Vona + Zova** — use aligned backend and frontend frameworks for code sharing, workflow reuse, and cross-stack consistency
+- **Suite-based modular system** — organize capabilities as suites and modules so services, features, metadata, and tooling evolve in composable units
+- **Multiple delivery modes** — deliver SSR, SPA, Web, and Admin applications with shared conventions across the stack
+- **CLI-first workflows for AI vibe coding** — turn common scaffolding, metadata, refactors, and verification into explicit commands for faster, more accurate AI vibe coding
+- **Monorepo-native development** — keep framework source, docs, and tooling aligned in one monorepo workflow
+
+## Shared architecture
+
+- **Vona** provides the backend framework capabilities.
+- **Zova** provides the frontend framework capabilities.
+- The root repository coordinates the two through shared scripts, shared terminology, and a shared release story.
+
+This combination keeps backend and frontend development close enough for code sharing, workflow reuse, and AI vibe coding workflows.
+
+## How the fullstack system stays connected
+
+At the repository level, shared scripts, shared terminology, and CLI-first workflows keep Vona and Zova aligned as one framework system.
+
+For the shared terminal-first workflow model, see [Fullstack CLI](/fullstack/cli).
+
+## Why the monorepo matters
+
+The monorepo makes it possible to keep backend and frontend concepts, tooling, and generated outputs aligned from source rather than memory, for example:
+
+- how frontend routes and components are reflected back into backend type hints
+- how backend OpenAPI and DTO output feeds frontend SDK generation
+- how common concepts can be documented once before edition-specific notes branch out
+- how Vona and Zova CLI capabilities can be reused instead of rebuilding scaffolding by hand
+
+## Technology Stack
+
+### General
+
+| Package    | Version  |
+| ---------- | -------- |
+| TypeScript | `^5.9.3` |
+| Zod        | `^4.3.6` |
+
+### Backend (Vona)
+
+| Package                          | Version   |
+| -------------------------------- | --------- |
+| Koa                              | `^3.2.0`  |
+| Knex                             | `^3.2.9`  |
+| Redis Client (`ioredis`)         | `^5.10.1` |
+| SQLite Driver (`better-sqlite3`) | `^12.9.0` |
+
+### Frontend (Zova)
+
+| Package        | Version     |
+| -------------- | ----------- |
+| Vue            | `^3.5.32`   |
+| Vite           | `^8.0.14`   |
+| Quasar         | `^2.19.3`   |
+| TanStack Query | `^5.100.10` |
+| TanStack Form  | `^1.32.0`   |
+| TanStack Table | `^8.21.3`   |
+
+### Edition-specific UI Stack
+
+- **Cabloy Basic**: DaisyUI + Tailwind CSS
+- **Cabloy Start**: Vuetify
+
+## Common-first, edition-aware
+
+Most framework concepts are shared across Cabloy Basic and Cabloy Start because both editions follow the same Cabloy fullstack core. The documentation prefers a common-first explanation, then adds edition-specific notes only where the editions intentionally diverge.
+
+Across editions, the frontend engineering layer stays mostly shared through Zova, Vue, Vite, Quasar tooling, and related libraries. The edition-specific UI layer then diverges between DaisyUI + Tailwind CSS for Cabloy Basic and Vuetify for Cabloy Start.
+
+Use the [Editions Overview](/editions/overview) page whenever a task depends on UI library assumptions, flavor names, module composition, SSR site baselines, distribution boundaries, or AI workflow guidance.

package/cabloy-docs/fullstack/openapi-to-sdk.md

@@ -0,0 +1,116 @@
+# Backend OpenAPI to Frontend SDK
+
+This page turns one of Cabloy’s most important fullstack collaboration paths into an explicit guide.
+
+## Why this path matters
+
+Cabloy’s fullstack productivity depends heavily on a contract loop:
+
+1. Vona emits backend API metadata through Swagger/OpenAPI
+2. Zova consumes that metadata to generate frontend SDKs and schema-aware helpers
+3. frontend pages, models, and services build on those generated contracts instead of re-declaring everything manually
+
+This is one of the strongest AI-leverage paths in the repo because it reduces duplicated type work and keeps backend/frontend coordination closer to source truth.
+
+## The contract loop in practical terms
+
+A useful split is:
+
+- backend docs define the authoring side of the contract
+- fullstack docs define the bridge from emitted contract to generated SDK
+- frontend docs define the consumption side of the generated contract
+
+That means this page is the fullstack contract-bridge page, not the backend authoring page and not the frontend usage page.
+
+## Backend side: Vona emits the contract
+
+On the backend side, OpenAPI metadata is driven by:
+
+- controller argument and return contracts
+- DTO and entity field definitions
+- validation rules and `v` helpers
+- `a-openapi` configuration
+
+For the deeper backend perspective, see:
+
+- [Controller Guide](/backend/controller-guide)
+- [OpenAPI Guide](/backend/openapi-guide)
+- [Validation Guide](/backend/validation-guide)
+- [DTO Infer and Generation](/backend/dto-infer-generation)
+
+## Frontend side: Zova consumes the contract
+
+On the frontend side, the generated-contract path typically includes:
+
+- OpenAPI configuration
+- SDK generation
+- API services or schema-driven helpers based on the generated output
+
+For the deeper frontend perspective, see:
+
+- [OpenAPI SDK Guide](/frontend/openapi-sdk-guide)
+- [Server Data](/frontend/server-data)
+- [API Guide](/frontend/api-guide)
+- [API Schema Guide](/frontend/api-schema-guide)
+- [SDK Guide](/frontend/sdk-guide)
+
+## Cabloy Basic workflow
+
+In the current public monorepo, Basic-specific Zova flavors include:
+
+- `cabloyBasicAdmin`
+- `cabloyBasicWeb`
+
+Representative frontend-side contract-generation commands include:
+
+```bash
+npm run zova :openapi:config demo-student
+npm run zova :openapi:generate demo-student
+cd zova && npm run build:rest:cabloyBasicAdmin
+cd zova && npm run build:rest:cabloyBasicWeb
+```
+
+A practical contract-loop sequence is:
+
+1. author or change the backend contract
+2. emit or inspect backend OpenAPI output
+3. configure frontend module ownership if needed
+4. generate module-level OpenAPI SDK output
+5. run the rest build for the active Basic flavor when needed
+6. consume the generated contract from frontend code instead of re-declaring it manually
+
+A practical responsibility split is:
+
+- project-level OpenAPI config decides where the backend Swagger/OpenAPI source comes from
+- module-level OpenAPI config decides which generated contract slice belongs to which frontend module
+
+A practical regeneration rule is:
+
+- if the backend contract changed, prefer regenerating the SDK/rest layer before hand-editing frontend request code
+
+## Cabloy Start workflow
+
+In the sibling private Start repo, the same collaboration idea applies, but the frontend flavor names differ.
+
+Representative Start-specific flavors include:
+
+- `cabloyStartAdmin`
+- `cabloyStartWeb`
+
+Before documenting or automating this path for Start, confirm:
+
+1. the `__CABLOY_START__` marker
+2. the Start repo’s `package.json`
+3. the exact frontend flavor names and generated output paths
+
+## Implementation checks for backend-to-frontend contract changes
+
+When changing a backend API contract, ask:
+
+1. does OpenAPI output change?
+2. does the frontend SDK or schema layer need regeneration?
+3. is the active edition Basic or Start?
+4. is the right next step to regenerate contracts instead of hand-editing frontend request code?
+5. is the current task on the backend authoring side, the bridge step, or the frontend consumption side?
+
+That keeps the backend/frontend contract loop coherent.

package/cabloy-docs/fullstack/quickstart.md

@@ -0,0 +1,89 @@
+# Fullstack Quickstart
+
+This guide explains the fastest way to start a Cabloy fullstack project.
+
+## 1. Prerequisites
+
+Before creating a new Cabloy project, make sure your environment has:
+
+| Name         | Version     |
+| ------------ | ----------- |
+| `pnpm`       | `>=10.19.0` |
+| `Node.js`    | `>=24.4.0`  |
+| `Redis`      | `>=7.2.6`   |
+| `SQLite3`    | `Built-in`  |
+| `MySQL`      | `>=8`       |
+| `PostgreSQL` | `>=16`      |
+
+- `Redis`: powers queue, schedule, startup, broadcast, caching, two-layer cache, and redlock
+- `SQLite3`: if you use `better-sqlite3`, set up `node-gyp` before installing dependencies
+
+## 2. Create a new project
+
+```bash
+npm create cabloy
+```
+
+The generated project already includes `CLAUDE.md` and the `.claude/` workspace assets. This path creates a Cabloy Basic project baseline. Open this project in Claude Code and start coding immediately with project-specific guidance.
+
+## 3. Start the backend
+
+```bash
+npm run dev
+```
+
+- Web: http://localhost:7102/
+- Admin: http://localhost:7102/admin/
+
+## 4. Start the frontend for your edition
+
+### Cabloy Basic
+
+```bash
+npm run dev:zova:admin # http://localhost:9000/admin/
+npm run dev:zova:web   # http://localhost:9000/
+```
+
+### Cabloy Start
+
+Cabloy Start is the private commercial edition. Instead of `npm create cabloy`, purchase access to the licensed private repository, clone that source directly, and run `npm run init`. Then use the frontend commands provided by that edition. Do not assume the Cabloy Basic flavor names apply to Cabloy Start.
+
+For the full Start onboarding details, including the access and initialization flow, read [Cabloy Start](/editions/cabloy-start).
+
+If you are not sure which edition you are using or which one to choose, read:
+
+- [Choosing Between Cabloy Basic and Cabloy Start](/editions/choosing-between-basic-and-start)
+- [Edition Detection](/editions/detection)
+- [Cabloy Basic](/editions/cabloy-basic)
+- [Cabloy Start](/editions/cabloy-start)
+
+## 5. Upgrade an existing project
+
+```bash
+npm run upgrade
+```
+
+## 6. Next steps for framework-aware development
+
+If you are contributing to framework-aware workflows or using Cabloy CLI generation directly, prefer CLI-backed generation over manual scaffolding.
+
+Read [Fullstack CLI](/fullstack/cli) for the shared cross-stack workflow model, then start with:
+
+```bash
+npm run vona :create
+npm run zova :create
+```
+
+Then narrow into the specific command family you need.
+
+## 7. Shared verification commands for deeper workflow checks
+
+If you are validating framework-aware changes or a broader workflow, use the shared project scripts before declaring a workflow correct:
+
+```bash
+npm run tsc
+npm run test
+npm run build
+```
+
+Choose more targeted checks when only one area is affected, but treat these scripts as the shared reference surface.

package/cabloy-docs/fullstack/vona-zova-integration.md

@@ -0,0 +1,86 @@
+# Fullstack Vona + Zova Integration
+
+This guide explains the current monorepo-native workflow for integrating Vona and Zova.
+
+## Why the workflow looks different in the monorepo
+
+Earlier standalone-repo workflows often described integrating Zova by cloning a separate repository and copying its built output into Vona manually.
+
+That is not the preferred Cabloy workflow.
+
+In the current monorepo:
+
+- Vona and Zova already live in the same source tree
+- the root repository already exposes shared scripts for both sides
+- edition differences should be handled explicitly rather than through ad hoc path replacement
+
+## Core integration model
+
+Cabloy uses a frontend-backend separation architecture:
+
+- Vona provides the backend runtime
+- Zova provides the frontend application
+- generated or built frontend output is consumed by the backend-side fullstack flow
+- type sharing is coordinated through OpenAPI, generated SDKs, and frontend-generated route/component typing
+
+## Cabloy Basic
+
+In Cabloy Basic, the root repository already exposes these shared entrypoints:
+
+```bash
+npm run dev
+npm run dev:zova:admin
+npm run dev:zova:web
+npm run build
+npm run build:zova
+```
+
+The relevant Zova flavors in this repository include:
+
+- `cabloyBasicAdmin`
+- `cabloyBasicWeb`
+
+The frontend-side REST/type build flows include:
+
+```bash
+cd zova && npm run build:rest:cabloyBasicAdmin
+cd zova && npm run build:rest:cabloyBasicWeb
+```
+
+## Cabloy Start
+
+Cabloy Start is the private commercial edition. It lives in a licensed sibling repository rather than a subdirectory here, but the same integration idea applies.
+
+Its root script surface uses Start-specific flavors such as:
+
+- `cabloyStartAdmin`
+- `cabloyStartWeb`
+
+Because Start differs in UI layer, module composition, SSR site baselines, and project assets, do not reuse Basic integration examples without first confirming:
+
+1. the `__CABLOY_START__` marker
+2. the Start repo’s `package.json`
+3. the exact Zova flavor names and generated output paths used there
+
+## Recommended integration workflow
+
+### 1. Detect the edition
+
+- `__CABLOY_BASIC__` → use Basic examples from this repo
+- `__CABLOY_START__` → verify the sibling Start repo scripts before using examples
+
+### 2. Start from root scripts
+
+Use the root `package.json` as the first workflow surface.
+
+### 3. Use Zova build and REST generation deliberately
+
+For frontend builds and type generation, inspect the relevant Zova flavor scripts instead of hardcoding copy paths or ad hoc integration steps.
+
+### 4. Verify both sides together
+
+For meaningful fullstack changes, verify:
+
+- backend dev/build/test flow
+- frontend dev/build/type generation flow
+- the edition-specific flavor you actually targeted