generator-white-label 8.0.0 → 10.0.0

package/CLI.md

@@ -7,7 +7,7 @@ CLI ──────> createProject() ──────> project
 Node API ─┘
 ```
 
-`createProject()` owns the scaffold. The CLI translates command-line input into that API.
+`createProject()` owns the canonical tagged-template scaffold, including destination safety. The CLI translates command-line input into that API; it does not maintain a second generation path.
 
 ## Create a project
 
@@ -25,7 +25,7 @@ yarn dlx generator-white-label create my-project
 pnpm dlx generator-white-label create my-project
 ```
 
-The CLI creates into a new or existing **empty** directory. It refuses a non-empty destination so a mistyped path cannot overwrite existing project files.
+Project creation accepts a missing or existing **empty** directory. A non-empty destination is rejected before scaffold files are copied or written.
 
 Then install and test the generated project with npm, Yarn, or pnpm:
 
@@ -36,23 +36,21 @@ npm install && npm test
 # or: pnpm install && pnpm test
 ```
 
-When run interactively, the CLI asks whether page and view templates should use JSX/TSX. JSX is optional: choose **Yes** for White Label's first-party JSX syntax such as `<section>...</section>`, or **No** for plain TypeScript functions that return HTML strings. Both choices produce the same working starter application and features.
+The generated project uses ordinary `.ts` files and White Label View's first-party tagged HTML templates:
 
-Choose **No** when you want plain string templates or plan to use a third-party renderer. Install that renderer in the generated application and call it from the View `template` function; White Label does not require an adapter. See [Template engines and JSX options](https://whitelabeljs.org/docs/view/#template-engines) for the tested third-party engines and rendering contract.
+```ts
+import {html} from 'white-label-view/html';
 
-For scripts and non-interactive use, choose explicitly:
-
-```sh
-white-label create my-project --jsx
-white-label create my-project --no-jsx
-
-npx generator-white-label create my-project --jsx
-npx generator-white-label create my-project --no-jsx
+export default function Page(data: {title: string}) {
+    return html`<main><h1>${data.title}</h1></main>`;
+}
 ```
 
-The same `--jsx` and `--no-jsx` flags work through `yarn dlx` and `pnpm dlx`.
+Dynamic text and quoted-attribute values are escaped by the tagged-template runtime. Use `attributes()` for conditional/opening-tag attributes and reserve `unsafeHTML()` for application-owned content that is already trusted or sanitized.
 
-If no choice can be asked interactively and neither flag is supplied, JSX remains the default for backward compatibility.
+There is no generator renderer prompt and no `--jsx` or `--no-jsx` flag. If a project prefers JSX, Handlebars, Eta, EJS, Mustache, Nunjucks, Pug, or another renderer, add it as an application dependency and return its rendered output from View's `template` function. JSX remains a tested third-party option rather than a generator-owned runtime.
+
+See [Template engines](https://whitelabeljs.org/docs/view/#template-engines) for tested integrations and trust boundaries.
 
 Run `white-label --help` for usage. See [`PACKAGE_MANAGERS.md`](PACKAGE_MANAGERS.md) for package-manager compatibility details.
 
@@ -62,21 +60,19 @@ Run `white-label --help` for usage. See [`PACKAGE_MANAGERS.md`](PACKAGE_MANAGERS
 import {createProject} from 'generator-white-label';
 
 await createProject({
-    destination: '/absolute/path/to/my-project',
-    jsx: false
+    destination: '/absolute/path/to/my-project'
 });
 ```
 
-Set `jsx: true` for JSX/TSX templates or `jsx: false` for plain TypeScript and HTML strings. Use `jsx: false` as the starting point when another template engine should own rendering. Omitting `jsx` defaults to `true`.
-
-`createProject()` is the lower-level programmatic API and does not apply the CLI's non-empty-directory guard. Applications using it directly own destination-policy decisions.
+`createProject()` uses the same destination-safety rule as the CLI: missing and empty directories are allowed; non-empty directories are rejected before project content is written.
 
 ## Read the implementation
 
 The source is intentionally small enough to teach the design:
 
-- `scaffold/index.ts` — project creation
+- `scaffold/index.ts` — project creation and destination-safety boundary
 - `cli/index.ts` — command-line adapter
+- `app/` — canonical TypeScript/tagged-template starter
 - `test/` — executable contracts
 
 Creation behavior belongs in one place. Future integrations should call `createProject()` rather than copy templates or reimplement generation logic.

package/EXISTING_APPLICATIONS.md

@@ -0,0 +1,155 @@
+# Adopt White Label in an existing server-rendered application
+
+White Label does not require a rewrite. Existing applications should install only the runtime packages a feature needs and integrate them at explicit boundaries.
+
+The **generator is intentionally for new projects** and refuses to scaffold over a non-empty destination. If an application already exists—SFCC/SFRA, a CMS, Rails, PHP, Java, .NET, another server-rendered stack, or a long-lived frontend—do not regenerate the host application. Add White Label to one feature or DOM region at a time.
+
+This is one of the strongest White Label use cases: modern TypeScript structure and lifecycle where it helps, while the existing platform keeps ownership of routing, business rules, initial HTML, and the rest of the page.
+
+## When this pattern fits
+
+Incremental adoption is a good fit when:
+
+- the server or CMS already renders meaningful HTML;
+- public URLs, SEO, accessibility, or no-JavaScript behavior matter;
+- a rewrite would be disproportionate to the feature being added;
+- teams want observable state, lifecycle, application events, or URL-backed interaction without introducing a full frontend framework;
+- multiple teams/features need clear ownership boundaries on the same page;
+- commerce/account/content flows must keep authoritative business logic on the server.
+
+It is less compelling for experiences that are intentionally fully client-owned and deeply stateful across most of the viewport, such as editors, design tools, complex collaborative workspaces, or other applications where a component framework already provides valuable shared conventions.
+
+## Install only the needed primitives
+
+Start with the actual responsibility the feature needs:
+
+```sh
+npm install white-label-view white-label-model
+```
+
+Add Router or Mediator only when the feature genuinely needs URL state or cross-module events:
+
+```sh
+npm install white-label-router white-label-mediator
+```
+
+White Label packages do not require the generator at runtime and do not require one another unless the application chooses to compose them.
+
+A useful rule is:
+
+```text
+existing platform owns the page
+        +
+White Label owns a deliberate feature boundary
+```
+
+## Adopt existing server-rendered markup
+
+`white-label-view` can own lifecycle around an element that already exists instead of replacing the host application's rendering system.
+
+```ts
+import {Model} from 'white-label-model';
+import View from 'white-label-view';
+
+const status = document.querySelector<HTMLElement>('[data-filter-status]')!;
+const filters = new Model({color: ''});
+
+const statusView = new View({
+    parentElement: status.parentElement!,
+    element: status,
+    model: filters,
+    update(element, data) {
+        const state = data as {color: string};
+        element.textContent = state.color
+            ? `Color filter: ${state.color}`
+            : 'No color filter selected';
+        return true;
+    }
+}).initialize();
+```
+
+No client template is required when an attached existing element can be updated in place. The host remains responsible for the initial HTML; View owns only the adopted root and its lifecycle.
+
+Keep ownership narrow. Unrelated server-rendered siblings, headers, forms, navigation, and page chrome should remain outside the View unless the feature genuinely owns them.
+
+`destroy()` removes the root the View owns. If the host application expects that element to remain after enhancement teardown, choose an ownership boundary that can be removed safely rather than treating host-owned markup as disposable.
+
+## Scope progressive routing to one enhanced region
+
+By default, Router listens for opted-in `data-pushstate` links across the document. An embedded or incrementally adopted feature can limit that interception to its own DOM region:
+
+```ts
+import Router from 'white-label-router';
+
+const refinementArea = document.querySelector<HTMLElement>('[data-refinements]')!;
+const router = new Router();
+
+router.navigationRoot = refinementArea;
+router.routes = {
+    '/search': (_scope, location) => {
+        filters.update({color: location.data.query.prefv1 || ''});
+    }
+};
+router.initialize();
+```
+
+Only eligible links whose click event reaches that navigation root are enhanced by that Router. Other page links retain the host application's normal behavior. Multiple independently owned regions can therefore coexist without every Router claiming document-wide link handling.
+
+`navigationRoot` controls click-listener ownership. It is deliberately separate from `router.scope`, which remains the value passed to route handlers.
+
+## Add state and events only where needed
+
+A feature does not need the full White Label stack.
+
+Use `white-label-model` when the feature needs observable state. Load data through the application's existing fetch/client/service layer, validate it at that boundary when appropriate, then apply it to Model. Model should not replace a backend API, persistence layer, or framework store solely for architectural symmetry.
+
+Use `white-label-mediator` when separate modules need to exchange intent without importing one another. Direct function calls are clearer when there is already an ownership relationship. Avoid turning a mediator into an unstructured global event namespace.
+
+## Preserve the host application's server contract
+
+White Label should not duplicate or bypass server-owned responsibilities. Keep these in the existing platform when it already owns them:
+
+- authentication and authorization;
+- pricing, inventory, tax, promotions, checkout, and other authoritative business rules;
+- canonical URLs and directly requestable public routes;
+- initial semantic content and crawlable navigation;
+- CSRF/session protections and trusted API boundaries;
+- CMS/content governance and server-side personalization rules;
+- persistence, queues, retries, and cross-process workflows.
+
+Use White Label where a client-side state, lifecycle, event, or URL boundary adds value. Normal server navigation is still the right choice when enhancement does not materially improve the interaction.
+
+## SEO and accessibility boundary
+
+For public content, keep the important information in the initial response. Progressive enhancement should improve interaction rather than become a prerequisite for discovery or comprehension.
+
+Prefer:
+
+- real `href` values and directly requestable routes;
+- semantic headings, forms, controls, landmarks, and status regions in initial HTML;
+- server/static ownership of canonical URLs, titles, descriptions, robots directives, and structured data;
+- deliberate focus handling after meaningful client-side navigation or content replacement;
+- client behavior that preserves keyboard, context-menu, modified-click, and no-JavaScript behavior.
+
+Do not treat source-level metadata as proof of search-engine indexing. Validate deployed behavior and indexing with actual production/search-console evidence.
+
+## Teardown
+
+Long-lived shells and dynamically mounted regions should release the objects they own:
+
+```ts
+statusView.destroy();
+router.destroy();
+filters.destroy();
+```
+
+Also destroy a feature-owned Mediator when that event boundary leaves the application lifecycle.
+
+## Commerce and SFCC example
+
+The White Label demo repository contains a concrete Salesforce B2C Commerce / SFRA example using the same incremental boundary:
+
+- [SFCC / SFRA progressive enhancement recipe](https://github.com/bshack/white-label-demo-site/blob/main/docs/recipes/sfcc-sfra-progressive-enhancement.md)
+- [Incremental JavaScript for server-rendered applications](https://whitelabeljs.org/guides/incremental-javascript-for-server-rendered-apps/)
+
+The same pattern applies to other server-rendered stacks: keep the server as the source of truth, then adopt only the client-side regions that need richer behavior.

package/PACKAGE_MANAGERS.md

@@ -10,9 +10,9 @@ yarn dlx generator-white-label create my-project
 pnpm dlx generator-white-label create my-project
 ```
 
-The same `--jsx` and `--no-jsx` options are available through every invocation path. JSX is optional: use `--jsx` for the first-party White Label JSX runtime, or `--no-jsx` for plain TypeScript templates and as the starting point for a third-party template engine.
+Every invocation creates the same canonical TypeScript/tagged-template starter. There are no renderer-selection flags.
 
-See [Template engines and JSX options](https://whitelabeljs.org/docs/view/#template-engines) for tested third-party renderers and the View rendering contract.
+White Label View remains template-engine agnostic. Projects that prefer JSX or a third-party renderer can install it after generation and return its rendered output from View's `template` function. See [Template engines](https://whitelabeljs.org/docs/view/#template-engines) for tested integrations and trust boundaries.
 
 ## Work with a generated project
 
@@ -26,10 +26,12 @@ pnpm install && pnpm test
 
 Generated manifests require the supported Node.js runtime but do not require a specific package manager. Nested scripts use Node's `--run` support instead of invoking npm internally.
 
-Generated projects use exact npm versions for the four first-party White Label packages. They also carry narrow install-script approvals for the dependencies that actually need lifecycle builds: `esbuild`, `@parcel/watcher`, and `white-label-view`. npm uses pinned `allowScripts` entries, Yarn uses pinned `dependenciesMeta` build permissions, and pnpm uses `onlyBuiltDependencies`.
+Generated projects use exact npm versions for the four first-party White Label packages. Install/build lifecycle approvals are limited to dependencies that need native or generated artifacts during installation: `esbuild` and `@parcel/watcher`. npm uses pinned `allowScripts` entries, Yarn uses pinned `dependenciesMeta` build permissions, and pnpm uses `onlyBuiltDependencies`. Published White Label runtime packages include their built output and do not receive lifecycle-script approval in generated projects.
 
-Yarn's package-age security gate is left enabled for ordinary dependencies. The generated `.yarnrc.yml` preapproves only `white-label-mediator`, `white-label-model`, `white-label-router`, and `white-label-view` so a newly published White Label release can be installed immediately without disabling Yarn's protection for the rest of the dependency graph.
+Yarn's package-age security gate is left enabled for ordinary dependencies. The generated `.yarnrc.yml` preapproves only `white-label-mediator`, `white-label-model`, `white-label-router`, and `white-label-view` so a newly published coordinated White Label release can be installed immediately without disabling Yarn's protection for the rest of the dependency graph. Package-age preapproval does not grant lifecycle-script execution.
 
 ## Repository development
 
 The committed `package-lock.json` remains the generator repository's canonical dependency lockfile and npm remains the maintenance/audit path used by primary CI. Compatibility CI packs the real generator artifact and verifies its API and CLI under npm, Yarn, and pnpm. Alternate lockfiles are not committed merely for compatibility testing.
+
+Generator 10 depends on `white-label-view@7`. View 7's implementation is merged but not yet published, so coordinated CI temporarily builds and injects the exact merged View 7 revision for integration testing. The release lockfile remains registry-based; do not replace it with a Git dependency or treat the temporary packed artifact as a published dependency. Normal registry installation remains a release gate until View 7 is published.

package/README.md

@@ -1,16 +1,30 @@
 # generator-white-label
 
-`generator-white-label` is a framework-independent TypeScript project generator for small, accessible, SEO-friendly sites with progressive enhancement, composable White Label primitives, and a provider-neutral Node.js function example.
+`generator-white-label` is a framework-independent TypeScript project generator for small, accessible, SEO-friendly, HTML-first sites with progressive enhancement, composable White Label primitives, first-party tagged HTML templates, and a provider-neutral Node.js function example.
 
 [Documentation](https://whitelabeljs.org/docs/generator/) · [API reference](https://whitelabeljs.org/api/#generator) · [Demo site](https://whitelabeljs.org/)
 
-The project is also its own teaching tool. The landing page, README, source, and tests are meant to be read together:
+White Label does not prescribe a framework. It provides focused pieces that can be composed where useful and omitted where they are not.
 
-```text
-understand → see → build → verify
-```
+## Where the generator fits
 
-White Label does not prescribe a framework. It provides focused pieces that can be composed where useful and omitted where they are not.
+Use the generator when starting a **new** site or small web application and you want:
+
+- meaningful static HTML before client JavaScript runs;
+- progressive enhancement instead of an SPA requirement;
+- explicit Model/View/Mediator/Router boundaries;
+- ordinary TypeScript with readable HTML-shaped templates;
+- accessibility and search-oriented defaults;
+- a small codebase that remains easy for humans and coding agents to inspect;
+- provider-neutral Web `Request`/`Response` serverless composition.
+
+The generated project is especially well suited to public sites, documentation/content experiences, agency or multi-client work, small product/account surfaces, and teams that want application structure without handing architecture to a full framework.
+
+### Already have an application?
+
+Do **not** use the generator to layer a scaffold over it. The generator intentionally rejects a non-empty destination.
+
+Existing server-rendered, CMS, commerce, Rails/PHP/Java/.NET, or long-lived frontend applications should install the individual White Label runtime packages they need and adopt them incrementally. See [`EXISTING_APPLICATIONS.md`](EXISTING_APPLICATIONS.md) and the public [incremental server-rendered application guide](https://whitelabeljs.org/guides/incremental-javascript-for-server-rendered-apps/).
 
 ## The idea
 
@@ -30,21 +44,61 @@ URL / user action
       DOM
 ```
 
-These are responsibilities, not mandatory layers. Static content can stay plain JSX or plain TypeScript HTML strings. A feature that does not need routing does not need a router.
+These are responsibilities, not mandatory layers. Static content can stay a plain TypeScript function that returns tagged HTML. A feature that does not need routing does not need a router; a feature that only needs local state can use Model by itself.
 
 - [`white-label-router`](https://github.com/bshack/white-label-router) turns location into application intent.
 - [`white-label-mediator`](https://github.com/bshack/white-label-mediator) coordinates application events.
 - [`white-label-model`](https://github.com/bshack/white-label-model) owns observable state.
 - [`white-label-view`](https://github.com/bshack/white-label-view) owns rendering and DOM lifecycle.
-- [`white-label-view/jsx-runtime`](https://github.com/bshack/white-label-view) provides optional escaped JSX without React or another template engine.
+- `white-label-view/html` provides the first-party tagged-template helpers used by the generator.
 
 The goal is simple boundaries with explicit composition.
 
+## Tagged HTML templates
+
+Generated pages and View templates are ordinary `.ts` functions:
+
+```ts
+import {html} from 'white-label-view/html';
+
+export default function Page(data: {title: string}) {
+    return html`
+        <main>
+            <h1>${data.title}</h1>
+        </main>
+    `;
+}
+```
+
+Normal text and quoted-attribute interpolations are escaped. Tagged markup composes without double escaping, so small view functions can remain reusable without introducing a component runtime.
+
+Conditional or grouped opening-tag attributes use `attributes()`:
+
+```ts
+import {attributes, html} from 'white-label-view/html';
+
+const input = html`
+    <input ${attributes({
+        type: 'checkbox',
+        checked: complete,
+        'data-task-id': taskId
+    })}>
+`;
+```
+
+`unsafeHTML()` is deliberately explicit. Use it only for application-owned content that is already trusted or sanitized, such as controlled JSON-LD after applying the application's serialization policy. It is not a sanitizer and it is not a replacement for contextual URL/CSS validation.
+
+The tagged-template runtime rejects interpolation in ambiguous or dangerous contexts such as script/style bodies, comments, tag names, and unquoted attribute positions rather than pretending generic escaping makes those contexts safe.
+
+White Label View remains template-engine agnostic. JSX, Handlebars, Eta, EJS, Mustache, Nunjucks, Pug, and other renderers can remain application dependencies and return their rendered output from View's `template` function. JSX is a tested third-party option rather than a White Label-owned runtime.
+
+See [Template engines](https://whitelabeljs.org/docs/view/#template-engines) for tested integrations and trust boundaries.
+
 ## Learn from the generated application
 
-The generated landing page demonstrates the same architecture it documents.
+The project is also a teaching tool. The generated landing page demonstrates the same architecture its source and tests document.
 
-Its static sections use either JSX functions or equivalent plain TypeScript HTML-string functions, depending on the generator choice. The task example then shows all four packages working together:
+The task example shows all four runtime packages working together:
 
 ```text
 TaskRouter
@@ -54,33 +108,19 @@ TaskMediator
 TaskModel
     ↓ observable state
 TaskView
-    ↓ render
+    ↓ tagged HTML render
 DOM
 ```
 
-Both generated variants provide the same application behavior and progressive enhancement. The only difference is template syntax.
-
-## Read the source
-
-For the default JSX scaffold, a useful reading order is:
+A useful reading order is:
 
-1. [`app/index.tsx`](app/index.tsx) — page composition.
-2. [`app/assets/view/sections/LiveExampleSection.tsx`](app/assets/view/sections/LiveExampleSection.tsx) — static composition around an interactive feature.
-3. [`app/assets/view/examples/tasks/TaskExample.tsx`](app/assets/view/examples/tasks/TaskExample.tsx) — shared JSX rendering.
+1. [`app/index.ts`](app/index.ts) — page composition.
+2. [`app/assets/view/sections/LiveExampleSection.ts`](app/assets/view/sections/LiveExampleSection.ts) — static composition around an interactive feature.
+3. [`app/assets/view/examples/tasks/TaskExample.ts`](app/assets/view/examples/tasks/TaskExample.ts) — shared tagged-template rendering.
 4. [`app/assets/script/tasks/TaskApplication.ts`](app/assets/script/tasks/TaskApplication.ts) — explicit dependency wiring.
 5. `TaskRouter`, `TaskMediator`, `TaskModel`, and `TaskView` — one responsibility at a time.
-6. [`server/handler.ts`](server/handler.ts) — provider-neutral `Request`/`Response` serverless composition.
-7. [`test/app.test.js`](test/app.test.js) and [`template-test/site.test.js`](template-test/site.test.js) — browser and generated-project contracts.
-
-The `--no-jsx` scaffold mirrors the same structure with `.ts` files and HTML-string render functions.
-
-Comments focus on why boundaries exist instead of narrating obvious TypeScript.
-
-When documenting public APIs, examples use comments where they clarify intent, lifecycle, side effects, or non-obvious behavior. Public method documentation should also state the return value—including meaningful boolean/status values, chaining returns, `undefined`, promises, and relevant thrown/rejected errors.
-
-A useful rule when extending the project is:
-
-> Introduce an abstraction when it gives a concern a clear home, not merely to create another layer.
+6. [`server/handler.ts`](server/handler.ts) — provider-neutral `Request`/`Response` composition.
+7. Tests — executable contracts for browser and generated-project behavior.
 
 ## Create a project
 
@@ -88,23 +128,13 @@ Requirement:
 
 - Node.js `^22.18.0` or `>=24.11.0`
 
-Install the CLI globally with your preferred package manager, or run the package directly.
-
-With npm:
+Run the package directly:
 
 ```sh
 npx generator-white-label create my-project
-```
-
-With Yarn:
-
-```sh
+# or
 yarn dlx generator-white-label create my-project
-```
-
-With pnpm:
-
-```sh
+# or
 pnpm dlx generator-white-label create my-project
 ```
 
@@ -115,7 +145,7 @@ npm install --global generator-white-label
 white-label create my-project
 ```
 
-After generation, use npm, Yarn, or pnpm consistently within the project:
+After generation, use one package manager consistently:
 
 ```sh
 cd my-project
@@ -124,25 +154,48 @@ npm install && npm test
 # or: pnpm install && pnpm test
 ```
 
-Interactive creation asks whether templates should use JSX/TSX. JSX is optional: choose **Yes** for White Label's first-party JSX syntax such as `<section>...</section>`, or **No** for plain TypeScript functions that return HTML strings. Both choices generate the same functional starter application.
+There is one canonical scaffold. The CLI has no renderer prompt and no `--jsx`/`--no-jsx` mode switch.
 
-Choose the no-JSX path when another template engine should own rendering. Install that engine in the generated application and call it from the View `template` function; no White Label adapter is required. White Label View currently tests Handlebars, Eta, EJS, Mustache, Nunjucks, and Pug in both browser and server rendering. See [Template engines and JSX options](https://whitelabeljs.org/docs/view/#template-engines) for tested versions, examples, the rendering contract, and security guidance.
+The generator refuses to layer a scaffold over an existing non-empty destination. This protection is enforced by the shared `createProject()` engine for both CLI and programmatic use. An existing empty directory is allowed; a missing directory is created.
 
-For explicit or non-interactive use:
+See [`CLI.md`](CLI.md), [`PACKAGE_MANAGERS.md`](PACKAGE_MANAGERS.md), and [`EXISTING_APPLICATIONS.md`](EXISTING_APPLICATIONS.md).
 
-```sh
-white-label create my-project --jsx
-white-label create my-project --no-jsx
+## Progressive enhancement and SEO
+
+The generated project renders meaningful HTML during the build. Interactive task filters are real links first and are enhanced with History API navigation after initialization.
 
-npx generator-white-label create my-project --jsx
-npx generator-white-label create my-project --no-jsx
+```text
+HTML owns semantics.
+JavaScript enhances behavior.
 ```
 
-The same `--jsx` and `--no-jsx` options work through `yarn dlx` and `pnpm dlx`.
+Public content should remain readable, navigable, and crawlable without executing the enhancement bundle. Generated pages include canonical URLs, page titles/descriptions, robots metadata, semantic navigation, JSON-LD, and sitemap-oriented output; deployment still needs to serve the generated files correctly.
+
+Do not treat metadata in source code as proof of search-engine indexing. Verify deployed behavior and indexing with actual production/search-console evidence.
+
+## A simple View click event
+
+Use View lifecycle hooks to add and remove browser listeners with the same callback reference:
+
+```ts
+import View from 'white-label-view';
+
+class ButtonView extends View {
+    handleClick = () => console.log('Clicked');
 
-If no interactive answer is available and neither flag is supplied, JSX is the default for backward compatibility.
+    addListeners() {
+        this.element.addEventListener('click', this.handleClick);
+        return this;
+    }
 
-See [`CLI.md`](CLI.md) for the CLI contract and [`PACKAGE_MANAGERS.md`](PACKAGE_MANAGERS.md) for package-manager compatibility details.
+    removeListeners() {
+        this.element.removeEventListener('click', this.handleClick);
+        return this;
+    }
+}
+```
+
+`addListeners()` runs when the View mounts. `removeListeners()` runs before replacement or destruction, so listener ownership remains explicit.
 
 ## Programmatic API
 
@@ -151,92 +204,45 @@ Project creation has one implementation:
 ```js
 import {createProject} from 'generator-white-label';
 
-// Resolves after the scaffold files and package manifest have been written.
 await createProject({
-    destination: new URL('./my-project', import.meta.url).pathname,
-    jsx: false
+    destination: new URL('./my-project', import.meta.url).pathname
 });
 ```
 
-Set `jsx: true` for JSX/TSX templates or `jsx: false` for plain TypeScript and HTML strings. Use `jsx: false` as the starting point for a third-party template engine. Omitting `jsx` defaults to `true`.
+`createProject(options)` returns `Promise<void>`. A successful call resolves with `undefined`; file-system failures reject. If the destination exists and contains files, it rejects before copying or writing project content.
+
+`createProject()` is the canonical creation API. The CLI and future integrations are adapters around it rather than separate generation systems. Keeping overwrite policy here prevents adapters from bypassing the same safety boundary.
+
+## Serverless and function runtimes
 
-`createProject(options)` returns `Promise<void>`. A successful call resolves with `undefined`; file-system failures reject the promise instead of returning a status value.
+Every generated project includes `server/handler.ts`, a provider-neutral example built around Web `Request` and `Response`. It composes Router, Mediator, Model, and `white-label-view/server` without Express or a provider SDK.
 
-`createProject()` is the canonical creation API. The CLI and future integrations are adapters around it rather than separate generation systems.
+Mutable White Label instances are created inside `handleRequest()`. Serverless hosts can reuse a warm process for many requests, so mutable module-level state can leak request data or listeners. Immutable configuration can still live at module scope when its lifetime is intentionally process-wide.
 
-This is the same design principle used throughout White Label: one responsibility, one implementation, explicit adapters at environment boundaries.
+Cloud-specific adapters should stay at the boundary: translate a provider request into a Web `Request` when needed, call `handleRequest()`, then translate the returned `Response` back only if required.
+
+Generated-project tests exercise sequential warm invocations, concurrent requests, request-data escaping, execution without browser globals, and a browser/Web-target bundle smoke test. They also enforce serverless composition size/import regression budgets. These are regression guards, not universal latency guarantees.
+
+The Web-target smoke test does **not** claim blanket Cloudflare/Deno/edge-provider compatibility. Published runtime packages document Node as their supported server runtime; verify a specific target before deployment.
 
 ## Source layout
 
 | Path | Purpose |
 | --- | --- |
-| `scaffold/index.ts` | Canonical `createProject()` implementation |
-| `scaffold/no-jsx/` | Plain-TypeScript template equivalents |
+| `scaffold/index.ts` | Canonical `createProject()` implementation and destination-safety boundary |
 | `cli/index.ts` | First-party command-line adapter |
-| `app/*.tsx` | Default JSX top-level static pages |
-| `app/assets/view/` | Default JSX views and page sections |
+| `app/*.ts` | Static pages using tagged HTML templates |
+| `app/assets/view/` | Reusable tagged-template views and sections |
 | `app/assets/script/tasks/` | Model/View/Mediator/Router example |
-| `server/handler.ts` | Provider-neutral serverless `Request` → `Response` example |
-| `scripts/build.ts` | Static rendering and asset build for `.ts` and `.tsx` pages |
+| `server/handler.ts` | Provider-neutral serverless Request → Response example |
+| `scripts/build.ts` | Static rendering and asset build |
 | `test/` | Executable contracts and integration tests |
-| `template-test/` | Generated-project validation, including serverless portability budgets |
-
-No React, Bootstrap, Sass, Eta, Handlebars, Mustache, Nunjucks, Pug, web fonts, cloud SDK, or browser-side template framework is required. Third-party template engines and provider adapters remain optional application dependencies.
+| `template-test/` | Generated-project validation |
 
-## Template choice: JSX or no JSX
-
-JSX is optional. When enabled, TypeScript uses the White Label JSX runtime:
-
-```json
-{
-  "compilerOptions": {
-    "jsx": "react-jsx",
-    "jsxImportSource": "white-label-view"
-  }
-}
-```
-
-A page remains an ordinary function:
-
-```tsx
-export default function Page(data: Record<string, unknown>) {
-    return <main><h1>{String(data.title)}</h1></main>;
-}
-```
-
-With `--no-jsx`, the equivalent page is ordinary TypeScript returning an HTML string instead. The application architecture and generated features remain the same. That no-JSX scaffold is also the intended starting point when Handlebars, Eta, EJS, Mustache, Nunjucks, Pug, or another renderer should remain the project's template convention.
-
-For larger pages, compose focused views instead of growing one renderer indefinitely.
-
-JSX expressions are escaped by default. In plain-TypeScript templates or third-party engines, applications own the engine's escaping and raw-output configuration. See [Template engines and JSX options](https://whitelabeljs.org/docs/view/#template-engines) for the tested matrix and trust boundaries.
-
-## Progressive enhancement
-
-The generated project renders meaningful HTML during the build. Interactive task filters are real links first and are enhanced with History API navigation after initialization.
-
-The principle is intentional:
-
-```text
-HTML owns semantics.
-JavaScript enhances behavior.
-```
-
-## Serverless and function runtimes
-
-Every generated project includes `server/handler.ts`, a provider-neutral example built around the Web `Request` and `Response` APIs. It composes Router, Mediator, Model, and `white-label-view/server` without Express or a provider SDK.
-
-Mutable White Label instances are created inside `handleRequest()`. This is intentional: serverless hosts can reuse a warm process for many requests, so mutable module-level Model/View/Router/Mediator instances can leak request data or listeners. Immutable configuration can still be shared at module scope when its lifetime is intentionally process-wide.
-
-Cloud-specific adapters should stay at the boundary. Translate an AWS/Vercel/Netlify/Azure/etc. request into a Web `Request` when necessary, call `handleRequest()`, and translate the returned `Response` back only if the provider requires it.
-
-Generated-project tests exercise sequential warm invocations, concurrent requests, request-data escaping, execution without browser globals, and a browser/Web-target bundle smoke test. They also enforce a 100 kB minified serverless-composition bundle budget and a 750 ms fresh-process handler-import budget. These are regression guards, not universal latency guarantees.
-
-The Web-target bundle smoke test catches unresolved Node built-ins, but it does **not** claim blanket Cloudflare/Deno/edge-provider compatibility. The published runtime packages still document Node as their supported server runtime; verify a specific edge provider before deployment.
+No React, Bootstrap, Sass, Eta, Handlebars, Mustache, Nunjucks, Pug, web font, cloud SDK, or browser-side template framework is required. Optional renderers/providers remain application dependencies.
 
 ## Build and verify
 
-The repository keeps npm as its canonical maintenance/audit path and committed lockfile. Generated projects support npm, Yarn, and pnpm.
-
 Development build:
 
 ```sh
@@ -263,13 +269,17 @@ npm run audit
 npm pack --dry-run
 ```
 
-Tests are part of the documentation. They demonstrate intended contracts while protecting behavior. Executable project source is held to 100% statement, branch, function, and line coverage.
+Tests are part of the documentation. Executable project source is held to 100% statement, branch, function, and line coverage. CI checks supported Node versions, packed CLI/programmatic installation, production builds, and generated-project compatibility across npm, Yarn, and pnpm.
+
+## Coordinated runtime release
+
+Generator 10 targets the published White Label runtime line: `white-label-mediator@5.0.0`, `white-label-model@7.0.1`, `white-label-router@6.1.0`, and `white-label-view@7.0.0`. Release and CI verification use those registry packages directly.
 
 ## White Label ecosystem
 
 - [`white-label-model`](https://github.com/bshack/white-label-model) — observable state.
-- [`white-label-view`](https://github.com/bshack/white-label-view) — rendering, DOM lifecycle, optional JSX, and a template-engine-agnostic rendering contract.
+- [`white-label-view`](https://github.com/bshack/white-label-view) — rendering, existing-DOM lifecycle, tagged HTML templates, server rendering, and a template-engine-agnostic contract.
 - [`white-label-mediator`](https://github.com/bshack/white-label-mediator) — application events.
-- [`white-label-router`](https://github.com/bshack/white-label-router) — routing and URL state.
+- [`white-label-router`](https://github.com/bshack/white-label-router) — progressive routing and URL state.
 
 The generated project imports the real packages rather than reproducing their behavior locally. That makes it both an example and an ecosystem integration test.