cabloy 5.1.51 → 5.1.53

package/cabloy-docs/ai/docs-skills-rules-mapping.md

@@ -115,6 +115,7 @@ Use this quick rule:
 ### Example: “Always detect Basic vs Start before giving UI-sensitive advice”
 
 - public explanation → [AI Edition Detection](/ai/edition-detection)
+- consistency review surface → [Edition Consistency Checklist](/ai/edition-consistency-checklist)
 - repo-wide behavior rule → `CLAUDE.md`
 - procedural enforcement → `cabloy-workflow` skill
 

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

@@ -0,0 +1,150 @@
+# Edition Consistency Checklist
+
+This checklist helps maintainers keep docs, rules, commands, and skills aligned when writing or reviewing Cabloy Basic and Cabloy Start guidance.
+
+Use it whenever you add or revise:
+
+- edition-aware docs
+- `CLAUDE.md` guidance
+- `.claude/commands/`
+- `.claude/skills/`
+- AI workflow playbooks
+
+## The baseline story that should stay consistent
+
+Before checking details, confirm that the content still tells the same baseline story:
+
+- **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
+- 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
+
+If a page, rule, or skill contradicts one of those points, align that content before polishing wording.
+
+## Checklist 1: edition detection is explicit
+
+Confirm that the content:
+
+- tells the reader or agent to check `__CABLOY_BASIC__` or `__CABLOY_START__`
+- treats edition detection as mandatory before UI-sensitive guidance
+- does not assume Cabloy Basic examples apply to Cabloy Start automatically
+- does not assume the project creation path is the same for both editions
+
+## Checklist 2: creation path assumptions are correct
+
+Confirm that the content states or implies the right project-entry model:
+
+- **Cabloy Basic** → `npm create cabloy`
+- **Cabloy Start** → licensed private repository clone
+
+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
+
+## Checklist 3: shared core vs edition divergence is separated cleanly
+
+Confirm that the content distinguishes:
+
+### Shared core
+
+- Vona
+- Zova
+- suite-based architecture
+- CLI-first workflows
+- shared frontend engineering direction
+
+### Edition divergence
+
+- UI layer
+- frontend flavors
+- suites/modules
+- SSR site baselines
+- project assets
+- edition-specific generated outputs or script paths where applicable
+
+Avoid collapsing the whole difference into “different UI library only.”
+
+## Checklist 4: UI language uses the right layer
+
+When the content talks about frontend differences, confirm that it uses the right level:
+
+- shared frontend engineering layer
+- edition-specific UI layer
+
+Prefer wording such as:
+
+- **Cabloy Basic**: DaisyUI + Tailwind CSS UI layer
+- **Cabloy Start**: Vuetify UI layer
+
+Avoid wording that makes Quasar sound like the edition UI component library when the intended meaning is tooling.
+
+## Checklist 5: operational examples match the active edition
+
+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 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
+
+## Checklist 6: docs, rules, and skills play different roles
+
+Confirm that the same guidance is distributed correctly:
+
+- **docs** explain the workflow in durable prose
+- **`CLAUDE.md`** captures short repo-wide behavioral rules
+- **skills** encode procedural branching and follow-up logic
+- **commands** are used only for named operator workflows, not as the only home for conceptual guidance
+
+Avoid these drifts:
+
+- a skill contains the only explanation of an edition rule
+- `CLAUDE.md` grows into a long architectural essay
+- docs duplicate every procedural branch that belongs in a skill
+
+## Checklist 7: verification guidance matches the edition model
+
+When content ends with verification steps, confirm that it reminds the reader or agent to verify the right edition-specific surfaces when relevant:
+
+- flavor names
+- script paths
+- suites/modules
+- SSR site baselines
+- 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.
+
+## Checklist 8: wording about system size stays appropriately scoped
+
+If the content talks about project fit, confirm that it keeps the intended nuance:
+
+- **Cabloy Basic** is optimized for public reference, learning, community workflows, and faster small-to-medium system development
+- **Cabloy Start** is optimized as a stronger baseline for more complex business systems
+
+Avoid overstating this into a hard claim that Basic cannot support larger systems.
+
+## Quick review questions
+
+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?
+5. Do docs, rules, and skills each play their proper role?
+
+## Read together with
+
+- [Choosing Between Cabloy Basic and Cabloy Start](/editions/choosing-between-basic-and-start)
+- [Editions Overview](/editions/overview)
+- [Edition Detection for AI Workflows](/ai/edition-detection)
+- [Docs, Skills, Rules, and CLI Mapping](/ai/docs-skills-rules-mapping)
+- [Rules and Config](/ai/rules-and-config)
+- [Verification](/ai/verification)

package/cabloy-docs/ai/edition-detection.md

@@ -8,10 +8,10 @@ Edition detection should happen before any AI workflow that assumes a frontend s
 
 If an agent skips edition detection, it can:
 
-- scaffold against the wrong UI assumptions
+- scaffold against the wrong UI-layer assumptions
 - suggest the wrong frontend flavors
-- cite modules that do not exist in the active repo
-- generate docs or skills that accidentally hardcode Basic-only behavior into Start workflows
+- cite suites, modules, SSR site baselines, or project assets that do not exist in the active repo
+- generate docs or skills that accidentally hardcode Basic-only behavior or `npm create cabloy` assumptions into Start workflows
 
 ## Operational rule
 

package/cabloy-docs/ai/global-bean-lookup.md

@@ -152,6 +152,7 @@ Avoid these mistakes:
 Read these pages together:
 
 - [Class Placement Rule](/ai/class-placement-rule)
+- [Virtual Decorator Guidance](/ai/virtual-decorator-guidance)
 - [Repo Guidance](/ai/repo-guidance)
 - [Rules and Config](/ai/rules-and-config)
 - [Verification](/ai/verification)

package/cabloy-docs/ai/introduction.md

@@ -1,8 +1,8 @@
 # AI Development Introduction
 
-This page is the entrypoint for contributors who are designing, reviewing, or maintaining AI-assisted workflows in the Cabloy repository.
+This page is the entrypoint for contributors who are designing, reviewing, or maintaining AI vibe coding workflows in the Cabloy repository.
 
-The Cabloy monorepo is a good fit for AI-assisted development because the source tree already contains most of the framework knowledge an agent needs:
+The Cabloy monorepo is a good fit for AI vibe coding because the source tree already contains most of the framework knowledge an agent needs:
 
 - root scripts for shared workflows
 - Vona CLI source and command groups
@@ -23,13 +23,22 @@ The goal is to make AI **reuse the repo’s existing conventions directly**, esp
 - internal architecture notes
 - shared public documentation
 
+## How to approach AI work
+
+For contributor and automation workflows in this repository, prefer this order:
+
+1. inspect the active edition and repo markers before making UI-sensitive or workflow-sensitive assumptions
+2. inspect root scripts, Vona CLI, and Zova CLI before inventing manual scaffolding or custom workflow steps
+3. use public docs for durable user-facing guidance and `.docs-internal/` for maintainer rationale
+4. encode repeatable behavior in Claude rules, commands, or skills instead of relying on unstated habits
+
 ## The knowledge layers
 
 ### Public docs
 
 Use `cabloy-docs/` for user-facing and agent-facing guidance that should remain durable and source-aligned.
 
-For normal project usage, prefer the user-facing entry docs such as [Fullstack Quickstart](/fullstack/quickstart). This AI section focuses on repository workflows and AI-assisted development.
+For normal project usage, prefer the user-facing entry docs such as [Fullstack Quickstart](/fullstack/quickstart). This AI section focuses on repository workflows and AI vibe coding.
 
 ### Internal engineering docs
 
@@ -43,6 +52,41 @@ Use root `CLAUDE.md` and `.claude/commands/` for concise operational behavior an
 
 Use `.claude/skills/` for procedural workflows that benefit from reusable instructions, bundled references, or future deterministic scripts.
 
+## AI reading paths
+
+Use this page as the main AI-development hub, then choose the path that matches your task.
+
+### Repo workflow path
+
+Start here when the task is about choosing the right repo surface, docs location, or automation boundary:
+
+- [Repo Guidance](/ai/repo-guidance)
+- [Docs / Skills Mapping](/ai/docs-skills-rules-mapping)
+- [CLI to Skill Map](/ai/cli-to-skill-map)
+- [Skills](/ai/skills)
+- [Rules and Config](/ai/rules-and-config)
+
+### Framework implementation path
+
+Use this path when the task is about implementing or reviewing Cabloy code with repo-aware rules:
+
+- [Class Placement Rule](/ai/class-placement-rule)
+- [Global Bean Lookup](/ai/global-bean-lookup)
+- [Playbook: Backend Module](/ai/playbook-backend-module)
+- [Playbook: Frontend Page](/ai/playbook-frontend-page)
+- [Playbook: Contract Regeneration](/ai/playbook-contract-regeneration)
+- [Playbook: Metadata Refresh](/ai/playbook-metadata-refresh)
+
+### Verification and roadmap path
+
+Use this path when the task is about consistency checks, verification, or future workflow planning:
+
+- [Edition Detection](/ai/edition-detection)
+- [Edition Consistency Checklist](/ai/edition-consistency-checklist)
+- [Verification](/ai/verification)
+- [Future Skill Roadmap](/ai/future-skill-roadmap)
+- [CLI for Agents](/ai/cli-for-agents)
+
 ## Recommended AI lookup rules
 
 For backend shorthand lookup, prefer these surfaces in order:

package/cabloy-docs/ai/repo-guidance.md

@@ -38,9 +38,9 @@ Edition detection is especially important when the work touches:
 
 - page creation
 - component generation
-- UI library usage
+- UI-layer usage
 - frontend flavor scripts
-- edition-specific modules or assets
+- edition-specific suites, modules, SSR site baselines, or project assets
 
 ## 5. Use the right lookup surface before searching broadly
 

package/cabloy-docs/ai/rules-and-config.md

@@ -10,7 +10,7 @@ Use the root `CLAUDE.md` for concise, durable operational guidance such as:
 - where public docs live
 - where internal docs live
 - which command entrypoints are preferred
-- why edition detection is mandatory before UI-sensitive guidance
+- why edition detection is mandatory before UI-sensitive guidance or project-creation assumptions
 
 ## `.claude/commands/`
 

package/cabloy-docs/ai/skills.md

@@ -33,3 +33,5 @@ A strong Cabloy skill usually includes:
 5. references to durable source-of-truth files
 
 When a skill needs to apply an architectural rule such as backend class placement, prefer a branching decision tree that points back to durable docs instead of embedding the full architecture rationale inside the skill itself.
+
+For edition-aware skills, use [Edition Detection for AI Workflows](/ai/edition-detection) and [Edition Consistency Checklist](/ai/edition-consistency-checklist) as the durable review surfaces before expanding edition-specific branches.

package/cabloy-docs/ai/verification.md

@@ -18,6 +18,7 @@ For skills and repo guidance:
 - confirm the workflow still points to real command entrypoints
 - confirm edition branches match the active repo markers and scripts
 - confirm public docs, skills, and root `CLAUDE.md` tell the same story
+- review edition-aware changes against [Edition Consistency Checklist](/ai/edition-consistency-checklist)
 
 ## Code-generation verification
 

package/cabloy-docs/ai/virtual-decorator-guidance.md

@@ -0,0 +1,206 @@
+# Virtual Decorator Guidance
+
+Use this page when deciding whether a backend class should use `@Virtual()`, or when AI needs to understand what `@Virtual()` changes in Vona bean behavior.
+
+The goal is to preserve real runtime semantics, keep class placement intentional, and prevent `@Virtual()` from being reused as a shorthand or registration filter.
+
+## Short definition
+
+`@Virtual()` marks a container-managed class as a virtual inherited runtime node.
+
+Its core effect is to make bean registration inherit `moduleBelong` from the parent bean chain instead of treating the current class as a new independent runtime ownership center.
+
+## What `@Virtual()` does not mean
+
+`@Virtual()` does **not** mean any of the following:
+
+- suppress bean registration
+- remove a bean-scene class from `IBeanRecordGlobal`
+- act as a shorthand-registration filter
+- compensate for incorrect class placement
+- mean only that a class is abstract or internal
+
+If a class should not appear on the global shorthand surface, fix placement instead.
+
+For related guidance, also read:
+
+- [Class Placement Rule](/ai/class-placement-rule)
+- [Global Bean Lookup](/ai/global-bean-lookup)
+
+## Runtime effect
+
+`@Virtual()` matters at registration time and then keeps affecting runtime scope resolution.
+
+### 1. Decorator stage
+
+The decorator writes virtual metadata on the class.
+
+Conceptually:
+
+```text
+@Virtual()
+ -> metadata(SymbolDecoratorVirtual = true)
+```
+
+### 2. Registration stage
+
+When the bean is registered, Vona reads that metadata and computes `moduleBelong`.
+
+- non-virtual bean -> `moduleBelong` stays equal to the current module
+- virtual bean -> `moduleBelong` is inherited from the nearest parent bean that already has one
+
+Conceptually:
+
+```text
+@Virtual()
+ -> addBean()
+ -> _parseModuleBelong()
+ -> inherited moduleBelong
+```
+
+### 3. Runtime stage
+
+Bean instances then resolve runtime scope resources from that inherited `moduleBelong`.
+
+This directly affects access to:
+
+- `this.scope`
+- `this.module`
+- `this.config`
+- `this.constant`
+- `this.error`
+- `this.locale`
+- `this.util`
+- `this.model`
+- `this.entity`
+- module meta and scene resources
+
+Short version:
+
+> `@Virtual()` changes runtime ownership resolution, not registration existence.
+
+## Relationship to `@Bean()` and `@Service()`
+
+These decorators solve different problems.
+
+- `@Bean()` / `@Service()` / `@Controller()` decide which scene the class registers into
+- `@Virtual()` decides how runtime ownership is resolved
+
+They are orthogonal.
+
+Examples:
+
+- `@Service() + @Virtual()`
+  - service-scene bean
+  - runtime ownership follows the parent bean chain
+- `@Bean() + @Virtual()`
+  - bean-scene bean
+  - still a virtual bridge node rather than a new independent ownership center
+
+## When to use `@Virtual()`
+
+Use `@Virtual()` when a class is still container-managed, but is not intended to become a new independent runtime ownership center.
+
+Typical cases:
+
+### 1. Runtime-anchor bases
+
+These classes still need bean lifecycle, class-token lookup, selector-aware behavior, or framework-managed context.
+
+Representative examples:
+
+- `vona/src/suite-vendor/a-vona/modules/a-orm/src/service/databaseDialectBase_.ts`
+- `vona/src/suite-vendor/a-vona/modules/a-cache/src/service/cacheMemBase_.ts`
+- `vona/src/suite-vendor/a-vona/modules/a-cache/src/service/cacheRedisBase_.ts`
+- `vona/src/suite-vendor/a-vona/modules/a-summer/src/service/summerCacheBase_.ts`
+
+### 2. Bean facade or bridge nodes
+
+These classes remain intentionally visible on the bean-scene shorthand surface, but still behave as inherited bridge nodes rather than independent runtime ownership centers.
+
+Representative example:
+
+- `vona/src/suite-vendor/a-vona/modules/a-orm/src/bean/bean.model.ts`
+
+### 3. Compatibility or variant nodes
+
+These classes extend an existing bean hierarchy and should keep runtime ownership aligned with the parent chain.
+
+Representative example:
+
+- `vona/src/suite-vendor/a-vona/modules/a-ormdialect/src/bean/databaseDialect.mysql3.ts`
+
+## When not to use `@Virtual()`
+
+Do **not** use `@Virtual()` for these cases.
+
+### 1. Independent business services
+
+If a class is the real business owner of its own runtime boundary, it should usually keep its own `moduleBelong` and should not be virtual.
+
+### 2. Misplaced bean-scene classes
+
+Do not keep a class in `src/bean` and try to hide it with `@Virtual()`.
+
+If it should not be a global shorthand bean, move it instead:
+
+- pure helper or subclass-only base -> `src/lib`
+- runtime-anchor base -> `src/service`, often `src/service/*_.ts`
+
+### 3. Pure helpers or superclass convenience classes
+
+If a class does not need container-managed behavior, it usually belongs in `src/lib` and should not use `@Virtual()`.
+
+## Decision table
+
+| Scenario | Use `@Virtual()` | Recommended placement | Reason |
+| --- | --- | --- | --- |
+| independent business service | No | `src/service` | it should own its own runtime resource boundary |
+| runtime-anchor base with container behavior | Yes | `src/service` or `src/service/*_.ts` | it is container-managed but belongs logically to the parent bean system |
+| bean-scene facade that intentionally stays on shorthand surface | Yes, if it is a bridge node | `src/bean` | it participates in shorthand lookup but is not a new ownership center |
+| compatibility / dialect / variant node built on a parent bean | Yes | same scene as the concrete variant type | runtime ownership should inherit from the parent chain |
+| pure helper or superclass convenience class | No | `src/lib` | no bean ownership semantics are needed |
+| class kept in `src/bean` only to expose shortcut lookup | Usually no | re-evaluate placement | `@Virtual()` is not a shorthand filter |
+| misplaced bean-scene class that should not be globally visible | No | move to `src/lib` or `src/service` | fix placement, not metadata |
+
+## Worked examples
+
+### Example: runtime-anchor dialect base
+
+`databaseDialectBase_.ts` is virtual because it remains container-managed and is used as the runtime base for dialect resolution, but it is not meant to become a separate public shorthand ownership center.
+
+### Example: bean-scene bridge node
+
+`bean.model.ts` is still in bean-scene because it intentionally participates in the global shorthand surface, but `@Virtual()` preserves its bridge-node semantics.
+
+### Example: derived dialect variant
+
+`databaseDialect.mysql3.ts` combines `$Class.extend(...)` and `@Virtual()` because those two features solve different problems:
+
+- `$Class.extend(...)` expresses a framework-managed derived-class relationship
+- `@Virtual()` preserves inherited runtime ownership semantics
+
+## Quick checklist
+
+Ask these questions in order:
+
+1. Does the class still need container-managed behavior?
+   - if no, do not use `@Virtual()`
+2. Is it a runtime extension of a parent bean system rather than a new business ownership center?
+   - if yes, `@Virtual()` may be appropriate
+3. Are you using `@Virtual()` only to hide the class from shorthand or metadata surfaces?
+   - if yes, do not use it; fix placement instead
+4. Will inherited `moduleBelong` produce the correct `scope` / `config` / `model` / `entity` behavior at runtime?
+   - if no, do not use `@Virtual()`
+
+## Related guidance
+
+Read these pages together:
+
+- [Class Placement Rule](/ai/class-placement-rule)
+- [Global Bean Lookup](/ai/global-bean-lookup)
+- [Docs, Skills, Rules, and CLI Mapping](/ai/docs-skills-rules-mapping)
+
+For maintainer-level rationale, also read:
+
+- `.docs-internal/architecture/virtual-decorator-runtime-semantics.md`

package/cabloy-docs/backend/introduction.md

@@ -1,8 +1,8 @@
 # Backend (Vona)
 
-This page is the backend hub for contributors who are documenting, designing, or extending backend work in the Cabloy repository.
+This page is the backend hub for Cabloy users, contributors, and AI vibe coding workflows that need the backend side of the framework.
 
-Vona is the backend half of the Cabloy fullstack architecture.
+Vona is the backend half of Cabloy’s one-framework-system fullstack architecture.
 
 ## What Vona is responsible for
 

package/cabloy-docs/backend/logger-guide.md

@@ -24,7 +24,7 @@ By default, the log directory changes by runtime environment.
 Representative defaults are:
 
 - test/development → `{project path}/.app/logs`
-- production → `{home}/vona/{project name}/logs`
+- production → `{home}/.vona/{project name}/logs`
 
 This can be configured through app config or environment variables such as `LOGGER_DIR`.
 

package/cabloy-docs/backend/quickstart.md

@@ -86,10 +86,10 @@ 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**: public reference repo with DaisyUI + TailwindCSS oriented frontend modules
-- **Cabloy Start**: sibling private repo with Vuetify-oriented frontend modules and different value-add composition
+- **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
 
-In the current monorepo docs, do not treat these as just template names. Treat them as edition boundaries that affect frontend integration, scripts, and examples.
+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.
 
 ## Backend configuration reminder
 

package/cabloy-docs/editions/cabloy-basic.md

@@ -1,6 +1,6 @@
 # Cabloy Basic
 
-Cabloy Basic is the public monorepo you are reading right now.
+Cabloy Basic is the public framework/reference edition you are reading right now.
 
 ## Repository marker
 
@@ -12,14 +12,15 @@ This marker is the quickest safe signal for docs, skills, and rules that need to
 
 ## Typical role
 
-Use Cabloy Basic as the public reference for:
+Use Cabloy Basic as the public reference edition for:
 
 - shared architecture explanations
 - root scripts and monorepo entrypoints
 - Vona and Zova source browsing
 - public CLI-backed workflows
 - public user-facing documentation
+- projects created with `npm create cabloy`
 
 ## Frontend bias
 
-In the current source and docs, Cabloy Basic examples commonly align with a DaisyUI + TailwindCSS-oriented frontend story. That does not mean Zova is limited to that UI stack, but it does mean docs and AI outputs should not accidentally project Vuetify-specific assumptions into Cabloy Basic unless the current source explicitly requires it.
+In the current source and docs, Cabloy Basic examples commonly align with a shared frontend engineering layer built on Zova, Vue, Vite, and Quasar tooling, plus a Basic-specific UI layer built with DaisyUI + Tailwind CSS. That does not mean Zova is limited to that UI stack, but it does mean docs and AI outputs should not accidentally project Vuetify-specific assumptions into Cabloy Basic unless the current source explicitly requires it.

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

@@ -1,6 +1,6 @@
 # Cabloy Start
 
-Cabloy Start is a sibling private repository that shares the Cabloy fullstack direction while intentionally differing from Cabloy Basic.
+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.
 
 ## Repository marker
 
@@ -14,10 +14,41 @@ 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
 - Vuetify-specific frontend workflows
 - Cabloy Start flavor names in frontend scripts
-- modules that exist in the private Start repository but not in Basic
-- private value-add project composition
+- edition-specific module composition in the licensed Start repository
+- licensed private-repo structure and edition-specific project composition
+- edition-specific SSR site baselines and project assets
+
+## Get access and initialize
+
+Cabloy Start is the private commercial edition. 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
+
+Access surfaces:
+
+- Purchase page: `https://cabloy.com/module/cabloy-start`
+- Repository: `https://github.com/cabloy/cabloy-start`
+
+Clone the repository:
+
+```bash
+git clone git@github.com:cabloy/cabloy-start.git
+```
+
+After cloning, run:
+
+```bash
+npm run init
+```
+
+This initializes the project and installs dependencies.
 
 ## Relationship to this docs site