cabloy 5.1.136 → 5.1.138

package/cabloy-docs/frontend/model-resource-owner-pattern.md

@@ -99,12 +99,13 @@ export class ModelResource<
   Entity = any,
   EntityCreate = Partial<Entity>,
   EntityUpdate = Partial<Entity>,
+  EntityDelete = void,
 > extends BeanModelBase {}
 ```
 
 That already tells you something important.
 
-This model is designed to be reused across many resource types rather than tied to one page.
+This model is designed to be reused across many resource types rather than tied to one page. `EntityDelete` defaults to `void`, so standard Resource deletion remains bodyless. A resource-specific model can supply a DELETE request-body type without changing the other three generic positions.
 
 ## Why `enableSelector` is essential
 
@@ -247,6 +248,30 @@ Instead, it builds a reusable mutation layer:
 
 This gives the model one place to enforce mutation-key conventions and invalidation rules.
 
+### DELETE request bodies remain an explicit semantic operation
+
+The default `delete(id)` mutation has no variable and sends the existing bodyless DELETE request:
+
+```typescript
+await modelResource.delete(id).mutateAsync();
+```
+
+When the backend DELETE contract declares a request body, declare the fourth generic in a typed resource facade and pass the body to the mutation:
+
+```typescript
+type DeleteReason = { reason: string };
+
+declare const modelResource: ModelResource<Entity, EntityCreate, EntityUpdate, DeleteReason>;
+
+await modelResource.delete(id).mutateAsync({ reason: 'duplicate' });
+```
+
+`ModelResource` forwards a supplied variable through Axios `config.data`; `null` remains an intentional body, while an omitted variable preserves the bodyless request shape. For a DELETE body that is optional, use `DeleteReason | void`, not `DeleteReason | undefined`, so `mutateAsync()` remains callable without an argument.
+
+The generic Resource table delete command only confirms and executes a bodyless delete. It does not generate a delete form or invent a payload. A resource that needs a required DELETE body must provide a resource-specific action or dialog that collects the value and calls the typed mutation. It should not expose the standard generic delete action for that operation.
+
+The owner also exposes `apiSchemasDelete` lazily for a semantic caller that needs DELETE OpenAPI metadata. Loading that metadata or rendering a delete-body form remains the responsibility of that explicit caller.
+
 That is an important architectural advantage.
 
 Without this model boundary, every page or dialog could invent slightly different invalidation behavior.

package/cabloy-docs/frontend/module-scope.md

@@ -85,6 +85,30 @@ const message2 = this.scope.locale.HelloWorld.locale('en-us');
 
 Project-level locale resources can override module-level locale values, which is one of the key reasons scope stays useful even when the final app wants customized wording.
 
+### Diagnose locale typing at its source
+
+Use `this.scope.locale.SomeKey()` directly. Its type is generated from the module locale source and module metadata; do not add a local type assertion, compatibility helper, or cast merely to silence a missing-key error.
+
+When a locale key is missing or incorrectly typed:
+
+1. Inspect `src/config/locale/` for the module.
+2. If that directory does not exist, initialize it through the standard command:
+
+   ```bash
+   npm run zova :init:locale <module>
+   ```
+
+   The normal initializer path also refreshes module metadata.
+
+3. Add the key to every required locale source file.
+4. If locale sources are complete but `this.scope.locale` is still stale, run the focused metadata refresh:
+
+   ```bash
+   npm run zova :tools:metadata <module>
+   ```
+
+Then return to direct `this.scope.locale.SomeKey()` usage. Repairing the locale source and generated metadata preserves the module contract for every consumer.
+
 ## `error`
 
 Module-specific errors are exposed through scope so business code can throw namespaced error definitions without inventing ad hoc exception patterns.

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

@@ -107,6 +107,27 @@ project
 
 A practical convention from the legacy guidance is that `a-demo` can host demo or disposable exploratory code, while suites such as `a-home` act as the normal starting point for real application growth.
 
+## Import suffixes in Zova modules
+
+Zova application modules are authored in TypeScript and TSX, but their relative ESM
+specifiers name emitted runtime files. In module source, use `.js` for a `.ts` target
+and `.jsx` for a `.tsx` target:
+
+```ts
+import type { ModelStudent } from '../model/student.js';
+import { RenderCard } from './render.card.jsx';
+```
+
+This applies to relative imports, type-only imports, re-exports, module tests, and
+module metadata that imports application code. Bare package imports are unchanged.
+
+The scope is intentionally limited to module packages under `zova/src/module/**`,
+`zova/src/module-vendor/**`, `zova/src/suite/**/modules/**`, and
+`zova/src/suite-vendor/**/modules/**`. Do not copy this convention into
+`zova/packages-utils/**` or `zova/packages-zova/**`: those package sources have
+intentional `.ts`/`.tsx` imports. Do not use a repository-wide replacement across
+Vona, CLI or template source, dependencies, generated output, or build artifacts.
+
 ## Module and suite boundaries in practice
 
 A practical mental model is:
@@ -175,6 +196,7 @@ When editing or creates frontend code, ask:
 1. does this belong in an existing module or a new one?
 2. is this really one feature unit, or should it become part of a suite?
 3. does the naming follow Zova’s module/suite conventions?
-4. will the chosen placement preserve the intended architectural and bundle boundaries?
+4. do relative imports and re-exports use emitted `.js`/`.jsx` suffixes within the affected module, without changing excluded package source?
+5. will the chosen placement preserve the intended architectural and bundle boundaries?
 
 That helps AI keep frontend growth aligned with Zova’s modular system instead of falling back to generic folder expansion.

package/cabloy-docs/frontend/navigation-guards-guide.md

@@ -49,6 +49,8 @@ class ServiceRouterGuards {
 
 `$getPagePathLogin(to.fullPath)` preserves the protected destination as `returnTo` without starting navigation. On the Client, returning that path lets Vue Router redirect the current navigation atomically. On the Server, `$redirect(...)` preserves the SSR HTTP redirect flow.
 
+`requiresAuth` is independent of `ssrProfile`. A route such as Login or password recovery can use `meta: { requiresAuth: false, ssrProfile: 'public' }` for an anonymous, cache-safe, hydration-equivalent contract, or explicitly use `session` when its SSR contract genuinely needs cookie-backed state. The profile does not authenticate the visitor or bypass API authorization.
+
 ## Why route meta matters here
 
 The example makes a key architectural point: navigation guards are tightly coupled to route metadata such as `requiresAuth`.

package/cabloy-docs/frontend/page-params-guide.md

@@ -34,6 +34,8 @@ A page route that declares or consumes dynamic params **must** define `route.nam
 
 The route name is required because Zova uses the named route identity to generate and resolve the page's typed `params` schema at runtime. This initializes the controller's `$params` surface during SSR and client navigation. A params schema declaration alone does not make `$params` available if the route is unnamed.
 
+Conversely, a static route should not add a name merely for typing, canonical URL generation, or alias convenience. Use the path-keyed `$router.getPagePath(...)` helper for a known canonical static path; keep a static name only for a documented named-route requirement.
+
 Representative route idea:
 
 ```typescript

package/cabloy-docs/frontend/page-route-guide.md

@@ -44,6 +44,10 @@ This matters because path generation is modular by default.
 
 A route with dynamic params must define `name`. Typed param-aware routing uses the named route identity to generate and resolve the page's runtime params schema; an unnamed parameterized route does not provide the required `$params` contract.
 
+A static route should normally omit `name`. Do not add a name merely for typing, canonical URL generation, or alias convenience: use the path-keyed `$router.getPagePath(...)` helper for a known static path. Keep a static name only when a documented named-route or public-URL contract genuinely requires it.
+
+For ordinary business routes without a `locale` path parameter, omit app-config aliases by default. A system entry, compatibility URL, or explicitly designed user-facing URL may still opt into an alias; record that exception in the route design rather than treating aliases as routine.
+
 ## `component`
 
 `component` points to the generated page wrapper such as `ZPageCounter`.
@@ -64,6 +68,8 @@ The route meta surface includes important behavior such as:
 - keepAlive behavior
 - SSR profile and nested `meta.ssrProfileOptions.responseCache` behavior
 
+Choose `meta.ssrProfile` from the page's rendering contract. Use `session` when the server needs cookie-backed state, protected admission, personalized first paint, or private SSR data; use `public` for an explicit URL-locale or deliberately locale-neutral, cache-safe, hydration-equivalent public contract. A missing `locale` parameter alone does not determine the profile. This is separate from route admission: use `requiresAuth: false` for an anonymous route, and do not treat either profile as an authentication decision.
+
 This is one reason route records matter so much: they are not just URL declarations. They are an application-behavior surface.
 
 ## Route -> shell -> routed page
@@ -145,9 +151,10 @@ When editing page routing, do not only change the URL string.
 
 It should also check whether the route change affects:
 
-- params typing and the required `route.name` for dynamic params
-- auth behavior
+- params typing and the required `route.name` for dynamic params, plus static-route name omission
+- auth behavior, including whether anonymous admission explicitly requires `requiresAuth: false`
 - layout behavior
 - whether `meta.locale` should participate in URL-locale behavior
-- SSR profile and nested `meta.ssrProfileOptions.responseCache` behavior
+- whether an alias is an explicit system, compatibility, or user-facing URL exception rather than an ordinary business-route default
+- SSR profile and nested `meta.ssrProfileOptions.responseCache` behavior, selected from the page's rendering and cache contract
 - metadata regeneration

package/cabloy-docs/frontend/route-alias-guide.md

@@ -13,6 +13,8 @@ A home-page example shows this clearly:
 
 Route aliases bridge that gap.
 
+Aliases are an explicit public-URL contract, not a default convenience layer. Ordinary business routes without `locale` params should keep their canonical module path and omit an app-config alias. Use an alias when the route is a documented system entry, compatibility path, or intentionally designed user-facing URL; locale-aware public routes are another common exception.
+
 ## Basic routing flow
 
 The navigation flow can be described in terms of:
@@ -45,10 +47,12 @@ config.routes = {
 
 ## `path` vs `name`
 
-The distinction matters:
+The distinction matters after an alias has a documented reason:
+
+- use `routes.path` for an approved static path-based alias;
+- use `routes.name` when the approved alias depends on params-aware naming.
 
-- use `routes.path` for normal path-based aliases
-- use `routes.name` when the route depends on params-aware naming
+Do not introduce a static route name solely to use `routes.name`: a static exception can use `routes.path` instead.
 
 ## Generate a configured alias path
 
@@ -79,10 +83,12 @@ Use `$router.getPagePath(...)` for a known canonical path template, `$router.get
 When changing user-facing routes, ask:
 
 1. is this a real route change or just an alias change?
-2. does the alias belong in global config?
-3. is the page params-aware, meaning the name-based alias path is the correct layer?
+2. does the alias have an explicit system, compatibility, locale-aware, or user-facing URL reason?
+3. does the alias belong in global config?
+4. is the page params-aware, meaning the name-based alias path is the correct layer?
+5. if the route is static, can `getPagePath(...)` and a path-keyed alias preserve the canonical route without adding a name?
 
-That helps avoid breaking modular routing semantics.
+That helps avoid breaking modular routing semantics and keeps ordinary business routes on their canonical paths.
 
 ## Where to read next
 

package/cabloy-docs/frontend/ssr-env.md

@@ -28,22 +28,31 @@ These affect SSR profile selection, theme defaults, server-side API targeting, a
 
 For Vona-backed SSR, `SSR_PROFILE` supplies the flavor default. After the frontend route is resolved, `route.meta.ssrProfile` can override that default before `serverEntry` runs. The resolved profile controls request-cookie capability and related SSR behavior; locale-aware URL handling remains the existing `route.meta.locale` contract. A profile never grants authentication, site admission, or API authorization; `requiresAuth` and Vona guards remain responsible for those decisions.
 
+Route authors should choose the profile from the rendering contract rather than from the presence or absence of a `locale` parameter. Use `session` when SSR genuinely needs cookie-backed state, protected admission, personalized first paint, or private data; use `public` for an explicit URL-locale or deliberately locale-neutral, cache-safe, hydration-equivalent public contract. This is not an authentication requirement: an anonymous route should set `requiresAuth: false`, and `session` still does not grant Passport, Site, role, or API authority.
+
 The selected layout owns sidebar restoration. A layout that enables `layout.sidebar.bodyReadyObserver` queues a request-local hidden-body metadata entry during SSR, registers its readiness condition and restoration callback, and then injects the generic browser observer. The observer restores browser-local sidebar state after the relevant layout DOM exists and reveals the body before hydration. Admin enables this path; Web and Empty disable it. Therefore, a Web route using `ssrProfile: 'session'` remains `private, no-store` without gaining the Admin sidebar observer.
 
 The selected layout also supplies its own desktop sidebar fallback and responsive breakpoint: the Admin layout defaults to open and the Web layout defaults to closed, and both currently use `1023px` as their independently configured breakpoint. Browser-local sidebar preference can override that fallback. The selected layout passes its breakpoint to the SSR browser handoff; it is not profile-specific. SSR profile selection does not change a layout's sidebar behavior.
 
 ## SSR response cache control
 
-After Zova resolves the route profile, a `session` response immediately receives `Cache-Control: private, no-store`, before router guards or rendering can terminate it. A successfully rendered public route receives the profile default cache header, which `meta.ssrProfileOptions.responseCache` can refine.
+After Zova resolves the route profile, a `session` response immediately receives `Cache-Control: private, no-store`, before router guards or rendering can terminate it. A successfully rendered public route receives a response-cache header according to the route's locale metadata and any explicit `meta.ssrProfileOptions.responseCache` policy.
+
+For a public route, the default policy is:
+
+- `meta.locale: true`: use the configured public profile cache policy;
+- missing or false `meta.locale`: use `expires: 0`, which emits `Cache-Control: no-cache, no-store, must-revalidate`.
+
+The second case prevents a CDN from sharing HTML whose hydration-time locale may still come from a browser cookie while the URL does not identify the locale. A route-level `meta.ssrProfileOptions.responseCache` override remains authoritative, including `false`; use an explicit override only when the route's complete SSR HTML is safe to share for that URL.
 
 Cabloy Basic uses different flavor defaults:
 
-| Flavor | Default profile | SSR response header                  |
-| ------ | --------------- | ------------------------------------ |
-| Web    | `public`        | `public, max-age=600` when cacheable |
-| Admin  | `session`       | `private, no-store`                  |
+| Flavor | Default profile | SSR response header                           |
+| ------ | --------------- | --------------------------------------------- |
+| Web    | `public`        | locale-aware routes use `public, max-age=600` |
+| Admin  | `session`       | `private, no-store`                           |
 
-A route can override the flavor profile through `meta.ssrProfile` and can define a public response-cache policy through `meta.ssrProfileOptions.responseCache`. Set the nested value to `false` to disable public cache-header generation for that route. For Cloudflare cache-rule alignment that preserves these origin headers, see [Docker + Cloudflare Deployment](/fullstack/deploy-cloudflare-docker).
+A route can override the flavor profile through `meta.ssrProfile` and can define a public response-cache policy through `meta.ssrProfileOptions.responseCache`. For Cloudflare cache-rule alignment that preserves these origin headers, see [Docker + Cloudflare Deployment](/fullstack/deploy-cloudflare-docker).
 
 ## Theme implications of `SSR_PROFILE`
 

package/cabloy-docs/frontend/ssr-overview.md

@@ -34,6 +34,16 @@ For browser work that must wait for the initial SSR handoff, register `this.$ssr
 
 This lifecycle applies only to the initial client hydration of SSR HTML. It is not an SPA-startup or later client-navigation readiness signal. Do not render a client-ready marker into server HTML; add it from an `onHydrated(...)` callback when browser-visible evidence is required.
 
+For work that is safe to run immediately in an SPA, but must wait until hydration in an SSR document, use `this.$ssr.handleDirectOrOnHydrated(...)`:
+
+```ts
+this.$ssr.handleDirectOrOnHydrated(() => {
+  // browser-only work
+});
+```
+
+The helper is a client-only boundary. It returns without invoking the callback on the server; during the browser's initial SSR hydration it queues the callback through `onHydrated(...)`; and for SPA startup or after hydration it invokes the callback immediately. Callers should not wrap this helper in a second `process.env.CLIENT` guard. Do not put server-required initialization inside the callback; keep server work outside the helper and use the helper only for browser-only work.
+
 For a render-time branch, use `this.$ssr.isRuntimeSsrHydrated`. It is reactive and is `false` during server rendering and the browser's initial hydration render, then `true` after that hydration completes. It is also immediately `true` for SPA startup and later client navigation. Use it to retain the same neutral shell before hydration and begin private or browser-only queries and UI afterward. It indicates only SSR-hydration lifecycle readiness, not completed route admission, authentication, or data loading.
 
 ### SEO meta

package/cabloy-docs/frontend/ssr-review-checklist.md

@@ -41,6 +41,7 @@ Use this short checklist for PR review, AI review, or self-review.
 - [ ] I verified that the change uses existing SSR abstractions rather than inventing a parallel workaround.
 - [ ] I checked whether the change needs verification in built mode rather than only in dev mode.
 - [ ] I reviewed whether the change depends on edition-specific UI or theme assumptions.
+- [ ] For each new or changed route, I resolved static-versus-dynamic `route.name`, ordinary no-locale alias, the rendering-contract-driven SSR profile, and independent `requiresAuth` decisions.
 
 ## Layer-by-layer review checklist
 

package/cabloy-docs/frontend/zova-form-under-the-hood.md

@@ -233,6 +233,12 @@ A practical reading takeaway is:
 - **schema is not only validation truth**
 - **schema also drives ordering, render metadata, and scene-specific field behavior**
 
+### The form owner supplies the schema lifetime
+
+`ZForm` derives `properties` and `zodSchema` from the schema it receives. Its runtime does not own `$apiSchema` locale selection or refresh a facade retained by the page/controller. If the owner supplies a schema object created under an earlier locale, the form will faithfully render that object's titles and metadata.
+
+Automatic rendering also has an explicit composition boundary: when the form has no default body slot, `RenderForm` iterates the resolved schema properties; `slotHeader` and `slotFooter` can add structure without replacing that body. A default body slot replaces automatic iteration, so manual or mixed composition must render the required fields intentionally. See [Form Guide](/frontend/form-guide) and [API Schema Guide](/frontend/api-schema-guide) for the recommended live-schema pattern.
+
 ## 5. The form controller creates the field render context
 
 Still inside `form/controller.tsx`, the form controller prepares the field runtime support used later by every field:

package/cabloy-docs/frontend/zova-router-under-the-hood.md

@@ -96,7 +96,6 @@ export const routes: IModuleRoute[] = [
     },
   },
   {
-    name: 'toolMinimal',
     path: 'toolMinimal',
     component: ZPageToolMinimal,
     meta: {
@@ -112,7 +111,7 @@ What matters here is not only the route strings.
 What matters is that:
 
 - the module declares routes relative to the module boundary by default
-- route `name` controls named routing and typed params/query schema selection
+- dynamic-parameter routes require `name` for typed params; static routes normally remain path-keyed
 - route `meta` controls shell-facing behavior such as layout and component reuse strategy
 - the route record is only the first layer; config, guards, startup timing, and router-view hosting still cooperate afterward
 
@@ -231,7 +230,7 @@ This is one reason route authoring stays compact while runtime routing stays glo
 
 Before adding the route, the runtime checks `sys.config.routes.name` or `sys.config.routes.path` and deep-merges the config route on top of the module declaration.
 
-That is why alias and route-policy changes belong in config instead of being hand-spread across module route files.
+That is why an approved alias or shared route-policy override belongs in config instead of being hand-spread across module route files. An alias is an explicit public-URL contract, not a routine convenience: ordinary business routes without `locale` params keep their canonical module path unless a documented system entry, compatibility path, or designed user-facing URL requires an exception.
 
 Representative config source:
 
@@ -263,7 +262,7 @@ This detail is important because:
 - the runtime can still preserve named-route identity and params-aware resolution
 - alias handling remains a router concern instead of leaking into page code
 
-`$alias:<name>` and `/__alias__` are private runtime machinery. Application code should use `$router.getAliasPath('module:page', { params, query }, absolute?)`, which accepts the canonical route name and returns the configured public alias path (or `undefined` when no alias is configured). Its optional `absolute` argument uses the same origin and public-path conversion as `getPagePath(...)`.
+`$alias:<name>` and `/__alias__` are private runtime machinery. Application code should use `$router.getAliasPath('module:page', { params, query }, absolute?)` only when it intentionally needs a configured public alias; the helper accepts the canonical route name and returns that alias path (or `undefined` when no alias is configured). Its optional `absolute` argument uses the same origin and public-path conversion as `getPagePath(...)`. For a known canonical static page path, use path-keyed `$router.getPagePath(...)` instead of adding a route name or alias solely for URL generation.
 
 #### Layout wrapping
 
@@ -417,7 +416,7 @@ When `_initControllerRoute(...)` updates a page controller, it resolves the rout
 - `pageNameSchemas` for named routes
 - `pagePathSchemas` for path-keyed routes
 
-For page routes with dynamic params, define `route.name` and use the named-route metadata path. Do not rely on an unnamed parameterized route: the generated path-keyed record does not establish the typed controller `$params` contract.
+For page routes with dynamic params, define `route.name` and use the named-route metadata path. Do not rely on an unnamed parameterized route: the generated path-keyed record does not establish the typed controller `$params` contract. Conversely, a static route should not acquire a name merely for typing, canonical URL generation, or alias convenience; keep it path-keyed unless a documented named-route contract requires otherwise.
 
 Those schema records are generated into module metadata.
 

package/cabloy-docs/fullstack/a-pay-payment-suite.md

@@ -261,7 +261,7 @@ provider return or cancel
   -> durable order settlement observation
 ```
 
-The Commerce payment route requires authentication and uses the session SSR profile. Its controller defers client initialization through `$ssr.handleDirectOrOnHydrated(...)`. The payment-session model avoids creating private server-side query state when cookies are unavailable or the Passport is not authenticated. After hydration and admission, the controller can reconcile, poll, and navigate using customer-authorized reads.
+The Commerce payment route requires authentication and uses the session SSR profile. Its controller keeps server-required preparation separate from browser-only initialization and passes the latter through `$ssr.handleDirectOrOnHydrated(...)`. This helper returns without invoking its callback on the server, queues it until initial SSR hydration completes, and runs it immediately for SPA startup or later client navigation. The payment-session model avoids creating private server-side query state when cookies are unavailable or the Passport is not authenticated. After hydration and admission, the controller can reconcile, poll, and navigate using customer-authorized reads.
 
 The invariant is more important than a particular visual shell: server HTML and the hydration-time initial render must agree about private payment/order data. Do not render customer-owned payment state on the server when the request cannot authorize it, and do not let the provider return itself settle Commerce.
 

package/cabloy-docs/fullstack/deploy-cloudflare-docker.md

@@ -89,8 +89,11 @@ After the origin is reachable with its TLS configuration:
    SERVER_SERVE_PROTOCOL=https
    SERVER_SERVE_HOST=example.com
    SERVER_SUBDOMAINOFFSET=2
+   CORS_WHITE_LIST=https://app.example.com
    ```
 
+`SERVER_SERVE_PROTOCOL` and `SERVER_SERVE_HOST` define the backend's canonical public origin; they do not automatically authorize a separately hosted browser frontend. When the frontend or another browser consumer uses a different origin, set `CORS_WHITE_LIST` to explicit comma-separated origins, as shown above. Keep this list limited to the origins that require browser access; do not use a wildcard as the production default. The normal CORS allowlist is also used by the built-in WebSocket origin check, while account credential-link flows require exact normalized HTTP(S) origins.
+
 The base hostname resolves to the empty-name/default instance. For example, `acme.example.com` resolves to `acme`; a deeper hostname such as `eu.acme.example.com` resolves to `acme.eu` and requires that explicitly configured instance.
 
 For current Cloudflare proxy-record behavior, see [Proxied DNS records](https://developers.cloudflare.com/dns/manage-dns-records/reference/proxied-dns-records/).
@@ -111,16 +114,19 @@ For current Cache Rule settings, see [Cache Rules settings](https://developers.c
 
 ## SSR cache contract
 
-Zova SSR writes the public response-cache contract during rendering from the resolved profile and any public route-level `meta.ssrProfileOptions.responseCache` override. The effective SSR profile is authoritative: a `session` response always sets `Cache-Control: private, no-store` before route or profile response-cache policy is considered.
+Zova SSR writes the public response-cache contract during rendering from the resolved profile, route locale metadata, and any public route-level `meta.ssrProfileOptions.responseCache` override. The effective SSR profile is authoritative: a `session` response always sets `Cache-Control: private, no-store` before route or profile response-cache policy is considered.
+
+For a public route, the default response header depends on whether the URL identifies locale:
 
-| Flavor | Default profile | SSR response header                                 | Cloudflare result with this rule                                |
-| ------ | --------------- | --------------------------------------------------- | --------------------------------------------------------------- |
-| Web    | `public`        | `Cache-Control: public, max-age=600` when cacheable | Eligible to cache for ten minutes, subject to Cloudflare policy |
-| Admin  | `session`       | `Cache-Control: private, no-store`                  | Not stored                                                      |
+| Route condition                | Default SSR response header                                              | Cloudflare result with this rule  |
+| ------------------------------ | ------------------------------------------------------------------------ | --------------------------------- |
+| `meta.locale: true`            | `Cache-Control: public, max-age=600` using the Basic Web profile default | Eligible to cache for ten minutes |
+| missing or false `meta.locale` | `Cache-Control: no-cache, no-store, must-revalidate`                     | Not stored                        |
+| `session` profile              | `Cache-Control: private, no-store`                                       | Not stored                        |
 
 For Cabloy Start, verify the effective Web and Admin values in the licensed Start repository before creating the Cloudflare rule. The rule design remains the same: preserve and follow the origin `Cache-Control` response instead of replacing it.
 
-A route can override the flavor default through SSR route metadata. The Cloudflare rule follows the response contract; it does not replace it.
+A route can override the flavor default through SSR route metadata. An explicit public `meta.ssrProfileOptions.responseCache` policy remains authoritative; the Cloudflare rule follows the resulting response contract and does not replace it.
 
 For the public Basic environment-variable details, see [SSR Environment Variables](/frontend/ssr-env).
 
@@ -131,6 +137,6 @@ After the origin is running, verify the following before relying on Cloudflare t
 1. The base hostname returns the expected default instance.
 2. Each configured subdomain resolves to its expected enabled instance.
 3. Nginx forwards the browser hostname instead of the literal value `localhost`.
-4. Web SSR returns the `Cache-Control` header expected from the active edition and flavor configuration. In the current Basic baseline, it is `public, max-age=600`.
+4. Web SSR returns the `Cache-Control` header expected from the active edition, route metadata, and flavor configuration: locale-aware public routes use the configured public cache default, while public routes without `meta.locale: true` use `no-cache, no-store, must-revalidate` unless they have an explicit cache override.
 5. Admin SSR returns the `Cache-Control` header expected from the active edition and flavor configuration. In the current Basic baseline, it is `private, no-store`.
-6. After Cloudflare proxying is enabled, responses intended to be public-cacheable can be cached at the edge while responses marked `no-store` are not stored.
+6. After Cloudflare proxying is enabled, only responses whose origin policy permits public caching are cached at the edge; responses marked `no-store` are not stored.

package/e2e/specs/a-commerce/commerce.spec.ts

@@ -115,12 +115,16 @@ async function registerCustomer(
   expect(captcha?.id).toEqual(expect.any(String));
   expect(captcha?.token).toEqual(expect.any(String));
 
+  const baseURL = testInfo.project.use.baseURL;
+  if (!baseURL) throw new Error('commerce E2E base URL is unavailable');
+  const consumerUrl = new URL('/home/user/activation', baseURL).toString();
   const registerResponse = await request.post('/api/home/user/passport/register', {
     data: {
       username,
       email: `${username}@example.test`,
       password,
       passwordConfirm: password,
+      consumerUrl,
       captcha: { id: captcha.id, token: captcha.token },
     },
   });
@@ -1506,6 +1510,16 @@ test(
       await expect(childRow.getByText(parentName, { exact: true })).toBeVisible();
       await expect(childRow.getByText('Published', { exact: true })).toBeVisible();
 
+      await adminPage.goto(`${categoryListPath}/${parentId}/edit`, { waitUntil: 'load' });
+      await expect(
+        adminPage.getByRole('group', { name: 'Published' }).getByRole('combobox'),
+      ).toHaveValue('false');
+
+      await adminPage.goto(`${categoryListPath}/${childId}/edit`, { waitUntil: 'load' });
+      await expect(
+        adminPage.getByRole('group', { name: 'Published' }).getByRole('combobox'),
+      ).toHaveValue('true');
+
       await adminPage.goto(`${categoryListPath}/${childId}`, { waitUntil: 'load' });
       await expect(
         adminPage.getByRole('group', { name: 'Parent category' }).getByRole('textbox'),
@@ -1928,8 +1942,9 @@ test(
       await adminPage.goto(skuCreatePath, { waitUntil: 'load' });
       const productField = adminPage.getByRole('group', { name: 'Product' });
       await expect(productField).toBeVisible();
-      await expect(productField.getByRole('combobox')).toHaveCount(0);
-      await expect(productField.getByRole('textbox')).toBeVisible();
+      const productPicker = productField.getByRole('combobox');
+      await expect(productPicker).toBeVisible();
+      await expect(productPicker).toHaveValue('');
       const lifecycle = adminPage
         .getByRole('group', { name: 'SKU lifecycle' })
         .getByRole('combobox');