cabloy 5.1.157 → 5.1.159

package/.cabloy-version

@@ -1 +1 @@
-5.1.157
+5.1.159

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

@@ -18,11 +18,11 @@ This includes the reverse fullstack direction where newly added frontend resourc
 In that situation:
 
 1. run the normal sync or regeneration flow first
-2. run the relevant Zova build from the repo root before `npm run deps:vona`
-   - use `npm run build:zova:admin` for Admin-facing render/action/metadata changes
-   - also run `npm run build:zova:web` when the Web flavor is affected
+2. identify every affected flavor from the active repository’s root wrappers and lower-level Zova scripts, then run each matching paired SSR/REST build before `npm run deps:vona`
+   - `npm run build:zova:admin` and `npm run build:zova:web` are representative default wrappers only
+   - an independently named site must use its own source-confirmed paired root wrapper; do not relabel or assume a default wrapper refreshed it
 3. do not treat `build:rest:*` alone as sufficient, because the SSR bundle and rest output must move together
-4. run `npm run deps:vona`
+4. run `npm run deps:vona` after the required flavor builds
 5. if the generated `.zova-rest` artifacts already contain the expected changes but Vona still sees stale types, delete `vona/node_modules` and reinstall dependencies
 
 Do not keep debugging source-level contract or renderer changes until the local file-package installation state is known to be healthy.
@@ -101,6 +101,22 @@ In this mode, first diagnose whether the visible stale behavior comes from skipp
 
 Use this mode when generated artifacts already contain the expected keys, types, or resources, but installed local file dependencies still behave stale after the normal sync flow.
 
+### Mode E: independent SSR flavor and site
+
+Use this mode when the request adds a deployable Zova SSR surface that Vona must dispatch separately. This is more than a page or route inside an existing site.
+
+Before proposing implementation, inspect the active repository rather than inferring names from Admin or Web:
+
+1. edition marker and root `package.json` wrappers;
+2. `zova/package.json` or its durable source for matching `dev:ssr:*`, `build:ssr:*`, and `build:rest:*` scripts;
+3. flavor env/config and its `SITE_ID`, mount path, SSR profile, and artifact-copy targets;
+4. a Vona `@SsrSite(...)` baseline and the owning site-module asset path;
+5. the expected SSR release directory and flavor-specific `zova-rest-*` package.
+
+The independent identity tuple—flavor, site ID, public path, bundle path, REST package, Vona site module, and root paired-build wrapper—must be selected together. The root wrapper must build both SSR and REST output before `npm run deps:vona`; `build:rest:*` alone is not enough. Default Basic or Start Admin/Web wrappers are validated specimens, not a command template for a differently named site.
+
+Read [Independent SSR Site and Flavor Setup](../../../repo-docs/fullstack/ssr-site-and-flavor-setup.md) for the canonical setup and evidence procedure.
+
 If the task is only backend scaffolding or only frontend scaffolding, the more specialized scaffold skills may be the better primary choice.
 
 ## Step 2: Start from the contract source of truth
@@ -225,7 +241,7 @@ Important Cabloy Basic reverse-sync rule:
 - if the change was consumer-side, low-confidence, cross-edition, or happened outside the Claude hook path, run the reverse sync flow deliberately yourself
 - prefer visible proof under `zova/src/**/.metadata/**` when it is available; if the effective handoff only appears in `.zova-rest`, treat the safeguard as conservative reminder/auto-sync assistance rather than strict proof
 
-For Cabloy Start, verify the exact Start-specific flavor names, paths, SSR site baselines, and project assets in the active Start repository.
+For Cabloy Start, verify the exact Start-specific flavor names, paths, SSR site baselines, project assets, and source-confirmed root wrappers in the active Start repository. If the work affects an independent SSR site, follow Mode E: build that site’s paired wrapper rather than assuming an Admin/Web command covers it.
 
 ### Schema-driven UI decision branch
 
@@ -273,10 +289,11 @@ Especially verify:
 
 - active repo marker
 - affected frontend flavor
-- whether the change affects Admin, Web, or both
+- whether the change affects a default Admin/Web site, an independent site, or more than one site
+- source-confirmed root wrapper for every affected flavor
 - whether the generated output path is edition-specific
 
-Do not silently reuse Basic-specific examples in Start workflows.
+Do not silently reuse Basic-specific examples in Start workflows or treat default Admin/Web commands as an independent-site template.
 
 ## Step 7: End-to-end verification
 

package/.claude/skills/cabloy-contract-loop/evals/evals.json

@@ -30,6 +30,18 @@
       "prompt": "One persisted Order domain needs read-only Admin select/view operations through presetResource and customer Web list/detail reads. Should Admin and Web share one API and ModelResource, or should I use mine/viewMine-style Web operations and a separate Web model? Include the Cabloy contract-loop steps.",
       "expected_output": "Keeps one domain and persistence boundary while separating Admin select/view and explicit owner-scoped Web operations with audience-specific DTOs. Keeps ModelResource as the Admin Resource owner and accepts a dedicated Web model/pages only for the distinct self-service state. Requires backend-first OpenAPI inspection, constrained regeneration for all owned operations, and verification of Admin authorization, Web owner scope before pagination, SSR admission where relevant, and both consumer paths. Rejects forcing Web through presetResource and rejects a parallel Admin cache owner for an ordinary custom Admin action.",
       "files": []
+    },
+    {
+      "id": 6,
+      "prompt": "In Cabloy Start, add an independently mounted SSR site with a new Zova flavor. What must be discovered and built before Vona can serve it?",
+      "expected_output": "Detects the Start repository and discovers the site-specific flavor env/config, lower-level SSR and REST scripts, root paired wrapper, Vona @SsrSite baseline, artifact path, and generated zova-rest package. Requires a new aligned site identity tuple and paired SSR-plus-REST build followed by deps:vona. Rejects reusing or relabeling default Admin/Web wrappers, REST-only rebuilding, and Commerce-specific names or paths as a generic template.",
+      "files": []
+    },
+    {
+      "id": 7,
+      "prompt": "A Vona consumer remains stale after an independent SSR flavor change. The new flavor artifacts appear correct. What is the safe Cabloy diagnosis order?",
+      "expected_output": "Requires proving that the selected site-specific wrapper generated both SSR and REST artifacts, confirming the matching Vona bundle/type identity, and running deps:vona before calling it local dependency drift. Does not suggest REST-only rebuilding or default Admin/Web commands for the independent site. Only after the normal handoff is proved does it recommend repairing Vona local installation state.",
+      "files": []
     }
   ]
 }

package/.claude/skills/cabloy-contract-loop/references/contract-loop-map.md

@@ -145,6 +145,34 @@ The Web model is valid only for the separate self-service state domain. It must
    - backend tooling and type hints
    - SSR or integration paths that depend on refreshed frontend output
 
+## Independent SSR site/flavor handoff map
+
+Use this map when Vona must serve a newly independent Zova SSR site, rather than when a route is added to an existing site.
+
+1. authored site boundary
+   - flavor env and optional flavor config
+   - site-specific route, layout, admission, locale, and asset choices
+   - exact site ID and mounted public path
+2. paired frontend artifacts
+   - SSR bundle and client assets copied to the owning Vona site module
+   - flavor-specific generated REST/type package copied to Vona’s local workspace
+   - one source-confirmed root wrapper that produces both outputs
+3. Vona consumer registration
+   - independently packaged site module
+   - `@SsrSite(...)` identity, public path, bundle path, localized title, and diagnostics command
+   - typed site/public-path augmentation plus generated page/icon imports from the matching REST package
+4. dependency handoff
+   - run the selected site wrapper first
+   - run `npm run deps:vona` only after both artifacts exist
+   - do not treat `build:rest:*` alone as a Vona SSR handoff
+5. consumer proof
+   - Vona dispatch reaches the intended public path
+   - raw HTML is server-rendered and assets resolve
+   - browser hydration and route aliases preserve the mounted boundary
+   - admission, redirect, and cache behavior match the site contract
+
+Default Admin/Web wrappers are specimens only. Discover the independently named site’s own scripts and generated paths from the active edition before recommending commands.
+
 ## Drift diagnosis matrix
 
 ### Source wrong

package/.claude/skills/cabloy-contract-loop/references/verification-checklist.md

@@ -37,8 +37,9 @@ When one persisted domain has both Admin Resource and Web self-service consumers
 
 - frontend-owned source is correct
 - metadata generation completed when applicable
-- the relevant flavor build completed successfully
-- `deps:vona` completed
+- every affected flavor’s source-confirmed paired SSR/REST build completed successfully
+- `deps:vona` completed after the paired builds
+- `build:rest:*` was not treated as the only Vona SSR handoff
 - backend consumers can resolve the refreshed frontend-generated handoff
 - prefer visible proof under `zova/src/**/.metadata/**` when it is available
 - this repo does not rely on a contract-loop pre-commit gate; the active safeguard is the Claude hook layer
@@ -48,6 +49,22 @@ When one persisted domain has both Admin Resource and Web self-service consumers
 - `npm run tsc:zova`
 - relevant flavor-specific or route-specific checks
 
+### Independent SSR site/flavor verification
+
+When Vona consumes a new independent SSR site, also verify:
+
+- the active edition and exact flavor are confirmed from source
+- `SITE_ID`, Vona `siteId`, Zova `APP_PUBLIC_PATH`, and Vona `publicPath` align; enabled site IDs and public paths remain unique
+- Vona `bundlePath` exactly matches the copied SSR release directory
+- the generated `zova-rest-*` package matches the Vona type import
+- the source-confirmed root wrapper generated both the SSR bundle and REST/type output
+- `npm run deps:vona` ran after that paired build, and Vona resolves the refreshed local package
+- the site diagnostics command names that same wrapper rather than a default Admin/Web command
+- raw Vona-served HTML proves server rendering at the intended mounted path
+- client assets load, hydration completes without mismatch, and aliases do not duplicate the mount path
+- public/private admission, redirect, and cache expectations match the selected SSR profile
+- targeted browser or E2E evidence covers the site through Vona, not only a standalone frontend server
+
 ## Consumer drift verification
 
 - source truth already looks correct

package/.claude/skills/cabloy-resource-field-update/SKILL.md

@@ -180,6 +180,24 @@ Important serialization reminder:
 - for performance reasons, Vona response serialization is opt-in per API action
 - verify that the target controller action explicitly uses `@Core.serializer()` before concluding that serializer metadata is broken
 
+### Join-backed foreign-key filtering and sorting
+
+Use this metadata/query-contract branch when a persisted relation field remains an identity, but a resource list must filter or order it by a human-readable column on the related table. This is a metadata-only refinement when the foreign-key column already exists; do not increment `fileVersion` solely for this behavior.
+
+Keep the entity field name and identity schema unchanged. Put the relation mapping on the entity field so inferred projections retain it:
+
+- `v.filter({ table, joinType, joinOn, originalName, op })` maps the public relation field to the related display column;
+- `ZovaRender.column({ enableSorting: true })` exposes the table sort control when the list should support ordering;
+- preserve existing relation picker/cell metadata and `v.tableIdentity()` (or the applicable identity schema).
+
+For a required relation, `innerJoin` is usually appropriate. When the relation is optional or unmatched base rows must remain visible, choose the join semantics explicitly instead of copying an inner-join example.
+
+Keep the public query and order key equal to the foreign-key field name. In the select request DTO, retain that inferred field and use `$makeSchema(...)` only to change its query-input schema and renderer, usually to `v.optional()`, `z.string()`, and Cabloy Basic's `basic-input:formFieldInput`. Do not replace the entity storage schema with a string or add a parallel display-name parameter unless the API intentionally exposes separate ID and display-name filters.
+
+Verify direct DTO metadata, the emitted optional text query parameter, absence of an unintended alternate parameter, visible sortable-column metadata, and endpoint filtering plus ascending/descending ordering. Confirm that filtering and ordering resolve to the intended related display column and inject the expected join.
+
+See [Existing Resource Field Update](../../../repo-docs/backend/resource-field-update.md#filter-and-sort-a-relation-by-its-display-field) for the public pattern and links to the ORM and frontend query-flow guides.
+
 ## Step 6: Apply the renderer branch deliberately
 
 ### Default rule: prefer shared renderer reuse

package/.claude/skills/cabloy-zova-source-reading/SKILL.md

@@ -139,6 +139,20 @@ When a translated schema title, renderer, or validation surface remains stale af
 
 The key distinction is between a genuinely stale generated contract and a valid schema facade captured from an earlier locale. `$computed` is only locale-safe when its dependency path reacquires the current schema source; wrapping an old facade or transformed snapshot does not make it current.
 
+### Raw-`this` reactivity boundary
+
+When an author reports that a controller field changed but a TSX render, `$computed`, or `$watch` did not react, inspect this lifecycle boundary before recommending framework-neutral rewrites:
+
+1. inspect `zova-core/src/bean/beanContainer.ts` `BeanContainer._prepareBeanInstanceCommon(...)` to verify that `new BeanClass(...)` occurs before the framework exposes the reactive/proxied bean;
+2. inspect `BeanContainer._initBeanInstance(...)` to verify that `__init__()` is invoked only after preparation;
+3. check whether a class-field arrow callback or construction-time `bind(this)` captured raw `this` and later writes bean state;
+4. distinguish this from a callback created in `__init__()`, whose lexical `this` is the exposed bean; and
+5. verify whether the dependent render read through that same exposed identity.
+
+State the consequence precisely: a proxy-based TSX render read can track normally, while a mutation through a raw construction-time callback changes the underlying field without notifying that dependency. An unrelated reactive update can later expose the changed value during another render.
+
+Do **not** summarize this as “arrow functions are non-reactive,” and do not default to `ref.value`, `toRaw`, or generic Vue rewrites. Explain the Zova bean lifecycle first; recommend ordinary controller methods for normal actions, or closures created in `__init__()` only when a stable callback reference is required.
+
 ## Step 5: Explain Zova-native meaning first
 
 When answering, explain the Zova role first, then add Vue analogies only if they help.

package/.claude/skills/cabloy-zova-source-reading/references/core-reading-paths.md

@@ -20,6 +20,16 @@ Use when the question is about:
 - `$computed`
 - `$params` / `$query`
 - page render flow
+- a class-field arrow callback, callback identity, or stale TSX after an apparent controller-state mutation
+
+For a raw-`this` reactivity symptom, verify this expected sequence:
+
+1. `BeanContainer` constructs the class instance before it exposes the reactive/proxied bean;
+2. a class-field arrow callback captures that construction-time raw `this`;
+3. `__init__()` runs after preparation, so a closure created there captures the exposed bean instead; and
+4. a render dependency invalidates only when its mutation travels through the same exposed reactive identity used for the read.
+
+Therefore, do not classify the issue as “arrow functions are non-reactive.” Distinguish a raw-captured write that changes the underlying field without a trigger from an ordinary controller method or `__init__()` callback that writes through the exposed bean.
 
 ## Component controller and wrapper path
 

package/.github/workflows/docs-pages.yml

@@ -5,6 +5,9 @@ on:
       - main
     paths:
       - 'repo-docs/**'
+      - 'repo-e2e/docs/**'
+      - 'package.json'
+      - 'pnpm-lock.yaml'
       - 'README.md'
       - '.github/workflows/docs-pages.yml'
   workflow_dispatch:
@@ -33,12 +36,25 @@ jobs:
           node-version: 24
           cache: pnpm
           cache-dependency-path: repo-docs/pnpm-lock.yaml
+      - name: install root dependencies
+        run: pnpm install --frozen-lockfile
       - name: install docs dependencies
         run: pnpm --dir repo-docs install --frozen-lockfile
-      - name: build docs
+      - name: install Chromium
+        run: pnpm exec playwright install --with-deps chromium
+      - name: build docs and verify layout
         env:
           GA_MEASUREMENT_ID: ${{ vars.GA_MEASUREMENT_ID }}
-        run: pnpm --dir repo-docs docs:build
+        run: npm run test:docs:e2e
+      - name: upload docs E2E artifacts
+        if: failure()
+        uses: actions/upload-artifact@v7
+        with:
+          name: docs-e2e-artifacts
+          path: |
+            repo-e2e/docs/playwright-report/
+            repo-e2e/docs/test-results/
+          if-no-files-found: ignore
       - name: setup pages
         uses: actions/configure-pages@v5
       - name: upload pages artifact

package/CHANGELOG.md

@@ -1,5 +1,31 @@
 # Changelog
 
+## 5.1.159
+
+### Features
+
+- Add form layout support.
+- Add render column support.
+- Add OpenAPI title support for DTOs.
+- Add form schema title support.
+- Add configurable page title keys.
+- Add blog styling enhancements.
+
+### Improvements
+
+- Update documentation for joined backend filtering and sorting.
+- Document raw `this` reactivity boundaries.
+- Document SSR site and flavor setup.
+- Improve documentation links, layouts, page metadata guidance, and blog styling.
+- Update site configuration and controller behavior.
+
+## 5.1.158
+
+### Improvements
+
+- Add licensing documentation.
+- Add contribution guidelines.
+
 ## 5.1.157
 
 ### Features

package/CONTRIBUTING.md

@@ -0,0 +1,84 @@
+# Contributing to Cabloy Basic
+
+Contributions to Cabloy Basic source, tests, tooling, and documentation are welcome. Cabloy Basic is the public Cabloy framework/reference edition, with Vona backend and Zova frontend layers.
+
+## Before you begin
+
+- Use [GitHub Issues](https://github.com/cabloy/cabloy/issues) for reproducible bugs, public questions, and feature proposals. Search for an existing issue first.
+- Use [pull requests](https://github.com/cabloy/cabloy/pulls) for focused, reviewable changes.
+- For a bug report, include the expected and actual behavior, a minimal reproduction or sufficient setup details, and relevant Cabloy, Node.js, pnpm, database, and browser/runtime versions.
+- Remove credentials, tokens, personal data, and sensitive system information from issues, logs, screenshots, and pull requests.
+
+## Set up a development checkout
+
+You need Git, Node.js `>=24.4.0`, pnpm `>=11.5.2`, Redis `>=7.2.6`, and one documented development database baseline: SQLite, MySQL `>=8`, or PostgreSQL `>=16`. SQLite setups using `better-sqlite3` may also require a native build toolchain for `node-gyp`.
+
+```bash
+git clone https://github.com/cabloy/cabloy.git
+cd cabloy
+npm run init
+```
+
+`npm run init` is more than a package install: it installs multiple workspaces, prepares generated local configuration, initializes and synchronizes Vona and Zova, and generates required frontend and backend artifacts. Run it intentionally rather than as a retry for an unrelated narrow change.
+
+Current CI workflows run on Ubuntu with Node.js 24 after pushes to `main`; do not assume that every pull request is automatically validated. For maintained onboarding guidance, see [Cabloy Basic](https://cabloy.com/editions/cabloy-basic).
+
+## Develop and validate
+
+Start with the narrowest meaningful check, then broaden validation when a change crosses a shared boundary.
+
+| Purpose                                  | Command                    |
+| ---------------------------------------- | -------------------------- |
+| Start Vona development                   | `npm run dev`              |
+| Start one Vona development process       | `npm run dev:one`          |
+| Start Basic Admin SSR development        | `npm run dev:zova:admin`   |
+| Start Basic Web SSR development          | `npm run dev:zova:web`     |
+| Check formatting                         | `npm run format`           |
+| Lint                                     | `npm run lint`             |
+| Type-check Vona and Zova                 | `npm run tsc`              |
+| Run backend tests                        | `npm run test`             |
+| Run the full E2E suite                   | `npm run test:e2e`         |
+| Rerun E2E tests without reset            | `npm run test:e2e:fast`    |
+| Build required Basic artifacts           | `npm run build`            |
+| Build Basic Admin SSR and REST artifacts | `npm run build:zova:admin` |
+| Build Basic Web SSR and REST artifacts   | `npm run build:zova:web`   |
+| Synchronize Zova dependencies into Vona  | `npm run deps:vona`        |
+| Build the public documentation site      | `npm run docs:build`       |
+
+The tracked pre-commit hook runs `lint-staged`. It may format staged Markdown and configuration files, and may lint-fix and format staged source files. Review the resulting staged changes and run the relevant explicit checks before submitting.
+
+## Generated code and Vona–Zova integration
+
+Use Vona backend contracts, DTOs, OpenAPI metadata, and schema metadata as contract truth. Regenerate consumers rather than hand-editing generated frontend artifacts.
+
+For frontend metadata or dependency changes that Vona consumes, build every affected Basic flavor before synchronizing dependencies:
+
+```bash
+npm run build:zova:admin
+# Also run npm run build:zova:web when Web is affected.
+npm run deps:vona
+```
+
+Keep SSR and REST outputs aligned; a REST-only build is not sufficient. See the canonical [Contract Loop Playbook](https://cabloy.com/fullstack/contract-loop-playbook), [Vona + Zova Integration](https://cabloy.com/fullstack/vona-zova-integration), and [repository scripts reference](https://cabloy.com/reference/repo-scripts).
+
+## Pull requests
+
+Keep each pull request focused and describe its user-visible and technical effects. Include:
+
+- the related issue when one exists;
+- tests added or updated for behavioral changes;
+- the exact validation commands run and their results;
+- any regenerated contract artifacts and the build/synchronization steps used; and
+- documentation updates, or why no documentation update is needed.
+
+Do not include unrelated generated output, build artifacts, environment files, credentials, or cache files.
+
+## Documentation
+
+Canonical public Cabloy documentation is maintained in this repository's `repo-docs/` tree and published at [cabloy.com](https://cabloy.com). Discuss and submit proposed public-documentation changes in an issue or pull request; do not treat copies outside this repository as independent canonical sources.
+
+## License and contribution rights
+
+Cabloy Basic project-owned content is licensed under the root [MIT License](./LICENSE).
+
+Submit only material that you have the right to contribute. Preserve required copyright, license, attribution, and third-party notices for any included code, media, fonts, generated material, or copied snippets.

package/LICENSES.md

@@ -0,0 +1,5 @@
+# License Scope
+
+Unless a file or directory includes its own complete license or third-party notice, Cabloy Basic project-owned source, documentation, and assets inherit the root [MIT License](./LICENSE).
+
+Third-party material remains subject to the license and notice provided with that material or otherwise required by its upstream terms.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "cabloy",
-  "version": "5.1.157",
+  "version": "5.1.159",
   "gitHead": "2c5c19284bab738e492856189acb6fad74b8a7b7",
   "description": "A Node.js fullstack framework",
   "keywords": [
@@ -47,6 +47,7 @@
     "test": "cd vona && npm run test",
     "test:e2e": "node repo-e2e/scripts/runE2e.ts --clean",
     "test:e2e:fast": "node repo-e2e/scripts/runE2e.ts --fast",
+    "test:docs:e2e": "npm run docs:build && playwright test --config repo-e2e/docs/playwright.config.ts",
     "db:reset": "cd vona && npm run db:reset",
     "tsc": "npm run tsc:zova && pnpm --dir vona run tsc",
     "tsc:zova": "pnpm --dir zova run tsc",

package/repo-docs/.vitepress/config.mjs

@@ -97,6 +97,7 @@ const fullstackGroups = [
       },
       { text: 'Framework Performance', link: '/fullstack/framework-performance' },
       { text: 'Vona + Zova Integration', link: '/fullstack/vona-zova-integration' },
+      { text: 'SSR Site and Flavor Setup', link: '/fullstack/ssr-site-and-flavor-setup' },
       { text: 'A-Pay Payment Suite', link: '/fullstack/a-pay-payment-suite' },
       {
         text: 'Payment Provider Sandbox Configuration',
@@ -191,19 +192,49 @@ export default defineConfig({
   base: '/',
   ignoreDeadLinks: [/^https?:\/\/localhost/],
   head: gaHead,
+  transformPageData(pageData) {
+    if (!/^blogs\/[^/]+\/index\.md$/.test(pageData.relativePath)) return;
+
+    const pageClass = [pageData.frontmatter.pageClass, 'cabloy-blogs-article']
+      .filter(Boolean)
+      .join(' ');
+    return {
+      frontmatter: {
+        ...pageData.frontmatter,
+        pageClass,
+      },
+    };
+  },
   markdown: {
     lineNumbers: true,
   },
   themeConfig: {
     nav: [
       { text: 'Home', link: '/' },
+      {
+        text: 'Docs',
+        items: [
+          { text: 'Fullstack', link: '/fullstack/introduction', activeMatch: '^/fullstack/' },
+          { text: 'Backend (Vona)', link: '/backend/introduction', activeMatch: '^/backend/' },
+          { text: 'Frontend (Zova)', link: '/frontend/introduction', activeMatch: '^/frontend/' },
+        ],
+      },
       { text: 'Blogs', link: '/blogs/', activeMatch: '^/blogs/' },
-      { text: 'Fullstack', link: '/fullstack/introduction', activeMatch: '^/fullstack/' },
-      { text: 'Backend (Vona)', link: '/backend/introduction', activeMatch: '^/backend/' },
-      { text: 'Frontend (Zova)', link: '/frontend/introduction', activeMatch: '^/frontend/' },
       { text: 'Editions', link: '/editions/overview', activeMatch: '^/editions/' },
       { text: 'AI Development', link: '/ai/introduction', activeMatch: '^/ai/' },
       { text: 'Reference', link: '/reference/introduction', activeMatch: '^/reference/' },
+      {
+        component: 'GitHubRepositoriesNav',
+        props: {
+          repositories: [
+            { text: 'github.com/cabloy/cabloy', link: 'https://github.com/cabloy/cabloy' },
+            {
+              text: 'github.com/cabloy/cabloy-start',
+              link: 'https://github.com/cabloy/cabloy-start',
+            },
+          ],
+        },
+      },
     ],
     sidebar: {
       '/fullstack/': fullstackGroups,
@@ -634,7 +665,6 @@ export default defineConfig({
       ],
       '/reference/': referenceGroups,
     },
-    socialLinks: [{ icon: 'github', link: 'https://github.com/cabloy/cabloy' }],
     search: {
       provider: 'local',
     },