cabloy 5.1.59 → 5.1.61

package/cabloy-docs/fullstack/tutorial-4-custom-level-renderers.md

@@ -0,0 +1,144 @@
+# Tutorial 4: Custom Form/Table Renderers for Level
+
+<Badge type="info" text="Basic" />
+
+In this tutorial, one prompt lets AI upgrade the `level` field from built-in render resources to custom frontend renderers owned by the `demo-student` module.
+
+This is the **reverse chain** custom-resource handoff branch of the contract loop.
+
+## Goal
+
+By the end of this tutorial, you will understand:
+
+- when built-in render metadata is enough and when a custom renderer is worth adding
+- how a frontend table cell bean and a frontend form-field component can both serve the same backend field
+- how backend metadata points to module-owned frontend render resources
+
+## AI Prompt
+
+Give AI a prompt like this:
+
+```text
+Please make the level UI more business-specific in the Student list page and form.
+```
+
+## Why this step matters
+
+This is the right follow-up step because built-in render resources are a good starting point, but some business fields eventually need module-specific behavior.
+
+The `level` field is a good teaching example because this step deepens the UI in two concrete ways:
+
+- a custom table cell that renders a more business-specific badge style
+- a custom form field that adds helper text, readonly behavior, or module-specific select styling
+
+This is where Cabloy’s contract model becomes more practical: the backend field still owns the business contract, while the frontend module progressively deepens the UI behavior behind that contract.
+
+## CLI commands to inspect/use
+
+Inspect the Zova create surface first:
+
+```bash
+npm run zova :create
+npm run zova :create:bean --help
+npm run zova :create:component --help
+```
+
+Representative generation commands for this tutorial:
+
+```bash
+npm run zova :create:bean tableCell level -- --module=demo-student
+npm run zova :create:component formFieldLevel -- --module=demo-student
+```
+
+Usage notes:
+
+- use `:create:bean` when you need a table-cell render resource under the bean scene
+- use `:create:component` when you need a custom frontend component/controller surface
+- generation gives you the structural starting point, but this tutorial still expects manual refinement so the result matches the `demo-student` teaching implementation
+- after frontend resources exist, return to the backend entity and point `ZovaRender.field(...)` and `ZovaRender.cell(...)` at the custom module resources
+- once backend metadata starts consuming those new frontend resources, treat the next step as a reverse fullstack handoff rather than frontend-only cleanup: refresh generated output, rebuild the relevant flavor, and re-sync Vona dependencies
+
+## Generated or affected files
+
+By the end of this tutorial, your module should provide these teaching anchors:
+
+- custom table cell bean:
+  - `zova/src/module/demo-student/src/bean/tableCell.level.tsx`
+- custom form-field controller:
+  - `zova/src/module/demo-student/src/component/formFieldLevel/controller.tsx`
+- form-field metadata wrapper:
+  - `zova/src/module/demo-student/src/.metadata/component/formFieldLevel.ts`
+- backend field contract to update:
+  - `vona/src/module/demo-student/src/entity/student.tsx`
+
+Representative custom metadata targets are:
+
+```typescript
+ZovaRender.field('demo-student:formFieldLevel', {
+  items: levelItems,
+  helper: $locale('LevelPlaceholder'),
+})
+```
+
+and:
+
+```typescript
+ZovaRender.cell('demo-student:level', { items: levelItems })
+```
+
+## What those files mean in the business thread
+
+This tutorial makes the split of responsibilities explicit:
+
+- `tableCell.level.tsx` owns the custom table-cell rendering behavior for `level`
+- `component/formFieldLevel/controller.tsx` owns the custom form-field behavior for `level`
+- `.metadata/component/formFieldLevel.ts` exposes that component through the module registration surface
+- `entity/student.tsx` remains the backend-owned business contract that chooses which frontend resources should render the field
+
+That means the backend still defines the business field, validation, and metadata entry point, while the frontend module owns the implementation details of the richer UI behavior.
+
+## Verification
+
+1. refresh the generated handoff surfaces before checking backend consumers:
+
+```bash
+npm run zova :tools:metadata demo-student
+npm run build:zova:admin
+npm run deps:vona
+```
+
+If the same renderer path must also be available for Web, also run:
+
+```bash
+npm run build:zova:web
+npm run deps:vona
+```
+
+If backend-side type consumers still cannot see the new shared renderer types even though generated `.zova-rest` output is already correct, rebuild `vona/node_modules` and reinstall dependencies:
+
+```bash
+cd vona && rm -rf node_modules && pnpm install
+```
+
+2. make sure the local dev workflow is running:
+
+```bash
+npm run dev
+```
+
+3. open `http://localhost:7102/admin/`
+4. enter the **Student** list page and verify that the `level` column now uses the custom table-cell presentation
+5. open a Student create, update, or view form and verify that the `level` field now uses the custom form-field behavior
+6. inspect `vona/src/module/demo-student/src/entity/student.tsx` and confirm that the backend metadata now points to `demo-student:formFieldLevel` and `demo-student:level`
+
+## Read more
+
+- [Frontend Metadata Back to Backend](/fullstack/frontend-metadata-to-backend)
+- [Frontend CLI](/frontend/cli)
+- [Component Guide](/frontend/component-guide)
+- [Zova Form Under the Hood](/frontend/zova-form-under-the-hood)
+- [Bean Scene Boilerplate Variants](/reference/bean-scene-boilerplates)
+
+## Next step
+
+Continue to [Tutorial 5: Backend Contract Sharing](/fullstack/tutorial-5-backend-contract-sharing).

package/cabloy-docs/fullstack/tutorial-5-backend-contract-sharing.md

@@ -0,0 +1,146 @@
+# Tutorial 5: Backend Contract Sharing
+
+<Badge type="info" text="Basic" />
+
+In this tutorial, one prompt lets AI show the **forward chain** of Cabloy’s fullstack contract loop: backend API contracts that generate and refresh the frontend consumption surface.
+
+The teaching thread in this page is the pair of Student actions:
+
+- `summary/:id`
+- `deleteForce/:id`
+
+## Goal
+
+By the end of this tutorial, you will understand:
+
+- how a backend controller and DTO change becomes frontend generated API output
+- how backend row-action metadata can drive frontend table actions
+- how generated API, thin frontend model helpers, and row-action beans fit into one forward-chain workflow
+- why custom resource endpoints that still belong to the same resource should reuse the existing resource-owner instead of creating a competing cache owner
+
+## AI Prompt
+
+Give AI a prompt like this:
+
+```text
+Please add two custom actions to the Student list:
+
+- Summary: return or display a student summary for the selected row
+- Force Delete: permanently delete the selected student through a dedicated row action
+```
+
+## Why this step matters
+
+This is the right step because it reduces duplicated type work across backend and frontend.
+
+Instead of manually synchronizing request and response shapes in two places, this workflow keeps the backend as the source of truth and regenerates the frontend artifacts from that contract.
+
+This step also shows that contract sharing is not only about API methods. It also affects how backend row-action metadata becomes frontend table behavior.
+
+## CLI commands to inspect/use
+
+Inspect the relevant command surfaces first:
+
+```bash
+npm run zova :openapi
+npm run zova :openapi:config demo-student
+npm run zova :openapi:generate demo-student
+```
+
+If your workflow also needs refreshed rest-contract output for Cabloy Basic, the related build commands are:
+
+```bash
+cd zova && npm run build:rest:cabloyBasicAdmin
+cd zova && npm run build:rest:cabloyBasicWeb
+```
+
+Usage notes:
+
+- use the backend controller and DTOs as the starting point
+- inspect the module OpenAPI config before generation
+- prefer regeneration over hand-written duplicate API layers when the module already owns an OpenAPI contract surface
+- keep frontend follow-up thin: treat the module model as a semantic facade over generated API consumers rather than a second contract-definition layer
+- if the custom endpoint still belongs to the existing resource, reuse the existing resource-owner for server-state ownership
+
+## Generated or affected files
+
+The backend contract anchors are:
+
+- `vona/src/module/demo-student/src/controller/student.ts`
+- `vona/src/module/demo-student/src/dto/studentSummary.tsx`
+- `vona/src/module/demo-student/src/dto/studentSelectResItem.tsx`
+
+By the end of this tutorial, your `demo-student` controller should expose:
+
+```typescript
+@Web.get('summary/:id')
+async summary(...) { ... }
+
+@Web.delete('deleteForce/:id')
+async deleteForce(...) { ... }
+```
+
+The frontend contract and consumption anchors are:
+
+- OpenAPI config:
+  - `zova/src/module/demo-student/cli/openapi.config.ts`
+- generated frontend API:
+  - `zova/src/module/demo-student/src/api/demoStudent.ts`
+- frontend model wrapper:
+  - `zova/src/module/demo-student/src/model/student.ts`
+- custom row-action cells:
+  - `zova/src/module/demo-student/src/bean/tableCell.actionSummary.tsx`
+  - `zova/src/module/demo-student/src/bean/tableCell.actionDeleteForce.tsx`
+
+After regeneration, `src/api/demoStudent.ts` should contain generated methods such as:
+
+- `summary(...)`
+- `deleteForce(...)`
+
+## What those files mean in the business thread
+
+This tutorial is easiest to understand as one contract chain:
+
+1. `controller/student.ts` defines the backend action endpoints
+2. `dto/studentSummary.tsx` defines the response contract for the summary action
+3. `dto/studentSelectResItem.tsx` defines the row-action metadata that exposes those actions in the Student list page
+4. `cli/openapi.config.ts` tells the frontend module which backend operations it owns
+5. `src/api/demoStudent.ts` is the generated typed API surface created from that backend contract
+6. `src/model/student.ts` wraps the generated API in a thin frontend semantic facade
+7. the model should reuse the existing resource-owner for server-state ownership when the new API still belongs to the Student resource
+8. `tableCell.actionSummary.tsx` and `tableCell.actionDeleteForce.tsx` turn those model methods into visible row actions
+
+That is the practical forward chain: backend controller and DTO truth flows into generated frontend API output, then into thin frontend model helpers, and finally into visible table actions.
+
+## Verification
+
+1. make sure the local dev workflow is running:
+
+```bash
+npm run dev
+```
+
+2. open `http://localhost:7102/admin/`
+3. enter the **Student** list page
+4. trigger the **Summary** row action and verify that it uses the regenerated frontend API and returns the expected Student summary data
+5. trigger the **Force Delete** row action and verify that it reaches the custom backend deleteForce contract path
+6. inspect the source chain and confirm that each layer is present:
+   - `controller/student.ts`
+   - `dto/studentSummary.tsx`
+   - `dto/studentSelectResItem.tsx`
+   - `src/api/demoStudent.ts`
+   - `src/model/student.ts`
+   - `tableCell.actionSummary.tsx`
+   - `tableCell.actionDeleteForce.tsx`
+
+## Read more
+
+- [Backend OpenAPI to Frontend SDK](/fullstack/openapi-to-sdk)
+- [OpenAPI Guide](/backend/openapi-guide)
+- [OpenAPI SDK Guide](/frontend/openapi-sdk-guide)
+- [SDK Guide](/frontend/sdk-guide)
+- [Server Data](/frontend/server-data)
+
+## Next step
+
+Continue to [Tutorial 6: One Contract Surface, Four Uses](/fullstack/tutorial-6-one-contract-four-uses).

package/cabloy-docs/fullstack/tutorial-6-one-contract-four-uses.md

@@ -0,0 +1,170 @@
+# Tutorial 6: One Contract Surface, Four Uses
+
+<Badge type="info" text="Basic" />
+
+In this tutorial, one prompt lets AI close the series by showing Cabloy’s core fullstack idea: one field-oriented contract surface can drive several behaviors across backend and frontend.
+
+This capstone sits on top of both the forward chain and the reverse chain rather than replacing either one.
+
+This time the main teaching field is `mobile`, while `level` stays as the supporting example for table and form rendering.
+
+## Goal
+
+By the end of this tutorial, you will understand how one business field thread can participate in:
+
+1. validation
+2. OpenAPI generation
+3. table and form rendering
+4. serialization or desensitization
+
+## AI Prompt
+
+Give AI a prompt like this:
+
+```text
+Please add a mobile field to the Student resource. It should be required, be at least 11 characters long, and show the middle 4 digits as asterisks in returned data.
+```
+
+## Why this step matters
+
+This is the right capstone step because many frameworks force the same field knowledge to be repeated in many places:
+
+- validation rules
+- backend DTOs
+- API documentation
+- frontend forms
+- frontend tables
+- response masking logic
+
+Cabloy tries to reduce that duplication through a field-oriented contract and metadata model, and this tutorial lets you inspect that reduction through one concrete field story.
+
+## CLI commands to inspect/use
+
+This tutorial is mainly a source-inspection and verification capstone.
+
+Useful commands include:
+
+```bash
+npm run zova :openapi:generate demo-student
+npm run dev
+```
+
+Usage notes:
+
+- regenerate the frontend contract if your backend field changes affect the generated output
+- treat the backend entity and DTO surfaces as the first place to inspect
+- use the admin UI to confirm both the visible rendering result and the exposed mobile behavior
+
+## Generated or affected files
+
+The key backend field contract anchor is:
+
+- `vona/src/module/demo-student/src/entity/student.tsx`
+
+By the end of this tutorial, the `mobile` field should show the main capstone pattern:
+
+```typescript
+@Api.field(
+  v.title($locale('Mobile')),
+  v.required(),
+  v.min(11),
+  studentMobileSerializer(),
+  ZovaRender.order(4),
+)
+mobile: string;
+```
+
+The serializer helper lives in:
+
+- `vona/src/module/demo-student/src/lib/studentMobile.ts`
+
+The summary DTO also participates in the same thread:
+
+- `vona/src/module/demo-student/src/dto/studentSummary.tsx`
+
+The supporting render example remains:
+
+- `vona/src/module/demo-student/src/entity/student.tsx`
+  - `ZovaRender.field(...)` for `level`
+  - `ZovaRender.cell(...)` for `level`
+
+## What those files mean in the business thread
+
+This tutorial works best when you read `mobile` as one continuous contract thread.
+
+That is why `mobile` is the main capstone field, while `level` remains the supporting rendering field.
+
+### Use 1: Validation
+
+In `entity/student.tsx`, `mobile` already carries validation decisions such as:
+
+- `v.required()`
+- `v.min(11)`
+
+That means the field definition is part of the request-contract story, not only a persistence concern.
+
+### Use 2: OpenAPI generation
+
+The same field contract participates in DTO and controller flows, which then feed machine-readable API output.
+
+That is why backend field and DTO changes can later affect what frontend regeneration sees.
+
+### Use 3: Table and form rendering
+
+The main rendering example in this series remains `level`, not `mobile`.
+
+That is intentional.
+
+`level` shows how the same field-oriented contract can carry:
+
+- `ZovaRender.field(...)`
+- `ZovaRender.cell(...)`
+- built-in or custom frontend render resources
+
+This keeps the “four uses” explanation complete without forcing `mobile` to act like the best rendering example.
+
+### Use 4: Serialization and desensitization
+
+The most practical `mobile` lesson is response exposure policy.
+
+In `studentMobile.ts`, the helper:
+
+- defines the masking pattern
+- returns `v.serializerReplace(...)`
+
+That keeps the masking rule close to the field contract ecosystem instead of scattering it into ad hoc controller or service post-processing.
+
+## Verification
+
+1. make sure the local dev workflow is running:
+
+```bash
+npm run dev
+```
+
+2. open `http://localhost:7102/admin/`
+3. enter the relevant **Student** page
+4. verify that `level` still shows the expected render-driven behavior
+5. verify that `mobile` follows the validation and serialization policy you defined
+6. inspect these anchors and confirm that the four-use story is concrete rather than abstract:
+   - `vona/src/module/demo-student/src/entity/student.tsx`
+   - `vona/src/module/demo-student/src/lib/studentMobile.ts`
+   - `vona/src/module/demo-student/src/dto/studentSummary.tsx`
+
+## Read more
+
+- [Validation Guide](/backend/validation-guide)
+- [OpenAPI Guide](/backend/openapi-guide)
+- [API Schema Guide](/frontend/api-schema-guide)
+- [Server Data](/frontend/server-data)
+- [Serialization Guide](/backend/serialization-guide)
+- [Backend OpenAPI to Frontend SDK](/fullstack/openapi-to-sdk)
+- [Frontend Metadata Back to Backend](/fullstack/frontend-metadata-to-backend)
+
+## Next step
+
+After finishing this series, choose the next path based on your current task:
+
+- if you want deeper backend contract detail, continue with [Entity Guide](/backend/entity-guide) and [DTO Guide](/backend/dto-guide)
+- if you want deeper frontend contract consumption, continue with [OpenAPI SDK Guide](/frontend/openapi-sdk-guide) and [API Schema Guide](/frontend/api-schema-guide)
+- if you want more CLI-oriented workflow depth, continue with [CLI Reference](/reference/cli-reference)

package/cabloy-docs/fullstack/tutorials-overview.md

@@ -0,0 +1,192 @@
+# Fullstack Quick Start Tutorials
+
+<Badge type="info" text="Basic" />
+
+This six-part tutorial series gives you one connected, AI-guided path into Cabloy fullstack development.
+
+## Why this series exists
+
+Cabloy already has strong reference guides for CRUD, OpenAPI, DTO and entity contracts, schema-driven frontend rendering, and serialization. This series packages those capabilities into one simple workflow: each page gives you one focused prompt, AI completes the next increment, and you use the result to understand the framework model behind it.
+
+The core rhythm is:
+
+1. each page provides one focused prompt
+2. AI completes the tutorial-sized increment
+3. the generated or affected files become the next teaching surface
+4. the result is verified in the running app or generated contract output
+5. deeper reference docs remain available when more background is needed
+
+That makes the series practical as a guided, interactive workflow: each tutorial reduces the user action to one prompt, while the generated result becomes the teaching material for the next step.
+
+## The business scenario
+
+Throughout the series, you will build and refine a small **Student Training Center** example.
+
+The main business object is `student`, and the teaching fields are:
+
+- `name`
+- `description`
+- `level`
+- `mobile`
+
+Why these fields?
+
+- `level` is a good field for schema-driven form and table rendering
+- `mobile` is a good field for validation, OpenAPI output, and serialization or masking
+
+This keeps the storyline small enough for beginners while still showing Cabloy’s fullstack contract model.
+
+At the beginning of the series, the `demo-student` module does not exist yet. The tutorials build it step by step.
+
+## What you should prepare first
+
+Before starting this tutorial series, make sure you already know:
+
+- how to bootstrap a Cabloy Basic project
+- how to run the repo from the root
+- how to discover command families through `npm run vona` and `npm run zova`
+
+Read these pages first:
+
+- [Fullstack Quickstart](/fullstack/quickstart)
+- [Fullstack CLI](/fullstack/cli)
+- [CLI Reference](/reference/cli-reference)
+
+Those pages explain the repo entrypoints and the CLI-first workflow model that the tutorial prompts will reuse throughout this series.
+
+## The learning path
+
+### Phase 1: Create the module and CRUD thread
+
+- [Tutorial 1: Create Your First Module](/fullstack/tutorial-1-first-module)
+- [Tutorial 2: Create Your First CRUD](/fullstack/tutorial-2-first-crud)
+
+### Phase 2: Reverse chain — share frontend rendering metadata through the backend contract
+
+- [Tutorial 3: Frontend Metadata Sharing](/fullstack/tutorial-3-frontend-metadata-sharing)
+- [Tutorial 4: Custom Form/Table Renderers for Level](/fullstack/tutorial-4-custom-level-renderers)
+
+Important handoff note for this phase:
+
+- this phase teaches the **reverse chain** of the Cabloy contract loop
+- Tutorial 3 uses the built-in metadata branch
+- Tutorial 4 uses the custom resource handoff branch
+- once a frontend resource created in these tutorials is later consumed by backend metadata, do not stop at frontend source edits alone
+- refresh the generated frontend output, run the relevant flavor build, then run `npm run deps:vona`
+- if backend-side shared types still look stale after that normal sync flow, rebuild `vona/node_modules` and reinstall dependencies
+
+See [Contract Loop Playbook](/fullstack/contract-loop-playbook) and [Frontend Metadata Back to Backend](/fullstack/frontend-metadata-to-backend) for the full reverse-chain explanation.
+
+### Phase 3: Forward chain — share backend contracts into frontend consumption
+
+- [Tutorial 5: Backend Contract Sharing](/fullstack/tutorial-5-backend-contract-sharing)
+
+This phase teaches the **forward chain** of the contract loop: backend contract truth changes first, generated frontend consumers are refreshed second, and frontend follow-up stays thin and resource-owner-aware.
+
+### Phase 4: One field story across multiple contract surfaces
+
+- [Tutorial 6: One Contract Surface, Four Uses](/fullstack/tutorial-6-one-contract-four-uses)
+
+## The standard tutorial structure
+
+All six tutorials in this series follow the same learning structure:
+
+1. `Goal`
+2. `AI Prompt`
+3. `Why this step matters`
+4. `CLI commands to inspect/use`
+5. `Generated or affected files`
+6. `What those files mean in the business thread`
+7. `Verification`
+8. `Read more`
+9. `Next step`
+
+This makes the series easier to execute one page at a time: each page gives AI one clear increment, and the resulting output teaches why that step fits the Cabloy architecture.
+
+## How to use this series with AI
+
+Keep this series simple.
+
+In each tutorial, your main job is to copy the prompt from the page and give it to AI.
+
+That prompt already tells AI how to work in the Cabloy way, including things like:
+
+- inspect the CLI first
+- perform only the current tutorial increment
+- explain the commands it used
+- explain the business meaning of the generated or changed files
+- tell you what to verify next
+
+So for the user, the workflow is intentionally lightweight:
+
+1. open the current tutorial
+2. copy the prompt
+3. send it to AI
+4. review the result and continue to the next tutorial when ready
+
+## CLI-first rule
+
+This series assumes that AI should follow Cabloy’s CLI-first workflow before attempting manual scaffolding.
+
+In practice, the tutorial prompt should push AI to follow this rule:
+
+1. inspect the existing CLI family
+2. run the matching generator or tooling command
+3. inspect the generated result
+4. make only the minimal manual follow-up changes that the business case still needs
+
+Shared discovery commands from the repo root:
+
+```bash
+npm run vona :
+npm run vona :create
+npm run vona :tools
+
+npm run zova :
+npm run zova :create
+npm run zova :openapi
+```
+
+This is one of the most important Cabloy rules for AI-driven development in this series.
+
+## Suggested reading rhythm
+
+This series is designed to progress one prompt at a time.
+
+Each tutorial assumes that the previous result remains in place, so the workflow should stay incremental:
+
+1. complete the current tutorial prompt
+2. keep the generated result
+3. continue to the next tutorial on top of that result
+
+If a tutorial creates a new module, the local dev workflow may need `npm run dev` again so the new module is picked up before the next step.
+
+Do not jump directly to SDK generation or custom renderers before the module and CRUD thread are in place.
+
+## What you will understand by the end
+
+After the six tutorials, the completed workflow should make these Cabloy ideas clear:
+
+- when to use Vona and when to use Zova
+- why CRUD generation usually comes before hand-written backend boilerplate
+- how backend field metadata can reuse frontend render resources
+- how to evolve from built-in renderers to custom renderers
+- how backend OpenAPI contracts regenerate frontend SDKs and model helpers
+- how validation, rendering, OpenAPI, and serialization fit into one field-oriented contract model
+
+## Read together with
+
+The deeper reference guides behind this workflow include:
+
+- [CRUD Workflow](/backend/crud-workflow)
+- [Entity Guide](/backend/entity-guide)
+- [DTO Guide](/backend/dto-guide)
+- [Validation Guide](/backend/validation-guide)
+- [OpenAPI Guide](/backend/openapi-guide)
+- [Backend OpenAPI to Frontend SDK](/fullstack/openapi-to-sdk)
+- [Frontend Metadata Back to Backend](/fullstack/frontend-metadata-to-backend)
+- [OpenAPI SDK Guide](/frontend/openapi-sdk-guide)
+- [API Schema Guide](/frontend/api-schema-guide)
+- [Serialization Guide](/backend/serialization-guide)
+
+This series is not meant to replace those guides. It is meant to help you move through them in one practical, task-driven order.

package/cabloy-docs/index.md

@@ -51,9 +51,10 @@ Start here to learn the shared Cabloy architecture, see how Vona and Zova fit to
 ### For getting started
 
 1. [Fullstack Quickstart](/fullstack/quickstart)
-2. [Editions Overview](/editions/overview)
-3. [Choosing Between Cabloy Basic and Cabloy Start](/editions/choosing-between-basic-and-start)
-4. [Fullstack Introduction](/fullstack/introduction)
+2. [Fullstack Quick Start Tutorials](/fullstack/tutorials-overview)
+3. [Editions Overview](/editions/overview)
+4. [Choosing Between Cabloy Basic and Cabloy Start](/editions/choosing-between-basic-and-start)
+5. [Fullstack Introduction](/fullstack/introduction)
 
 ### For contributors and AI vibe coding workflows