cabloy 5.1.61 → 5.1.63

package/cabloy-docs/fullstack/suites-and-modules.md

@@ -0,0 +1,333 @@
+# Suites and Modules
+
+This guide explains how to think about suites and modules in the current Cabloy monorepo.
+
+Use it when you need to answer these questions clearly:
+
+1. what a suite is
+2. when to create a suite instead of only a module
+3. how suite naming works
+4. where suite-owned modules should live
+5. which CLI workflows should create the structure
+
+## Why suites exist
+
+As a project evolves, business capabilities do not usually grow as one isolated feature at a time.
+
+In real business scenarios, one business domain often requires multiple related modules that evolve together. A training domain, for example, may later grow into modules for:
+
+- training-student
+- training-course
+- training-record
+- training-attendance
+- training-certificate
+
+Because of that, the default architectural decision should usually start from a **suite** rather than from an isolated standalone module.
+
+A suite is the business-level composition boundary for a domain. A module is the feature-level implementation boundary inside that domain.
+
+A practical mental model is:
+
+- use a **suite** for the business domain
+- use **modules** for the concrete capabilities inside that domain
+
+## Suite and module roles
+
+The two units serve different jobs.
+
+### Suite
+
+A suite groups related modules into one larger business scenario or architectural area.
+
+That grouping matters because it gives the domain:
+
+- a stable ownership boundary
+- a clear place for future module growth
+- consistent source-tree organization
+- a shared naming anchor across backend and frontend
+
+### Module
+
+A module is the concrete implementation unit for one feature area.
+
+That usually means a module owns the code for things such as:
+
+- backend controllers, services, entities, DTOs, and models
+- frontend pages, components, APIs, models, and metadata
+- module-local config, locale, and other scoped resources
+
+A useful rule is:
+
+- the **suite** answers "which business domain does this belong to?"
+- the **module** answers "which capability inside that domain owns this work?"
+
+## Recommended decision path
+
+In the current Cabloy monorepo, the preferred decision path is:
+
+1. identify the business domain
+2. create a suite for that domain
+3. create one or more modules inside the suite
+4. continue feature growth inside those suite-owned modules
+
+In other words, for real business work, **suite-first** is usually the best choice.
+
+### When suite-first is the default
+
+Create a suite first when:
+
+- the work belongs to a real business domain
+- the domain is expected to grow beyond one small feature
+- backend and frontend will both evolve around the same domain
+- you want to avoid later structural migration from standalone modules into a domain boundary
+
+In practice, this is the normal path for long-lived product work.
+
+### When a standalone module is still acceptable
+
+A standalone module can still be acceptable for cases such as:
+
+- very small experiments
+- disposable demos
+- isolated utilities that are intentionally not the start of a larger domain
+- short tutorials where introducing a domain suite would add noise
+
+But this should be the exception, not the default path for real business architecture.
+
+## Naming
+
+Suite naming follows the same high-level model on both sides:
+
+```text
+Vona: FullName  = vona-suite-{providerId}-{suiteName}
+Zova: FullName  = zova-suite-{providerId}-{suiteName}
+ShortName      = {providerId}-{suiteName}
+```
+
+### Important suiteName rule
+
+In this repository, `suiteName` must follow this rule:
+
+- `suiteName` must use lowercase English letters only
+- `suiteName` must not contain another `-`
+
+This rule matters because the `-` already separates `{providerId}` and `{suiteName}` in the short name.
+
+So the supported shape is:
+
+```text
+{providerId}-{suiteName}
+```
+
+not:
+
+```text
+{providerId}-{part1-part2}
+```
+
+### Examples
+
+Representative examples from the current repo include:
+
+- `a-home`
+- `a-demo`
+- `cabloy-basic`
+
+These can be read as:
+
+- `a-home` -> providerId: `a`, suiteName: `home`
+- `a-demo` -> providerId: `a`, suiteName: `demo`
+- `cabloy-basic` -> providerId: `cabloy`, suiteName: `basic`
+
+For a training-oriented suite, the valid short name is:
+
+- `a-training`
+
+where:
+
+- providerId: `a`
+- suiteName: `training`
+
+A practical rule is:
+
+- keep `suiteName` simple, lowercase, and single-segment
+- do not add another `-` inside `suiteName`
+- if you need more semantic detail, express it through module names inside the suite rather than by making the suite name longer
+
+## Supported directory pattern
+
+To keep the code style consistent and reduce cognitive overhead, this repository supports only one suite layout for normal authoring work:
+
+- **suite-contained modules**
+
+That means when a suite exists, its modules belong under that suite.
+
+### Backend pattern
+
+```text
+vona/src/suite/<suite>/modules/<module>/
+```
+
+### Frontend pattern
+
+```text
+zova/src/suite/<suite>/modules/<module>/
+```
+
+### Example
+
+```text
+vona/src/suite/a-training/
+├── modules/
+│  ├── training-student/
+│  ├── training-course/
+│  └── training-record/
+└── package.json
+```
+
+```text
+zova/src/suite/a-training/
+├── modules/
+│  ├── training-student/
+│  ├── training-course/
+│  └── training-record/
+└── package.json
+```
+
+## Unsupported pattern for normal project authoring
+
+For consistency, do not treat a suite as a loose composition package that only depends on standalone modules located elsewhere.
+
+In other words, do not use a suite as a separate conceptual wrapper while keeping its real modules outside the suite tree.
+
+Use the suite as the real ownership boundary, and keep the suite-owned modules physically inside:
+
+- `vona/src/suite/<suite>/modules/`
+- `zova/src/suite/<suite>/modules/`
+
+This keeps the source tree easier to read and avoids extra mental branching about whether a module is only logically related to a suite or actually owned by it.
+
+## CLI-first workflow
+
+Do not scaffold suite/module structure manually when the CLI already supports it.
+
+Use the framework CLI first, then make only the minimal follow-up edits that the task still needs.
+
+### Create a backend suite
+
+```bash
+npm run vona :create:suite suiteName
+```
+
+### Create a frontend suite
+
+```bash
+npm run zova :create:suite suiteName
+```
+
+### Create a backend module inside a suite
+
+```bash
+npm run vona :create:module moduleName -- --suite=suiteName
+```
+
+### Create a frontend module inside a suite
+
+```bash
+npm run zova :create:module moduleName -- --suite=suiteName
+```
+
+A practical fullstack rule is:
+
+- use `npm run vona` to create the backend side of the domain
+- use `npm run zova` to create the frontend side of the domain
+- for a real business domain, create the suite first on both sides, then create the suite-owned modules
+
+## Recommended workflow for real business domains
+
+A practical suite-first workflow is:
+
+1. decide the domain boundary
+2. choose a valid suite short name
+3. create the suite in Vona
+4. create the suite in Zova
+5. create the first backend and frontend modules inside that suite
+6. continue all later domain growth inside the same suite
+
+For example, for a training domain:
+
+```bash
+npm run vona :create:suite a-training
+npm run zova :create:suite a-training
+
+npm run vona :create:module training-student -- --suite=a-training
+npm run zova :create:module training-student -- --suite=a-training
+```
+
+Later domain growth can continue with modules such as:
+
+- training-course
+- training-record
+- training-attendance
+
+This keeps the domain boundary stable while the capabilities inside it expand.
+
+## How to choose between a suite and only a module
+
+Use this rule:
+
+### Choose a suite first when
+
+- the work belongs to a real domain
+- more related modules are likely
+- the feature will grow across backend and frontend
+- you want the structure to remain stable as the domain expands
+
+### Choose only a standalone module when
+
+- the work is intentionally isolated
+- the scope is very small
+- the code is exploratory or disposable
+- creating a domain suite would add more ceremony than value
+
+For most real business scenarios, the correct answer is to create the suite first.
+
+## Relationship to repo structure
+
+This guide should be read together with:
+
+- [Package Map](/reference/package-map)
+- [Backend Directory Structure](/reference/backend-directory-structure)
+- [Frontend Directory Structure](/reference/frontend-directory-structure)
+- [Backend CLI](/backend/cli)
+- [Frontend CLI](/frontend/cli)
+- [Fullstack CLI](/fullstack/cli)
+
+A practical split is:
+
+- this page explains the decision model for suites and modules
+- the reference pages explain where those units live in the repo
+- the CLI pages explain how to generate them correctly
+
+## Verification
+
+After creating or restructuring suites and modules, verify with the narrowest useful checks first.
+
+Typical checks include:
+
+```bash
+npm run vona :
+npm run zova :
+
+npm run deps:vona
+npm run deps:zova
+
+npm run tsc
+```
+
+If the change affects broader cross-stack output, also use the relevant build flow from the repo root.
+
+The key rule is:
+
+- verify that the suite and module were created in the intended structural location
+- verify that later commands and dependency refresh flows still recognize that structure

package/cabloy-docs/fullstack/tutorial-1-first-module.md

@@ -52,6 +52,8 @@ Usage notes:
 - use `npm run vona :create:module` for the backend module boundary
 - use `npm run zova :create:module` for the frontend module boundary
 - use an empty `--suite=` when you want an independent module rather than a suite-owned module
+- this tutorial intentionally uses a standalone `demo-student` sandbox so readers can experiment without colliding with the repo's real `a-training/training-student` example
+- for the normal suite-first domain decision path, see [Suites and Modules](/fullstack/suites-and-modules)
 - rerun `npm run dev` after module creation so the local workflow picks up the new modules cleanly
 
 ## Generated or affected files
@@ -82,6 +84,7 @@ At this stage, the key idea is ownership, not business logic yet.
 - the backend module root is where the Student resource, entity, DTOs, controller, tests, and backend metadata will live later
 - the frontend module root is where generated OpenAPI output, model helpers, render resources, and frontend metadata will live later
 - the frontend `.metadata` entrypoint is part of how the module exposes its local registration surface
+- because this tutorial path is intentionally standalone, you can compare its generated result against the repo's real suite-owned `a-training/training-student` implementation without overwriting it
 
 A good beginner rule is: do not rush into editing business logic until you can explain which module roots were created and why they will own the next tutorials.
 

package/cabloy-docs/fullstack/tutorial-2-first-crud.md

@@ -27,6 +27,10 @@ Once the module exists, this is the next useful step because the prompt can driv
 
 That keeps the conversation focused on the generated business thread rather than on repetitive scaffolding details.
 
+> [!NOTE]
+> This tutorial continues the standalone `demo-student` sandbox from Tutorial 1.
+> That sandbox is intentional: it lets you run the full tutorial flow without colliding with the repo's real suite-owned `a-training/training-student` implementation.
+
 ## CLI commands to inspect/use
 
 Inspect the CRUD family first:

package/cabloy-docs/fullstack/tutorial-3-frontend-metadata-sharing.md

@@ -6,6 +6,10 @@ In this tutorial, one prompt lets AI show the **reverse chain** of Cabloy’s fu
 
 You start with the simplest path first: reuse the existing built-in rendering resources for the `level` field.
 
+> [!NOTE]
+> This tutorial still uses the standalone `demo-student` sandbox introduced in Tutorial 1.
+> Keep that sandbox separate from the repo's real suite-owned `a-training/training-student` example so you can experiment and compare the two paths side by side.
+
 ## Goal
 
 By the end of this tutorial, you will understand:

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

@@ -2,13 +2,21 @@
 
 <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.
+In this tutorial, one prompt lets the user express a simple product need: the `level` field in the Student experience should feel less generic and more like a real training-stage workflow.
 
-This is the **reverse chain** custom-resource handoff branch of the contract loop.
+From that user need, AI can infer that the next step is no longer just relabeling the field. It now needs a more dedicated rendering experience owned by the `demo-student` module.
+
+This tutorial covers the **reverse chain** custom-resource handoff branch of the contract loop.
+
+> [!NOTE]
+> Like the earlier tutorials in this series, this page keeps using the standalone `demo-student` sandbox.
+> That keeps the custom-renderer experiment isolated from the repo's real suite-owned `a-training/training-student` implementation.
 
 ## Goal
 
-By the end of this tutorial, you will understand:
+By the end of this tutorial, you will understand how a user-facing request about a more business-specific `level` experience turns into a concrete custom-renderer implementation.
+
+In particular, 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
@@ -19,17 +27,17 @@ By the end of this tutorial, you will understand:
 Give AI a prompt like this:
 
 ```text
-Please make the level UI more business-specific in the Student list page and form.
+For demo purposes, use custom renderer components to give the `level` field on the Student list page and form a more distinctive look and feel.
 ```
 
 ## 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.
+This is the right follow-up step because built-in render resources are a good starting point, but some fields eventually need a more distinctive user experience to match the business workflow.
 
-The `level` field is a good teaching example because this step deepens the UI in two concrete ways:
+The `level` field is a good teaching example because users often expect two improvements once a training workflow becomes more realistic:
 
-- 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
+- the list should make each training stage easier to recognize at a glance
+- the form should guide the user more clearly when choosing a training stage
 
 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.
 
@@ -52,15 +60,15 @@ 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
+- use `:create:bean` when AI determines that the list needs a dedicated table-cell render resource under the bean scene
+- use `:create:component` when AI determines that the form needs 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:
+To satisfy the user-facing need above, AI will usually converge on a small set of implementation anchors like these:
 
 - custom table cell bean:
   - `zova/src/module/demo-student/src/bean/tableCell.level.tsx`
@@ -71,34 +79,38 @@ By the end of this tutorial, your module should provide these teaching anchors:
 - backend field contract to update:
   - `vona/src/module/demo-student/src/entity/student.tsx`
 
-Representative custom metadata targets are:
+Representative metadata targets after AI makes that implementation decision are:
 
 ```typescript
 ZovaRender.field('demo-student:formFieldLevel', {
   items: levelItems,
   helper: $locale('LevelPlaceholder'),
-})
+});
 ```
 
 and:
 
 ```typescript
-ZovaRender.cell('demo-student:level', { items: levelItems })
+ZovaRender.cell('demo-student:level', { items: levelItems });
 ```
 
-## What those files mean in the business thread
+This is the point where a user request about “better list presentation” and “better form guidance” starts turning into explicit renderer resources and backend metadata links.
 
-This tutorial makes the split of responsibilities explicit:
+## How those files support the user experience
 
-- `tableCell.level.tsx` owns the custom table-cell rendering behavior for `level`
-- `component/formFieldLevel/controller.tsx` owns the custom form-field behavior for `level`
+These files work together to deliver the richer `level` experience:
+
+- `tableCell.level.tsx` makes the training stage easier to recognize in the list
+- `component/formFieldLevel/controller.tsx` makes the form interaction more guided and business-specific
 - `.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.
+That means the backend still defines the business field, validation, and metadata entry point, while the frontend module owns the implementation details that make the experience feel more tailored to the Student Training Center workflow.
 
 ## Verification
 
+These checks are the reverse-chain synchronization steps AI must complete so the user-facing renderer change is actually available to backend consumers and the running app.
+
 1. refresh the generated handoff surfaces before checking backend consumers:
 
 ```bash

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

@@ -9,6 +9,10 @@ The teaching thread in this page is the pair of Student actions:
 - `summary/:id`
 - `deleteForce/:id`
 
+> [!NOTE]
+> This tutorial still runs inside the standalone `demo-student` sandbox from the earlier pages.
+> Use that sandbox for OpenAPI regeneration experiments so you do not interfere with the repo's real suite-owned `a-training/training-student` implementation.
+
 ## Goal
 
 By the end of this tutorial, you will understand:
@@ -135,6 +139,7 @@ npm run dev
 
 ## Read more
 
+- [Backend Metadata to Frontend Table Actions](/fullstack/backend-metadata-to-frontend-table-actions)
 - [Backend OpenAPI to Frontend SDK](/fullstack/openapi-to-sdk)
 - [OpenAPI Guide](/backend/openapi-guide)
 - [OpenAPI SDK Guide](/frontend/openapi-sdk-guide)

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

@@ -8,6 +8,10 @@ This capstone sits on top of both the forward chain and the reverse chain rather
 
 This time the main teaching field is `mobile`, while `level` stays as the supporting example for table and form rendering.
 
+> [!NOTE]
+> This capstone still uses the standalone `demo-student` sandbox carried through the tutorial series.
+> That keeps the final experiment path isolated while preserving a clean comparison against the repo's real suite-owned `a-training/training-student` implementation.
+
 ## Goal
 
 By the end of this tutorial, you will understand how one business field thread can participate in:

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

@@ -36,7 +36,7 @@ Why these fields?
 
 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.
+At the beginning of the series, the `demo-student` module does not exist yet. The tutorials build it step by step. This standalone tutorial track is intentional: it gives readers a safe experiment surface that does not collide with the repo's real `a-training/training-student` implementation and also makes side-by-side comparison easier.
 
 ## What you should prepare first
 

package/cabloy-docs/reference/bean-scene-boilerplates.md

@@ -28,15 +28,15 @@ A practical contributor rule is:
 
 ### Current built-in scenes with variants
 
-| Scene          | Default metadata key | Named variant keys  | Example command                                                                               | Source module          |
-| -------------- | -------------------- | ------------------- | --------------------------------------------------------------------------------------------- | ---------------------- |
-| `filter`       | `boilerplate`        | `boilerplateGlobal` | `npm run vona :create:bean filter log -- --module=demo-student --boilerplate=global`          | `vona-module-a-aspect` |
-| `pipe`         | `boilerplate`        | `boilerplateGlobal` | `npm run vona :create:bean pipe log -- --module=demo-student --boilerplate=global`            | `vona-module-a-aspect` |
-| `interceptor`  | `boilerplate`        | `boilerplateGlobal` | `npm run vona :create:bean interceptor log -- --module=demo-student --boilerplate=global`     | `vona-module-a-aspect` |
-| `guard`        | `boilerplate`        | `boilerplateGlobal` | `npm run vona :create:bean guard auth -- --module=demo-student --boilerplate=global`          | `vona-module-a-aspect` |
-| `middleware`   | `boilerplate`        | `boilerplateGlobal` | `npm run vona :create:bean middleware trace -- --module=demo-student --boilerplate=global`    | `vona-module-a-aspect` |
-| `ssrMenu`      | `boilerplate`        | `boilerplateWeb`    | `npm run vona :create:bean ssrMenu menuTest -- --module=demo-student --boilerplate=web`       | `vona-module-a-ssr`    |
-| `ssrMenuGroup` | `boilerplate`        | `boilerplateWeb`    | `npm run vona :create:bean ssrMenuGroup groupTest -- --module=demo-student --boilerplate=web` | `vona-module-a-ssr`    |
+| Scene          | Default metadata key | Named variant keys  | Example command                                                                                   | Source module          |
+| -------------- | -------------------- | ------------------- | ------------------------------------------------------------------------------------------------- | ---------------------- |
+| `filter`       | `boilerplate`        | `boilerplateGlobal` | `npm run vona :create:bean filter log -- --module=training-student --boilerplate=global`          | `vona-module-a-aspect` |
+| `pipe`         | `boilerplate`        | `boilerplateGlobal` | `npm run vona :create:bean pipe log -- --module=training-student --boilerplate=global`            | `vona-module-a-aspect` |
+| `interceptor`  | `boilerplate`        | `boilerplateGlobal` | `npm run vona :create:bean interceptor log -- --module=training-student --boilerplate=global`     | `vona-module-a-aspect` |
+| `guard`        | `boilerplate`        | `boilerplateGlobal` | `npm run vona :create:bean guard auth -- --module=training-student --boilerplate=global`          | `vona-module-a-aspect` |
+| `middleware`   | `boilerplate`        | `boilerplateGlobal` | `npm run vona :create:bean middleware trace -- --module=training-student --boilerplate=global`    | `vona-module-a-aspect` |
+| `ssrMenu`      | `boilerplate`        | `boilerplateWeb`    | `npm run vona :create:bean ssrMenu menuTest -- --module=training-student --boilerplate=web`       | `vona-module-a-ssr`    |
+| `ssrMenuGroup` | `boilerplate`        | `boilerplateWeb`    | `npm run vona :create:bean ssrMenuGroup groupTest -- --module=training-student --boilerplate=web` | `vona-module-a-ssr`    |
 
 These backend entries come from the current `vonaModule.onions` metadata in `a-aspect` and `a-ssr`.
 
@@ -44,10 +44,10 @@ These backend entries come from the current `vonaModule.onions` metadata in `a-a
 
 ### Current built-in scenes with variants
 
-| Scene       | Default metadata key | Named variant keys                                | Example command pattern                                                                          | Source module           |
-| ----------- | -------------------- | ------------------------------------------------- | ------------------------------------------------------------------------------------------------ | ----------------------- |
-| `command`   | `boilerplate`        | `boilerplateCommandBulk`, `boilerplateCommandRow` | `npm run zova :create:bean command test -- --module=demo-student --boilerplate=commandRow`       | `zova-module-a-command` |
-| `tableCell` | `boilerplate`        | `boilerplateTableActionRow`                       | `npm run zova :create:bean tableCell test -- --module=demo-student --boilerplate=tableActionRow` | `zova-module-a-table`   |
+| Scene       | Default metadata key | Named variant keys                                | Example command pattern                                                                              | Source module           |
+| ----------- | -------------------- | ------------------------------------------------- | ---------------------------------------------------------------------------------------------------- | ----------------------- |
+| `command`   | `boilerplate`        | `boilerplateCommandBulk`, `boilerplateCommandRow` | `npm run zova :create:bean command test -- --module=training-student --boilerplate=commandRow`       | `zova-module-a-command` |
+| `tableCell` | `boilerplate`        | `boilerplateTableActionRow`                       | `npm run zova :create:bean tableCell test -- --module=training-student --boilerplate=tableActionRow` | `zova-module-a-table`   |
 
 These frontend entries come from the current `zovaModule.onions` metadata in `a-command` and `a-table`.
 

package/cabloy-docs/reference/package-map.md

@@ -32,10 +32,10 @@ Representative package metadata in the current repo shows the distinction clearl
 
 ### Module package
 
-Example: `vona/src/module/demo-student/package.json`
+Example: `vona/src/suite/a-training/modules/training-student/package.json`
 
-- package name: `vona-module-demo-student`
-- title: `demo-student`
+- package name: `vona-module-training-student`
+- title: `training-student`
 - `vonaModule.dependencies` records module-level framework dependencies
 
 ### Suite package
@@ -74,6 +74,7 @@ A practical comparison is:
 
 Use this package map together with:
 
+- [Suites and Modules](/fullstack/suites-and-modules)
 - [Backend Essentials](/backend/backend-essentials)
 - [Backend Foundation](/backend/foundation)
 - [Backend CLI](/backend/cli)

package/package.json

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