cabloy 5.1.203 → 5.1.205

package/repo-docs/blogs/ai-coding-one-prompt-crud-ssr-multitasking/index.md

@@ -0,0 +1,216 @@
+---
+title: 'AI Coding in Action: One Prompt for CRUD, SSR & Multitasking'
+titleZh: AI 编码实战：一句提示词，实现 CRUD、SSR 与多任务
+titleEn: 'AI Coding in Action: One Prompt for CRUD, SSR & Multitasking'
+subtitle: A hands-on book management walkthrough, from AI-assisted development to using the Admin interface in CabloyJS.
+summary: Give Codex one prompt to create a standalone Book CRUD module in CabloyJS. Then start the servers, open the Admin interface, create a record, refresh the list, and switch between edit, detail, and draft tasks. This walkthrough gives you a practical feel for developing with CabloyJS and using the resulting feature.
+tags:
+  - AI Coding
+  - Codex
+  - CabloyJS
+  - Vona
+  - Zova
+  - CRUD
+  - SSR
+  - Multitasking
+slug: ai-coding-one-prompt-crud-ssr-multitasking-en
+cover: ./cover-en-v1.png
+date: 2026-10-09
+---
+
+# AI Coding in Action: One Prompt for CRUD, SSR & Multitasking
+
+If you ask AI to build a book management feature, what do you expect to get back?
+
+A set of APIs and a few source files—or an Admin page you can open in a browser and actually use?
+
+Let's try it in **CabloyJS**. We'll give Codex one prompt to develop and test a Book CRUD module. Then we'll start the servers, open the Admin interface, create a book, and keep edit, detail, and create tasks open at the same time.
+
+You'll see more than how AI writes code. You'll get a feel for the finished feature: **what happens when you refresh the list, how you switch between tasks, and whether an unsubmitted form keeps its input.**
+
+## 1. Start with One Prompt
+
+Open Codex in an existing, configured CabloyJS project and enter:
+
+```text
+Create a standalone demo-book module to implement CRUD operations for books.
+```
+
+This gives Codex two clear goals:
+
+- Create a standalone `demo-book` module.
+- Implement CRUD—create, read, update, and delete—for books.
+
+We're using a Cabloy Basic project, with **Vona** on the backend and **Zova** on the frontend. The project already has a module structure, development commands, and an Admin interface. Our job is to add a business feature on top of that foundation.
+
+The prompt doesn't need to specify every controller, data model, form component, or page layout. Codex first reads the project conventions, examines the existing structure and tools, and follows the project's development workflow.
+
+### What Does AI Actually Do?
+
+For this feature, Codex's work follows four steps:
+
+```text
+Understand the project → Run the CRUD generator → Refine fields and integration → Run tests and checks
+```
+
+It examines the project and generator commands, then uses Vona's CRUD generator to create the module. Next, it refines the book fields, validation, menu integration, and supporting code so the resource becomes available in the existing Admin interface.
+
+The resulting book form has three fields:
+
+| Field       | Purpose          | Requirement |
+| ----------- | ---------------- | ----------- |
+| Title       | Book title       | Required    |
+| Author      | Book author      | Required    |
+| Description | Book description | Optional    |
+
+One useful part of the development experience is immediately apparent: **once the business resource is defined, the list, detail view, and forms can reuse CabloyJS's existing schema-driven CRUD pages. There is no need to build a new management interface from scratch.**
+
+AI adds the business module; the framework supplies the reusable capabilities. Together, they let you focus on the fields and operations a book needs rather than rebuilding page structures and basic interactions for every resource.
+
+## 2. Development Includes Tests
+
+After creating the module, Codex continues with tests, TypeScript checks, linting, and formatting checks.
+
+This development task took **13 minutes and 57 seconds**. Codex's completion summary reports:
+
+- All five Book module tests passed.
+- The backend test suite had 269 passed, ten skipped, and zero failed.
+- TypeScript, lint, and formatting checks passed.
+
+![Codex's completion summary, including task duration, implemented capabilities, and test results](./images/completion-summary.jpg)
+
+The implemented capabilities include create, paginated listing, detail viewing, update, delete, and transactional bulk deletion.
+
+At this point, a single business request has led to a module implementation and automated checks. Now let's start the servers and see what the feature feels like in the interface.
+
+## 3. Two Commands to Open Book Management
+
+In the project root, open the first terminal and start the backend development server:
+
+```bash
+npm run dev
+```
+
+Open a second terminal and start the Admin frontend development server:
+
+```bash
+npm run dev:zova:admin
+```
+
+Once the servers are ready, open the Admin interface and select **Book** from the menu on the left.
+
+The book list is already part of the existing Admin layout: the management menu on the left, search filters and records in the main area, and page navigation above. Creating, searching, and working with records all happen in the same interface.
+
+That's the first tangible result of adding the module: **you haven't just gained source files. You have a new business feature you can open and use.**
+
+### Refresh the List and Experience SSR
+
+The book list supports SSR, or server-side rendering.
+
+Refresh the browser while on the list page. The layout shows no obvious flicker during the refresh and retains the familiar Admin structure.
+
+![The book list, with search filters, a records area, and the management menu](./images/ssr-refresh.jpg)
+
+For someone using the application, the first impression is not the implementation details of SSR—it's how the page appears when opened or refreshed. For the developer, the Book module is now part of CabloyJS's SSR-enabled Admin interface, without having to build an SSR mechanism specifically for this CRUD feature.
+
+## 4. Create a Book: From Form to List
+
+Click **Create** to open the book form and enter:
+
+```text
+Title: Book One
+Author: Kevin
+```
+
+Description is optional, so leave it empty for now and click **Submit**.
+
+Back in the list, you'll see Book One with Kevin as its author.
+
+It's a simple operation, but it brings the frontend and backend together: open a form, enter the fields, submit the data, and see the result in the list. The module AI just created can now carry out a real business operation.
+
+Next, instead of finishing with this book, let's keep working with it as an open task.
+
+## 5. Keep Three Tasks Open Without Losing Input
+
+In an Admin application, it's common to start editing a record and then need to check its details. Or perhaps you've begun filling out a new form but need to deal with something else before submitting it.
+
+If leaving the page means reopening it—or entering everything again—your work gets interrupted.
+
+CabloyJS's Admin interface provides a second row of task tabs. Let's use Book One and Book Two to see how they work.
+
+### Open Book One for Editing
+
+From the list, open Book One's edit page. Its title and author are already filled in.
+
+Now return to the book list. Look at the tabs above: **Book One's edit task is still open.** Returning to the list doesn't mean you have to close the edit page.
+
+### Open Book One's Details as Another Task
+
+Next, open Book One's detail page from the list.
+
+You now have two tasks for the same book: one for editing and one for viewing details. You can choose whichever you need without going back to the list and finding the record each time.
+
+### Start Book Two, but Don't Submit It
+
+Return to the list, click Create, and enter a second book:
+
+```text
+Title: Book Two
+Author: Tom
+```
+
+Don't submit this time. Leave the form as a draft.
+
+The task tabs now contain three open tasks:
+
+| Task   | Content                     |
+| ------ | --------------------------- |
+| Edit   | Book One's edit form        |
+| Detail | Book One's detail view      |
+| Create | Book Two's unsubmitted form |
+
+### Switch Back and Continue Where You Left Off
+
+Switch to Book One's edit task, then its detail task, and finally back to Book Two's create task.
+
+The title is still `Book Two`, and the author is still `Tom`. The edit and detail tasks also remain open, so you can continue switching among all three.
+
+![Returning to Book Two's create task: the title and author are preserved, with all three task tabs still open above](./images/multitasking-draft.jpg)
+
+**Book Two hasn't been submitted, but switching tasks hasn't lost the input.**
+
+That makes the task tabs more than navigation shortcuts. Each task keeps its current working context. You can check another piece of information and then return to finish the form, without submitting early just to leave the page or retyping everything when you come back.
+
+The experience feels closer to multitasking in a desktop application: several pieces of work can stay open together, rather than forcing you to finish one before moving to the next.
+
+## 6. A Practical Introduction to Developing with CabloyJS
+
+Looking back, we started with just one business request:
+
+```text
+Create a standalone demo-book module to implement CRUD operations for books.
+```
+
+AI developed and checked the module. After starting the servers, we could open the book list, create a record, and use the SSR-enabled pages and task tabs.
+
+This walkthrough gives you a direct feel for several aspects of CabloyJS:
+
+- **Modular development:** the new Book feature is organized as a standalone `demo-book` module.
+- **AI working with existing tools:** AI examines the project and uses its generators and commands instead of introducing a separate implementation approach.
+- **Schema-driven management pages:** business fields become part of the list, detail view, and forms, with reusable page capabilities.
+- **SSR page experience:** the new resource joins the existing SSR-enabled Admin interface.
+- **Multitasking:** edit, detail, and create tasks stay open together, preserving form input when you switch.
+
+CRUD is the business feature at the center of the walkthrough. SSR and multitasking show what it's like to use that feature inside an actual Admin application.
+
+These aren't infrastructure capabilities AI has rewritten from scratch. They are capabilities CabloyJS already provides. **AI develops the business feature within the framework, and the new feature benefits from the framework's existing pages and interactions.**
+
+## Give AI a Request, Get a Feature You Can Use
+
+If you'd like to explore CabloyJS, a small feature like this is a good place to start.
+
+Give AI a clear request. See how it creates the module, refines the fields, and runs checks. Then open the browser, create a record yourself, refresh the list, and keep a few tasks open at once.
+
+Moving from “What code did it generate?” to “What does this feature feel like to use?” turns modules, schemas, and SSR from abstract terms into a concrete development and application experience.
+
+**That's the point of hands-on AI coding: turn a request into a feature you can operate, and make the framework's capabilities something you can see and use.**

package/repo-docs/blogs/index.md

@@ -9,6 +9,21 @@ aside: false
 Selected articles on Cabloy, Vona, Zova, and the architectural questions that shape full-stack applications.
 
 <div class="cabloy-blog-grid">
+  <article class="cabloy-blog-card">
+    <a class="cabloy-blog-card__cover" href="/blogs/ai-coding-one-prompt-crud-ssr-multitasking/" aria-label="Read AI Coding in Action: One Prompt for CRUD, SSR &amp; Multitasking">
+      <img src="/blogs/ai-coding-one-prompt-crud-ssr-multitasking/cover-en-v1.png" alt="AI Coding in Action: One Prompt for CRUD, SSR &amp; Multitasking" />
+    </a>
+    <div class="cabloy-blog-card__content">
+      <p class="cabloy-blog-card__date">October 9, 2026</p>
+      <h2><a href="/blogs/ai-coding-one-prompt-crud-ssr-multitasking/">AI Coding in Action: One Prompt for CRUD, SSR &amp; Multitasking</a></h2>
+      <p>Follow one prompt from AI-assisted Book CRUD development to a working CabloyJS Admin interface, SSR refresh, and task switching that preserves form input.</p>
+      <div class="cabloy-blog-card__tags" aria-label="Article topics">
+        <span>AI Coding</span><span>CabloyJS</span><span>SSR</span><span>Multitasking</span>
+      </div>
+      <a class="cabloy-blog-card__read" href="/blogs/ai-coding-one-prompt-crud-ssr-multitasking/">Read article <span aria-hidden="true">→</span></a>
+    </div>
+  </article>
+
   <article class="cabloy-blog-card">
     <a class="cabloy-blog-card__cover" href="/blogs/ai-spec-driven-development/" aria-label="Read CabloyJS AI Spec-Driven Development Automatically Generates Gantt and Burndown Charts">
       <img src="/blogs/ai-spec-driven-development/cover-en-v1.png" alt="CabloyJS AI Spec-Driven Development Automatically Generates Gantt and Burndown Charts" />

package/repo-docs/frontend/scripts.md

@@ -51,7 +51,7 @@ The `dev:zova:*` commands start the Zova development server, which uses `9000` i
 
 ## Vona integrated SSR browser acceptance
 
-The default Basic Web and Admin sites have browser smoke commands that exercise Vona integrated SSR through Vona SSR dispatch at port `7102`, not through the Zova standalone SSR development-server port.
+The default Basic Web and Admin sites have browser smoke commands that exercise Vona integrated SSR through Vona SSR dispatch at the managed run's dynamically allocated test listener, not through the ordinary Vona development listener (`7102` by default) or the Zova standalone SSR development-server port. Vona supplies the API origin at runtime, so no Zova `.env` change or rebuild is needed solely for the test port; see [Runtime API origins in Vona integrated SSR](/fullstack/ssr-entry-modes#runtime-api-origins-in-vona-integrated-ssr).
 
 Prepare current SSR and REST artifacts explicitly when frontend output has changed:
 

package/repo-docs/fullstack/parallel-worktree-environment.md

@@ -1,10 +1,10 @@
 # Parallel Worktree Environment
 
-Use worktree-local environment overrides when two Cabloy Basic or Cabloy Start worktrees need to run ordinary local development or managed E2E checks at the same time.
+Use worktree-local environment overrides when two Cabloy Basic or Cabloy Start worktrees need to run ordinary local development at the same time. In Cabloy Basic, root `npm run test` and `npm run test:e2e` already isolate their test-mode runtime and data on every run, including alongside ordinary dev in the **same** checkout; they do not require this worktree setup for that purpose.
 
-This Cabloy Basic page is the canonical shared recipe for both editions. Detect the active edition before selecting commands, but keep the same two-file environment model.
+This Cabloy Basic page is the canonical shared recipe for both editions. Detect the active edition before selecting commands, but keep the same two-file environment model for worktree-local development.
 
-This workflow creates a standard isolated local runtime without changing committed environment defaults. It does not automatically isolate every external dependency.
+This workflow creates a standard isolated local development runtime without changing committed environment defaults. It does not automatically isolate every external dependency.
 
 ## Before creating local overrides
 
@@ -82,13 +82,13 @@ Use commands from the active repository root.
 | Cabloy Basic | `__CABLOY_BASIC__` | `npm run dev:zova:admin` or `npm run dev:zova:web` | `npm run test:e2e` |
 | Cabloy Start | `__CABLOY_START__` | `npm run dev:zova:admin` or `npm run dev:zova:web` | `npm run test:e2e` |
 
-Run one frontend command, not both, in each worktree. Both managed E2E workflows read Vona's effective local `SERVER_LISTEN_PORT` and start one fresh Vona test-mode worker; startup initializes test resources without a separate reset. Before either command, confirm exclusive ownership of the effective test database, `_local` Redis namespace, public/runtime paths, `APP_NAME`, API origin, and listener. A free port alone does not establish ownership. Do not change shared identity or ports to bypass a collision, and leave `E2E_BASE_URL` unset: externally managed targets are unsupported.
+Run one frontend command, not both, in each worktree. In Cabloy Basic, root `npm run test` and `npm run test:e2e` allocate a fresh run-specific identity, test database and Redis namespace, generated/runtime/public paths, and loopback listener independently of the worktree's development environment. Managed E2E starts a fresh Vona test-mode worker, and startup initializes test resources and module seeds without a separate dev-mode reset. This also isolates tests from a dev process in the same checkout. Cabloy Start's managed E2E uses the effective local test-mode Vona listener and its own ownership rules; inspect its root scripts before relying on Basic's isolation. Leave `E2E_BASE_URL` unset: externally managed targets are unsupported. Do not change shared identity or ports merely to bypass a busy development resource.
 
 ## What this isolates
 
-A unique `APP_NAME` separates the application identity used by ordinary framework-managed local resources, including managed test database names and Redis-related key prefixes. Worktree-local generated files, runtime files, build output, and coverage output are already separated by their worktree paths.
+A unique worktree `APP_NAME` separates the identity of ordinary development resources across worktrees, including framework-managed development database names and Redis-related key prefixes. Worktree-local generated files, runtime files, build output, and coverage output are already separated by their worktree paths. Cabloy Basic root tests use a separate run-specific identity even when invoked inside a worktree; they do not clean its ordinary development business data.
 
-The generated Vona, Zova development HTTP, and Zova HMR ports let worktrees run their ordinary local processes concurrently. The matching Zova API URL prevents the frontend in one worktree from calling the Vona process in another.
+The generated Vona, Zova development HTTP, and Zova HMR ports let worktrees run their ordinary local processes concurrently. The matching Zova API URL prevents the frontend in one worktree from calling the Vona process in another. Builds, dependency generation, and other shared preparation writes remain accepted prerequisites rather than part of test data cleanup.
 
 This is sufficient for the normal local workflows:
 

package/repo-docs/fullstack/ssr-entry-modes.md

@@ -15,6 +15,25 @@ Zova standalone SSR:    browser → Zova development server → frontend SSR →
 
 In the Cabloy Basic default environment, `SERVER_LISTEN_PORT=7102` is the Vona entry and `DEV_SERVER_PORT=9000` is the Zova development entry. These are separate listeners, not two ports for the same server. Zova's `API_BASE_URL` points to Vona, not to its own development port. Local environment overrides can change the ports; use the effective values in your checkout.
 
+## Runtime API origins in Vona integrated SSR
+
+Vona integrated SSR supplies API origins at runtime; this mechanism is not specific to an edition or frontend flavor. By default, Vona derives the origin from its effective protocol and host and passes:
+
+- `envServer.SSR_API_BASE_URL` to the built Zova server bundle during initialization.
+- `envClient.API_BASE_URL` through the SSR state to the browser during client initialization.
+
+These runtime values override Zova's build-time environment defaults used by the normal API client. They do not rewrite hard-coded URLs or arbitrary build-time substitutions in application code.
+
+For an isolated `npm run test:e2e` that enters through Vona integrated SSR, the runner's dynamic Vona origin is therefore sufficient: **do not edit Zova `.env` files or rebuild the flavor solely to match the test port**. A new listener address alone does not make the bundle stale.
+
+Artifact preparation is a separate concern. When frontend code, routes, metadata, or other build inputs change, refresh the required SSR/REST artifacts and synchronize Vona dependencies as required. Resolve commands and flavors from the active repository's scripts; do not assume every edition's E2E command builds the frontend automatically. See [SSR Build and Deploy Guide](/frontend/ssr-build-deploy-guide) and [Repo Scripts](/reference/repo-scripts).
+
+The injected origins are defaults, with these boundaries:
+
+- Vona merges the default origins first, then the `a-ssr` module's `site.default` configuration, then the individual SSR Site options. An explicit `envServer.SSR_API_BASE_URL` or `envClient.API_BASE_URL` in those site settings overrides the corresponding default; a value only in Zova's build-time `.env` does not count as a site override.
+- Generated OpenAPI clients prefer their module-specific `OPENAPI_BASE_URL_*`, then `OPENAPI_BASE_URL_DEFAULT`, before the server or browser API-origin fallback. Custom API configuration and hard-coded URLs also require separate inspection when requests reach the wrong origin.
+- Zova standalone SSR and SPA do not automatically receive this Vona integrated SSR handoff. Keep their environment setup separate from this rule, including deliberate [parallel worktree development configuration](/fullstack/parallel-worktree-environment).
+
 ## Start and use them in Cabloy Basic
 
 Start the Vona server from the repository root and visit a Vona-served site:

package/repo-docs/index.md

@@ -36,6 +36,8 @@ features:
 
 [![CabloyJS AI CRUD video](./assets/img/cabloy-ai-crud-cover-en.png)](https://youtu.be/PV9_By08hDM)
 
+[Read the hands-on walkthrough: AI Coding in Action — One Prompt for CRUD, SSR & Multitasking](/blogs/ai-coding-one-prompt-crud-ssr-multitasking/)
+
 ## Choose a reading path
 
 ### Start a project

package/repo-docs/reference/repo-scripts.md

@@ -41,6 +41,7 @@ Cabloy Basic exposes these shared root scripts:
 - `npm run start:one`
 - `npm run test`
 - `npm run test:e2e`
+- `npm run db:reset`
 - `npm run tsc`
 - `npm run docs:dev`
 - `npm run docs:build`
@@ -48,6 +49,26 @@ Cabloy Basic exposes these shared root scripts:
 
 `npm run init` prepares all Cabloy Basic SSR and REST artifacts with `npm run build:zova:all`, which sequentially builds the Basic and Commerce flavor batches before Vona initialization. Use `build:zova` or `build:zova:commerce` for focused artifact refreshes; use `build:zova:all` only when every shipped Basic flavor must be prepared.
 
+## Test isolation and development data in Cabloy Basic
+
+Root `npm run test` delegates to Vona's `npm run test`; both it and direct `cd vona && npm run test` use the same isolated runner. Vona's `npm run cov` also uses that runner and enables coverage. Root `npm run test:e2e` retains its own isolated E2E entrypoint. Each command launches a new test-mode run, even in the same checkout as a running development server. The runner chooses a UTC `YYYYMMDDHHmmss` timestamp plus eight lowercase cryptographically random hexadecimal characters for one run ID (for example, `20261014010203-a1b2c3d4`). This ID names both owned Vona directories (`.app-test-<id>` and `.vona-test-<id>`) and the disposable database and Redis namespaces; the runner also allocates a loopback listener. The runner exclusively creates an ignored JSON claim at `vona/.vona-test-claim/<id>.json` before allocating resources. A rare claim or directory collision fails without adopting or deleting the existing paths; rerun the command. Independent checkouts sharing database or Redis services do not share these claims, so their random suffixes reduce, but cannot eliminate, cross-checkout collisions.
+
+Claims contain a versioned, nonsecret resource inventory: owned local roots, exact database allocation intents, Redis namespaces and endpoint identities, process ownership, and cleanup progress. Allocators must receive an acknowledgment that their intent is recorded before creating a database or using framework-managed Redis resources. Credentials, full environment/configuration snapshots, and readiness secrets are not stored in claims.
+
+Successful unit, coverage, and managed application E2E runs release inventoried database and Redis resources and remove their owned local roots after process shutdown is verified. Managed E2E uses a registered browser fixture to verify detached browser-group shutdown; its run-owned reports, traces, and temporary profiles are deleted on success too. The claim is deleted last. Failed or interrupted runs retain their claim and resources for inspection. Cleanup failure also makes the command fail and retains the journal for retry.
+
+Before each new invocation, the runner checks retained claims against their immutable UTC creation timestamp. Claims older than one day are eligible for cleanup; set `VONA_TEST_CLAIM_TTL_SECONDS` to a positive integer to change the default `86400` seconds. Eligibility is not permission to delete a live or unowned resource: the runner retains malformed claims, mismatched owner markers, symlinked paths, changed service endpoints, live or uncertain process identities, incomplete launch registrations, and claims with an existing cleanup lock. Inspect these warnings manually; a lock is never taken over merely because it is old. Cleanup resolves current trusted configuration without starting the application, running seeds, or opening a listener. It drops only recorded database names and scans only exact recorded Redis prefixes, never flushing Redis. Partial progress is journaled so a later eligible cleanup can retry safely. Legacy `.vona-test-claim-<id>` directories and inventory-less run roots are not automatically migrated or deleted.
+
+All three commands initialize test databases and run module `seed()` hooks; none resets the ordinary dev-mode database or deletes its business data. A narrow test selection still initializes the test environment. Raw `:bin:test` invocations bypass the public scripts and do not get the runner's isolation guarantee.
+
+Coverage reports (`vona/coverage/lcov.info` and, without `--ci`, `vona/coverage/report`) are shared checkout-level artifacts, not run-owned data. Avoid overlapping coverage runs or relying on these reports as independent per-run output.
+
+Builds, generated artifacts, dependency installation/generation, and other shared preparation writes remain accepted prerequisites when needed. Test isolation does not make those writes private or authorize an unrelated reset of development data. The run-specific identity namespaces framework-managed resources; separately configured external databases, Redis targets or unprefixed custom keys, and third-party providers still require deliberate ownership and isolation. Inspect the active edition's scripts rather than assuming Cabloy Start already uses the same root runner.
+
+For Vona integrated SSR, the allocated E2E origin is supplied to Zova at runtime as server `SSR_API_BASE_URL` and browser `API_BASE_URL`. Do not edit Zova `.env` files or rebuild solely to match the test port. The current root `npm run test:e2e` consumes prebuilt frontend artifacts; refresh affected SSR/REST output and synchronize dependencies when their inputs change. See [Runtime API origins in Vona integrated SSR](/fullstack/ssr-entry-modes#runtime-api-origins-in-vona-integrated-ssr) for configuration overrides and scope.
+
+For a deliberate **dev-mode** database recreation, `npm run db:reset` is a separate, destructive command: it drops matching disposable development databases, reruns migrations and instance initialization, then runs module `seed()` hooks. It requires `database.testDatabase: true` in the dev configuration and a connection outside the disposable database. Ordinary `npm run dev` does not seed or reset; never run `db:reset` against development data you need to retain. Upgrades no longer initialize development test data automatically. See [Migration and Changes](/backend/migration-and-changes#local-development-workflow).
+
 ## Specification planning and derived charts
 
 The current Cabloy Basic root scripts also expose:
@@ -151,7 +172,7 @@ The public-package upgrade flow does not source or reconcile the Start-owned bas
 
 ## SSR browser checks
 
-Cabloy Basic and Cabloy Start each use a single managed local `npm run test:e2e` command. In Basic, the runner checks the effective `normal/test/local` Vona listener port and starts one fresh `--workers=1 --flavor=normal --mode=test` worker. Test-mode startup initializes test resources; the runner does not invoke a separate `db:reset` or a development-mode server. Playwright does not reuse an existing process. Confirm exclusive ownership of the effective test database, `_local` Redis namespace, public/runtime paths, `APP_NAME`, API origin, and listener before starting it; port availability alone is insufficient.
+Cabloy Basic and Cabloy Start each use a managed local `npm run test:e2e` command. In Basic, the root wrapper allocates a run-specific test identity, disposable database and Redis namespaces, Vona generated/runtime/public paths, and an available loopback port, then starts a fresh `--workers=1 --flavor=normal --mode=test` worker. Test-mode startup initializes test resources and invokes module seeds without a separate dev-mode `db:reset`; Playwright does not reuse an existing process. This protects ordinary same-checkout development data and permits a Basic root E2E run alongside a dev server, subject to the shared-preparation and external-resource boundaries above. Inspect the Start repository's current scripts for its own resource-ownership rules.
 
 Both editions' browser checks target Vona integrated SSR. In the Cabloy Basic default environment, the Vona listener is `7102`; the Zova standalone SSR development server uses `9000` and is not an acceptance target.
 

package/repo-e2e/config/playwright.config.ts

@@ -4,26 +4,44 @@ import { E2E_LOCAL_BASE_URL, E2E_ROOT_DIR } from '../scripts/e2e.ts';
 
 export default defineConfig({
   testDir: `${E2E_ROOT_DIR}/repo-e2e/specs`,
+  outputDir: process.env.VONA_TEST_RUN_ID
+    ? `${E2E_ROOT_DIR}/vona/.app-test-${process.env.VONA_TEST_RUN_ID}/test-results`
+    : `${E2E_ROOT_DIR}/repo-e2e/test-results`,
   fullyParallel: false,
   workers: 1,
   forbidOnly: !!process.env.CI,
   retries: process.env.CI ? 2 : 0,
-  reporter: process.env.CI ? [['html', { open: 'never' }], ['list']] : 'list',
+  reporter: process.env.CI
+    ? [
+        [
+          'html',
+          {
+            open: 'never',
+            outputFolder: process.env.VONA_TEST_RUN_ID
+              ? `${E2E_ROOT_DIR}/vona/.app-test-${process.env.VONA_TEST_RUN_ID}/playwright-report`
+              : `${E2E_ROOT_DIR}/repo-e2e/playwright-report`,
+          },
+        ],
+        ['list'],
+      ]
+    : 'list',
   use: {
     baseURL: E2E_LOCAL_BASE_URL,
     trace: 'on-first-retry',
   },
-  webServer: {
-    command: 'node repo-e2e/scripts/startE2eVona.ts',
-    cwd: E2E_ROOT_DIR,
-    url: `${E2E_LOCAL_BASE_URL}/health/ready`,
-    timeout: 180_000,
-    reuseExistingServer: false,
-    stdout: 'pipe',
-    stderr: 'pipe',
-    gracefulShutdown: {
-      signal: 'SIGINT',
-      timeout: 10_000,
-    },
-  },
+  webServer: process.env.VONA_TEST_RUN_ID
+    ? undefined
+    : {
+        command: 'node repo-e2e/scripts/startE2eVona.ts',
+        cwd: E2E_ROOT_DIR,
+        url: `${E2E_LOCAL_BASE_URL}/health/ready`,
+        timeout: 180_000,
+        reuseExistingServer: false,
+        stdout: 'pipe',
+        stderr: 'pipe',
+        gracefulShutdown: {
+          signal: 'SIGINT',
+          timeout: 10_000,
+        },
+      },
 });

package/repo-e2e/docs/specs/blogs-index.spec.ts

@@ -25,6 +25,7 @@ interface IArticleGeometry {
 }
 
 const blogArticlePaths = [
+  '/blogs/ai-coding-one-prompt-crud-ssr-multitasking/',
   '/blogs/ai-spec-driven-development/',
   '/blogs/ai-react-nextjs-enterprise-architecture-cabloy/',
   '/blogs/cabloy-fullstack-resource-addressing/',
@@ -119,26 +120,26 @@ test(
     await expect(page.locator('.VPDoc.has-aside')).toHaveCount(0);
 
     const cards = page.locator('.cabloy-blog-card');
-    await expect(cards).toHaveCount(5);
-    for (let index = 0; index < 5; index++) {
+    await expect(cards).toHaveCount(blogArticlePaths.length);
+    for (let index = 0; index < blogArticlePaths.length; index++) {
       await expect(cards.nth(index)).toBeVisible();
       await expect(cards.nth(index).locator('.cabloy-blog-card__cover img')).toBeVisible();
     }
     await expect(
       cards.nth(0).getByRole('link', {
-        name: 'CabloyJS AI Spec-Driven Development Automatically Generates Gantt and Burndown Charts',
+        name: 'AI Coding in Action: One Prompt for CRUD, SSR & Multitasking',
         exact: true,
       }),
     ).toBeVisible();
-    await expect(cards.nth(0).locator('.cabloy-blog-card__date')).toHaveText('September 11, 2026');
+    await expect(cards.nth(0).locator('.cabloy-blog-card__date')).toHaveText('October 9, 2026');
     await expect(cards.nth(0).locator('.cabloy-blog-card__cover')).toHaveAttribute(
       'href',
-      '/blogs/ai-spec-driven-development/',
+      '/blogs/ai-coding-one-prompt-crud-ssr-multitasking/',
     );
 
     const geometry = await getBlogsGeometry(page);
     expect(geometry.grid.display).toBe('grid');
-    expect(geometry.cards).toHaveLength(5);
+    expect(geometry.cards).toHaveLength(blogArticlePaths.length);
 
     const [firstCard, secondCard, thirdCard, fourthCard, fifthCard] = geometry.cards;
     const firstRow = [firstCard, secondCard, thirdCard, fourthCard];
@@ -181,6 +182,22 @@ test(
       await expect(page.locator('.VPDoc.has-sidebar')).toHaveCount(0);
       await expect(page.locator('.VPDoc.has-aside')).toHaveCount(1);
       await expect(page.locator('.aside')).toBeVisible();
+      if (path === '/blogs/ai-coding-one-prompt-crud-ssr-multitasking/') {
+        await expect(
+          page.getByRole('heading', {
+            name: 'AI Coding in Action: One Prompt for CRUD, SSR & Multitasking',
+            level: 1,
+          }),
+        ).toBeVisible();
+        const images = page.locator('.vp-doc img');
+        await expect(images).toHaveCount(3);
+        for (const image of await images.all()) {
+          await expect(image).toBeVisible();
+          await expect
+            .poll(() => image.evaluate(element => (element as HTMLImageElement).naturalWidth))
+            .toBeGreaterThan(0);
+        }
+      }
       if (path === '/blogs/ai-spec-driven-development/') {
         await expect(
           page.getByRole('heading', {

package/repo-e2e/scripts/e2e.test.ts

@@ -15,3 +15,42 @@ test('rejects a defined E2E_BASE_URL before loading local configuration', () =>
     assert.doesNotMatch(result.stderr, /SERVER_LISTEN_PORT/);
   }
 });
+
+test('isolated E2E target follows the assigned listener', () => {
+  const entrypoint = fileURLToPath(new URL('./e2e.ts', import.meta.url));
+  const result = spawnSync(
+    process.execPath,
+    [
+      '--input-type=module',
+      '-e',
+      `import { E2E_LOCAL_BASE_URL } from ${JSON.stringify(entrypoint)}; console.log(E2E_LOCAL_BASE_URL)`,
+    ],
+    {
+      env: {
+        ...process.env,
+        E2E_BASE_URL: undefined,
+        VONA_TEST_RUN_ID: '20261014010203-a1b2c3d4',
+        APP_NAME: 'cabtest20261014010203-a1b2c3d4',
+        SERVER_LISTEN_PORT: '42321',
+      },
+      encoding: 'utf8',
+    },
+  );
+  assert.equal(result.status, 0, result.stderr);
+  assert.equal(result.stdout.trim(), 'http://127.0.0.1:42321');
+});
+
+test('rejects a malformed isolated E2E run ID', () => {
+  const entrypoint = fileURLToPath(new URL('./e2e.ts', import.meta.url));
+  const result = spawnSync(process.execPath, [entrypoint], {
+    env: {
+      ...process.env,
+      E2E_BASE_URL: undefined,
+      VONA_TEST_RUN_ID: '20260230010203-a1b2c3d4',
+      SERVER_LISTEN_PORT: '42321',
+    },
+    encoding: 'utf8',
+  });
+  assert.notEqual(result.status, 0);
+  assert.match(result.stderr, /Invalid isolated test run ID/);
+});

package/repo-e2e/scripts/e2e.ts

@@ -13,7 +13,25 @@ const vonaEnv = dotenv.loadEnvs(
   resolve(E2E_ROOT_DIR, 'vona', 'env'),
   '.env',
 );
-const e2ePort = Number(vonaEnv?.SERVER_LISTEN_PORT);
+const runId = process.env.VONA_TEST_RUN_ID;
+if (runId) {
+  const match = /^(\d{14})-[a-f0-9]{8}$/.exec(runId);
+  const timestamp = match?.[1];
+  const date = timestamp
+    ? new Date(
+        `${timestamp.slice(0, 4)}-${timestamp.slice(4, 6)}-${timestamp.slice(6, 8)}T${timestamp.slice(8, 10)}:${timestamp.slice(10, 12)}:${timestamp.slice(12, 14)}Z`,
+      )
+    : undefined;
+  if (
+    !timestamp ||
+    !date ||
+    Number.isNaN(date.getTime()) ||
+    date.toISOString().slice(0, 19).replace(/[-:T]/g, '') !== timestamp
+  ) {
+    throw new Error('Invalid isolated test run ID: expected a UTC timestamp plus eight hex digits');
+  }
+}
+const e2ePort = Number(runId ? process.env.SERVER_LISTEN_PORT : vonaEnv?.SERVER_LISTEN_PORT);
 if (!Number.isInteger(e2ePort) || e2ePort <= 0 || e2ePort > 65535) {
   throw new Error('Missing or invalid SERVER_LISTEN_PORT for local E2E target');
 }