generator-white-label 9.0.0 → 10.0.0

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,59 +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.
-
-## 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');
-    };
-
-    addListeners() {
-        this.element.addEventListener('click', this.handleClick);
-        return this;
-    }
-
-    removeListeners() {
-        this.element.removeEventListener('click', this.handleClick);
-        return this;
-    }
-}
-```
-
-`addListeners()` runs when the View mounts. `removeListeners()` runs before replacement or destruction, so the listener lifecycle stays owned by the View.
-
-## Read the source
+A useful reading order is:
 
-For the default JSX scaffold, 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
 
@@ -114,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
 ```
 
@@ -141,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
@@ -150,27 +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
 
-If no interactive answer is available and neither flag is supplied, JSX is the default.
+Use View lifecycle hooks to add and remove browser listeners with the same callback reference:
 
-The generator refuses to layer a scaffold over an existing non-empty destination. This protection is enforced by the shared `createProject()` engine, so it applies to both the CLI and programmatic use. An existing empty directory is allowed; a missing directory is created as part of generation.
+```ts
+import View from 'white-label-view';
 
-See [`CLI.md`](CLI.md) for the CLI contract and [`PACKAGE_MANAGERS.md`](PACKAGE_MANAGERS.md) for package-manager compatibility details.
+class ButtonView extends View {
+    handleClick = () => console.log('Clicked');
+
+    addListeners() {
+        this.element.addEventListener('click', this.handleClick);
+        return this;
+    }
+
+    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
 
@@ -179,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
+
+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.
+
+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.
 
-`createProject(options)` returns `Promise<void>`. A successful call resolves with `undefined`; file-system failures reject the promise instead of returning a status value. If the destination already exists and contains files, it rejects before copying or writing project content.
+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.
 
-`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 accidentally bypassing the same safety boundary.
+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.
 
-This is the same design principle used throughout White Label: one responsibility, one implementation, explicit adapters at environment boundaries.
+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 and destination-safety boundary |
-| `scaffold/no-jsx/` | Plain-TypeScript template equivalents |
 | `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 |
+| `template-test/` | Generated-project validation |
 
-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 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.
-
-White Label JSX HTML-escapes ordinary child text and ordinary attribute values by default, rejects intrinsic `on*` event-handler attributes, and uses runtime-owned identity for trusted JSX/raw values. That escaping is not a general-purpose sanitizer for URL or CSS semantics. Plain-TypeScript templates and third-party engines likewise remain responsible for their own contextual escaping, sanitization, raw-output features, and 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 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
@@ -291,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. CI also checks the documented Node 22.18 minimum, the primary Node 24 line, packed CLI/programmatic API installation, and generated-project compatibility across npm, Yarn, and pnpm.
+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.
+The generated project imports the real packages rather than reproducing their behavior locally. That makes it both an example and an ecosystem integration test.

package/app/404.ts

@@ -0,0 +1,28 @@
+import {html} from 'white-label-view/html';
+
+interface PageData {
+    cdn: string;
+    version: string;
+    www: string;
+}
+
+export default function NotFoundPage(data: Record<string, unknown>) {
+    const page = data as unknown as PageData;
+    return html`<html lang="en-US" dir="ltr">
+            <head>
+                <meta charset="utf-8">
+                <meta name="viewport" content="width=device-width, initial-scale=1">
+                <meta name="robots" content="noindex,follow">
+                <title>Page not found | White Label</title>
+                <link rel="stylesheet" href="${page.cdn}release/${page.version}/assets/style/global.css">
+            </head>
+            <body>
+                <a class="skip-link" href="#main">Skip to the message</a>
+                <main id="main" tabindex="-1" class="mx-auto max-w-5xl px-4 py-24 sm:px-6 lg:px-8">
+                    <h1 class="text-5xl font-extrabold tracking-tight">Page not found</h1>
+                    <p class="mt-6 text-lg">The requested page does not exist.</p>
+                    <p class="mt-6"><a class="font-bold underline" href="${page.www}">Return to the White Label starter</a></p>
+                </main>
+            </body>
+        </html>`;
+}

package/app/README.md

@@ -1,10 +1,22 @@
 # White Label starter application
 
-This static starter was generated with the **JSX/TSX** template option. It uses TypeScript and the White Label JSX runtime for page and client-side View rendering, with Tailwind CSS 4 for styling. It makes no API or service calls.
+This static starter uses ordinary TypeScript and White Label View's first-party tagged HTML templates, with Tailwind CSS 4 for styling. It makes no API or service calls.
 
-JSX is optional in White Label. If you prefer plain TypeScript or want a third-party template engine to own rendering, generate with `--no-jsx` (or answer **No** to the generator's JSX question), then install and call that renderer from the View `template` function. The Model, View, Router, Mediator, progressive-enhancement behavior, and generated feature set remain equivalent.
+The rendering path is intentionally small and explicit:
 
-See [Template engines and JSX options](https://whitelabeljs.org/docs/view/#template-engines) for the tested third-party engines, rendering contract, and no-JSX setup.
+```ts
+import {html} from 'white-label-view/html';
+
+export default function Page(data: {title: string}) {
+    return html`<main><h1>${data.title}</h1></main>`;
+}
+```
+
+Dynamic text and quoted-attribute values are HTML-escaped by default. Use `attributes()` for conditional/opening-tag attributes. `unsafeHTML()` is an explicit trust boundary for application-owned content that is already trusted or sanitized; it is not a sanitizer.
+
+White Label View remains template-engine agnostic. If the application prefers JSX, Handlebars, Eta, EJS, Mustache, Nunjucks, Pug, or another renderer, add it to the application and return its rendered output from View's `template` function. JSX is a tested third-party option rather than a White Label runtime requirement.
+
+See [Template engines](https://whitelabeljs.org/docs/view/#template-engines) for tested integrations and rendering/security boundaries.
 
 ## Start developing
 
@@ -42,11 +54,11 @@ python3 -m http.server 8080 --directory _deploy
 
 Open `http://localhost:8080/`.
 
-Serve `_deploy` as the web server's document root. Do **not** browse to `_deploy/index.html` through a server rooted at the project directory (for example, `/white-label-site/_deploy/index.html`), because generated asset URLs such as `/release/local/assets/style/global.css` are intentionally rooted at the deployed site's origin and will otherwise return 404 responses.
+Serve `_deploy` as the web server's document root. Do **not** browse to `_deploy/index.html` through a server rooted at the project directory, because generated asset URLs such as `/release/local/assets/style/global.css` are intentionally rooted at the deployed site's origin.
 
-The build output is `_deploy`. The test suite checks the starter content, progressive interaction, production build, accessibility/indexability signals, serverless request isolation, Web-standard bundling, and serverless size/startup budgets.
+The build output is `_deploy`. The test suite checks starter content, progressive interaction, production build behavior, accessibility/indexability signals, serverless request isolation, Web-standard bundling, and serverless size/startup budgets.
 
-Pages live in `app/*.tsx`, page data lives in `app/assets/data/view`, browser code lives in `app/assets/script`, the provider-neutral serverless example lives in `server/handler.ts`, and shared styles live in `app/assets/style`. TypeScript is configured with `jsx: react-jsx` and `jsxImportSource: white-label-view`, so this scaffold's JSX does not require React.
+Pages live in `app/*.ts`, page data lives in `app/assets/data/view`, browser code lives in `app/assets/script`, the provider-neutral serverless example lives in `server/handler.ts`, and shared styles live in `app/assets/style`.
 
 ## Simple View click event
 
@@ -100,4 +112,4 @@ npm run build -- --version=release-1 --production=true --site-url=https://www.ex
 
 Build flags use `--key=value`. `--www` and `--cdn` default to `/`; `--version` selects `_deploy/release/<version>/assets`; without a version, the current timestamp is used. Production builds require a real HTTPS `--site-url` for canonical, Open Graph, robots, and sitemap output. Each build replaces `_deploy`.
 
-Edit TypeScript/TSX sources, not `dist`. JSX expressions are escaped by the White Label runtime; reserve `raw()` for trusted application-authored markup. Replace the starter copy with application content while retaining the tested accessibility and progressive-enhancement patterns.
+Edit TypeScript sources, not `dist`. Keep untrusted values in normal `html` interpolations; use `unsafeHTML()` only when the application has deliberately established trust or sanitization. Replace the starter copy with application content while retaining the tested accessibility and progressive-enhancement patterns.

package/{scaffold/no-jsx/app → app}/assets/script/index.ts

@@ -1,6 +1,7 @@
 /** @module app/assets/script/index */
 import {initializeTaskApplication} from './tasks/TaskApplication.js';
 
+/** Start the feature composition for this document. */
 export {initializeTaskApplication} from './tasks/TaskApplication.js';
 export {normalizeTaskFilter} from './tasks/TaskRouter.js';
 

package/{scaffold/no-jsx/app → app}/assets/script/tasks/TaskView.ts

@@ -3,7 +3,7 @@ import TaskExample from '../../view/examples/tasks/TaskExample.js';
 import type {TaskState} from '../../view/examples/tasks/task-state.js';
 import type TaskModel from './TaskModel.js';
 
-/** Create the task view without JSX/TSX syntax. */
+/** Adopt the build-time task root and reuse the same tagged template for model updates. */
 export function createTaskView(parentElement: HTMLElement, model: TaskModel): View {
     const element = parentElement.querySelector<HTMLElement>('[data-task-app]');
     if (!element) {throw new TypeError('Task example requires its static task-app root');}

package/app/assets/view/CodeBlock.ts

@@ -0,0 +1,15 @@
+import {html, type HTMLMarkup} from 'white-label-view/html';
+
+export const syntax = {
+    keyword: 'code-syntax-keyword',
+    type: 'code-syntax-type',
+    value: 'code-syntax-value',
+    muted: 'code-syntax-muted'
+};
+
+/** Render a readable code example with stable line numbers and caller-supplied syntax spans. */
+export default function CodeBlock({lines}: {lines: HTMLMarkup[]}) {
+    return html`<pre class="code-block"><code>${lines.map((line, index) => html`<span class="code-block__line">
+                <span aria-hidden="true" class="code-block__number">${index + 1}</span><span>${line}</span>
+            </span>`)}</code></pre>`;
+}

package/app/assets/view/examples/tasks/TaskExample.ts

@@ -0,0 +1,50 @@
+import {attributes, html} from 'white-label-view/html';
+import {getVisibleTasks, type TaskFilter, type TaskState} from './task-state.js';
+
+const filters: TaskFilter[] = ['all', 'active', 'completed'];
+
+/** Render the task example from state for both build-time HTML and browser updates. */
+export default function TaskExample({state}: {state: TaskState}) {
+    const visibleTasks = getVisibleTasks(state);
+    const completed = state.tasks.filter(task => task.complete).length;
+
+    return html`<section class="task-app" data-task-app aria-label="Interactive task example">
+            <form class="task-form" data-task-form action="#example" method="get">
+                <label for="task-title">New task</label>
+                <div class="task-form__controls">
+                    <input id="task-title" name="task" type="text" autocomplete="off" required>
+                    <button type="submit">Add task</button>
+                </div>
+            </form>
+
+            <nav class="task-filters" aria-label="Filter tasks">
+                ${filters.map(filter => html`<a ${attributes({
+                    href: `/?tasks=${filter}#example`,
+                    'data-task-filter': filter,
+                    'data-pushstate': true,
+                    'aria-current': state.filter === filter ? 'page' : 'false'
+                })}>${filter.charAt(0).toUpperCase()}${filter.slice(1)}</a>`)}
+            </nav>
+
+            <ul class="task-list">
+                ${visibleTasks.map(task => html`<li>
+                        <label>
+                            <input ${attributes({
+                                type: 'checkbox',
+                                checked: task.complete,
+                                'data-task-toggle': true,
+                                'data-task-id': task.id
+                            })}>
+                            <span>${task.title}</span>
+                        </label>
+                    </li>`)}
+            </ul>
+
+            <dl class="demo__trace">
+                <div><dt>Router</dt><dd>/?tasks=${state.filter}</dd></div>
+                <div><dt>Mediator</dt><dd>task:* application events</dd></div>
+                <div><dt>Model</dt><dd>${state.tasks.length} tasks · ${completed} complete</dd></div>
+                <div><dt>View</dt><dd>${visibleTasks.length} tasks rendered</dd></div>
+            </dl>
+        </section>`;
+}

package/app/assets/view/examples/tasks/task-state.ts

@@ -1,4 +1,4 @@
-/** Shared state shape used by build-time JSX and the browser application. */
+/** Shared state shape used by build-time tagged HTML and the browser application. */
 export type TaskFilter = 'all' | 'active' | 'completed';
 
 export interface TaskItem {

package/app/assets/view/layout/SiteFooter.ts

@@ -0,0 +1,11 @@
+import {html} from 'white-label-view/html';
+
+/** Keep reusable static page chrome as a small tagged-template function. */
+export default function SiteFooter() {
+    return html`<footer class="site-footer">
+            <div class="container site-footer__inner">
+                <p>White Label. Framework-independent TypeScript building blocks.</p>
+                <a href="#top">Back to top</a>
+            </div>
+        </footer>`;
+}

package/app/assets/view/layout/SiteHeader.ts

@@ -0,0 +1,17 @@
+import {html} from 'white-label-view/html';
+
+/** Static navigation remains ordinary crawlable HTML; JavaScript enhances only opted-in links. */
+export default function SiteHeader() {
+    return html`<header class="site-header">
+            <div class="container site-header__inner">
+                <a class="wordmark" href="#top">White Label</a>
+                <nav aria-label="Primary navigation">
+                    <a href="#example">Example</a>
+                    <a href="#packages">Packages</a>
+                    <a href="#source">Source</a>
+                    <a href="#start">Get started</a>
+                    <a href="https://github.com/bshack/white-label">GitHub</a>
+                </nav>
+            </div>
+        </header>`;
+}

package/app/assets/view/page-data.ts

@@ -1,8 +1,8 @@
 /**
  * Build-time data available to every page template.
  *
- * Keeping this contract separate from the page component makes the top-level
- * JSX read like application composition instead of deployment plumbing.
+ * Keeping this contract separate from the renderer keeps top-level tagged
+ * HTML focused on application composition instead of deployment plumbing.
  */
 export interface PageData {
     cdn: string;