diff --git a/.agents/skills/webjs/SKILL.md b/.agents/skills/webjs/SKILL.md
index d2d9b071d..0591ba15c 100644
--- a/.agents/skills/webjs/SKILL.md
+++ b/.agents/skills/webjs/SKILL.md
@@ -80,6 +80,7 @@ The table above routes by the job; this one routes by the topic, for when you al
 | Server actions, mutations, queries, validation, the `ActionResult` envelope | `references/data-and-actions.md`              |
 | Sessions, login flows, route protection, `forbidden()` / `unauthorized()`   | `references/auth-and-sessions.md`             |
 | Tailwind, light-DOM tag-prefix rule, tokens, fixed headers, no-reflow layout | `references/styling.md`                        |
+| Where a repeated markup helper lives (`utils/ui/` vs `lib/`), and fragment vs display-only component | `references/styling.md`                        |
 | Client router, prefetch, frames, view transitions, Suspense streaming        | `references/client-router-and-streaming.md`   |
 | Optimistic UI for a user-facing mutation                                     | `references/optimistic-ui.md`                 |
 | The `@webjsdev/ui` component kit (a `components.json` is present): class helpers, tokens, `add` / `view`, the MCP `ui` tool | `references/ui-kit.md`                         |
@@ -122,8 +123,10 @@ app/                  ROUTING ONLY (thin adapters importing from modules/)
   error.ts loading.ts not-found.ts forbidden.ts unauthorized.ts   boundaries (nearest wins)
 middleware.ts         root middleware
 modules/<feature>/    actions/ (mutations, *.server.ts), queries/ (reads, *.server.ts),
-                      components/, utils/ (pure), types.ts
-lib/                  lib/*.server.ts server-only infra, lib/utils/ browser-safe helpers
+                      components/ (custom elements), types.ts,
+                      utils/ (pure; returns data, or an html fragment under utils/ui/)
+lib/                  lib/*.server.ts server-only infra, lib/utils/ browser-safe helpers,
+                      lib/utils/ui.ts app-wide html fragments (lib/ui/ once they grow)
 components/*.ts        shared presentational custom elements (one per file)
 db/*.server.ts        Drizzle: schema, connection
 public/*              static assets, served at /public/<name>
diff --git a/.agents/skills/webjs/references/styling.md b/.agents/skills/webjs/references/styling.md
index 18f8e3200..40fff09a6 100644
--- a/.agents/skills/webjs/references/styling.md
+++ b/.agents/skills/webjs/references/styling.md
@@ -36,7 +36,20 @@ When custom CSS IS unavoidable inside a light-DOM component, the tag-prefix inva
 
 ## DRY via a JS helper, not `@apply`
 
-When the same Tailwind bundle repeats across 2+ places, extract it into a helper in `lib/utils/ui.ts` that returns an `html` fragment (SSR-time, no client runtime, output identical to inline classes):
+When the same Tailwind bundle repeats across 2+ places, extract it into a helper that returns an `html` fragment (SSR-time, no client runtime, output identical to inline classes). Where the helper LIVES follows the narrowest-owner rule, so pick the tier by who consumes it:
+
+| Consumers | Home |
+|---|---|
+| routes across the app (a heading, a lede, a back link) | `lib/utils/ui.ts` |
+| one feature (a todo row, a comment card, a board) | `modules/<feature>/utils/ui/<name>.ts` |
+
+One file per fragment under `utils/ui/`, because a feature accumulates several and one-per-file keeps them greppable. A fragment promotes from the feature tier to `lib/` only when a second feature genuinely consumes it.
+
+The app-wide tier grows the same way, on the same judgment `references/module-structure.md` applies to any module. `lib/utils/ui.ts` is where it starts and where it usually stays: small, independent, one-element helpers belong together in one file, however many of them there are (the blog example keeps nine there quite happily). Split to `lib/ui/<name>.ts`, one file per fragment, when a fragment stops being a one-liner, when one composes others, or when the single file is no longer scannable. The framework's own website crossed that line and its four composed page fragments live in `lib/ui/`.
+
+So `modules/<feature>/utils/ui/`, `lib/utils/ui.ts`, and `lib/ui/` are one convention at three sizes rather than three conventions, and the `ui` segment is the part carrying the meaning at every one of them: inside `modules/<feature>/`, `components/` holds custom elements, `utils/ui/` holds functions returning a `TemplateResult`, and the rest of `utils/` holds functions returning data. Drop the segment and a view fragment ends up beside a pure data helper with nothing in the path to tell them apart.
+
+The example below is the app-wide tier:
 
 ```ts
 import { html } from '@webjsdev/core';
@@ -62,12 +75,44 @@ export default function Post({ params }) {
 | Repeats | Action |
 |---|---|
 | Once | Inline the classes. |
-| 2 to 3 times, identical | Extract to `lib/utils/ui.ts`. |
+| 2 to 3 times, identical, inside ONE feature | Extract to `modules/<feature>/utils/ui/<name>.ts`. |
+| 2 to 3 times, identical, across features or routes | Extract to `lib/utils/ui.ts`. |
 | Varies by 1 to 2 props | Extract with a small parameter (`mb: 'sm' \| 'md'`). |
 | Radically different per call site | Keep inline, do not force-fit. |
 
 Avoid `@apply`: it hides which utilities a class uses and creates a second source of truth. A JS helper keeps the bundle visible at the definition site, composes with conditional classes and active states, and runs at SSR time.
 
+### Fragment or display-only component?
+
+Two questions, in order.
+
+**First, is this a UNIT or a repeated CLASS BUNDLE?** The helpers this section began with (a heading, a lede, a back link) are the second kind: one element with a class list you did not want to type twice. That is a fragment by definition and never a component; nobody wants `<page-lede>` as a tag in their DOM, and promoting a class bundle to an element is the same over-reach as absorbing a page section into an island. The question below only arises for a genuine unit of markup (a row, a card, a board) that could reasonably be either.
+
+**Second, for a unit: can the markup carry an extra wrapper element at all?** A component is a tag in the DOM, so choosing one adds a node between the parent and the markup. Usually that is fine and the component is the better choice, since it gets a tag name to target and can grow behaviour later. Two cases make it impossible outright:
+
+| Case | What happens |
+|---|---|
+| a `<table>` / `<tbody>` child | the parser FOSTER-PARENTS the element out of the table (an HTML spec rule, not a WebJs one), so it lands BEFORE the table and its cells are adopted by a `<tr>` it no longer owns. The component never renders where you put it |
+| output that is not DOM | a `<webjs-stream>` payload, or HTML a `route.ts` returns, is a STRING, and a component has no way to produce one |
+
+Three more render fine and are wrong in ways that surface later, so treat them as strong reasons rather than hard blocks. Measured in Chromium, the element survives in all three:
+
+| Case | What survives, what breaks |
+|---|---|
+| a `<ul>` / `<ol>` / `<dl>` child | the list renders, but `ul > li`, `:nth-child`, and list markers now see the wrapper instead of the row |
+| a `<select>` child | the control still offers a wrapped `<option>` (it is in `select.options`), but it is no longer `select > option`, so selector-based CSS and DOM code miss it, and the content model is invalid |
+| a `grid` / `flex` child | the wrapper becomes THE ITEM, so the children you meant to lay out sit one level too deep and the track sizing applies to the wrong box |
+
+Everywhere else the two are interchangeable, and the remaining difference is cost. Be precise about that too, because the obvious summary ("fragments are free, components ship") is wrong in both directions.
+
+**Rendered only by pages, they cost the same: nothing.** A page is inert or import-only, so a fragment it calls runs at SSR and is never fetched. A component that does no client work is elided, so it is never fetched either. Byte arguments do not decide this case; pick whichever reads better.
+
+**Rendered by a shipping island, BOTH ship.** A module a shipping component imports is fetched, fragment or not, so the fragment's function is downloaded too (verify it yourself: watch the network panel for the helper's path). What differs is what else comes with it. The component ships a custom element class plus its registration and upgrades once per instance, and, because elision propagates downward, it un-elides every display-only component IT renders. The fragment ships a function and stops there.
+
+So near an island the fragment is the smaller and more predictable choice, not a free one, and the gap is a class and its blast radius rather than everything. That is a tiebreaker, not a rule: it is worth acting on where a shipping island is or might become the renderer, and not worth reorganising page-level markup over. When it matters, measure with `webjs elision` rather than reasoning from either rule of thumb.
+
+**The summary.** A repeated class bundle is always a fragment. For a real unit, take the fragment where a wrapper element cannot exist (a table child, or string output) and where it would land wrong (a list, select, grid, or flex child); take the component whenever the markup needs behaviour, wants a tag to target, or might grow either; and treat the byte difference as the last consideration rather than the first.
+
 ### A design system for repeated PRIMITIVES: class helpers built on `@webjsdev/ui`
 
 An `html`-fragment helper is right for a repeated CHUNK of markup (the rubric above). For a repeated UI PRIMITIVE (button, input, card, badge) that needs variants and sizes, use a class helper instead: a function that returns a Tailwind class STRING you spread onto a native element. That is exactly what `@webjsdev/ui` ships (`buttonClass({ variant, size })`, `cardClass()`, `inputClass()`, `badgeClass({ variant })`), and it is what the scaffold gallery uses in `components/ui/`. To style a ONE-OFF that a variant does not cover (a circular icon button, a pill), compose the helper and override the bespoke bits with `cn()`: `cn(buttonClass({ variant: 'secondary', size: 'none' }), 'w-9 h-9 rounded-full')`. `cn` resolves Tailwind conflicts so a later class wins, including a shorthand over the axis it subsumes (`p-0` beats an earlier `px-4 py-2`), so an override just works. Conflicts are keyed on the CSS PROPERTY wherever `cn` can tell the properties apart, rather than on the shared class prefix, so the common prefix collisions do NOT evict: `cn('border-2', 'border-primary')` keeps both (a width and a colour), `cn('flex', 'flex-1')` keeps both (a `display` and a `flex-grow`, the shape an element that is both a flex container and a flex child needs), `cn('shadow-lg', 'shadow-red-500')` keeps both (a box-shadow and its colour), `cn('bg-clip-text', 'bg-primary')` keeps both (a clip and a colour, so the gradient-text idiom survives a later background), and an arbitrary value carrying a type hint is read as the property the hint names (`cn('shadow-lg', 'shadow-[color:red]')` keeps both). It is a small hand-rolled merger, not `tailwind-merge`, so it is still coarse in two ways. A prefix outside the families it knows is not grouped at all, so both classes are emitted and the winner is left to compiled stylesheet order (`inset-shadow-sm` against `inset-shadow-red-500`, `ring-2` against `ring-red-500`). And where one prefix carries two properties it reads the value against Tailwind's DEFAULT scales, so a `@theme`-extended name it cannot know about can still be misread and evict the wrong class: a custom `--shadow-card` makes `shadow-card` a box-shadow, but `cn` sees an unfamiliar name under a prefix whose bare names are usually colours and treats it as one. When an override has to win and you are unsure, pass the one class rather than layering, or install `clsx` + `tailwind-merge` and replace the helper (its header comment shows the swap). For an icon button prefer `size: 'none'` (it states "I supply my own box" by dropping the helper's padding + radius) over layering a `p-0` on top of the default size.
diff --git a/AGENTS.md b/AGENTS.md
index a302a606e..023767c6f 100644
--- a/AGENTS.md
+++ b/AGENTS.md
@@ -411,7 +411,7 @@ Derive the type at every boundary: a DB row from the schema (`typeof todos.$infe
 
 ## Styling: Tailwind-first
 
-**Tailwind is the strong default for pages AND light-DOM components.** The lit reflex to scope CSS in a shadow root with `static styles` is the habit to resist in light DOM. When a class bundle repeats, extract it into a `lib/utils/ui.ts` helper returning an `` html`...` `` fragment (SSR-time), NOT a CSS class (no `@apply`). Reserve raw CSS for what utilities cannot express (design tokens / `@theme`, `@property` + `@keyframes`, scrollbar, `prefers-reduced-motion`, complex `color-mix()` / gradients); in light DOM the tag-prefix invariant (#7) still holds, and shadow-DOM components legitimately use `static styles = css\`\``. **Pin a header with `position: fixed`, never `position: sticky`** (a sticky header flickers on iOS WebKit during a client-router nav, #610, because the preserved header plus the scroll-to-top trips a WebKit sticky-repaint bug that the GPU-promotion hacks do NOT fix, so reserve the header height on the content with a `--header-height` offset). See `references/styling.md`.
+**Tailwind is the strong default for pages AND light-DOM components.** The lit reflex to scope CSS in a shadow root with `static styles` is the habit to resist in light DOM. When a class bundle repeats, extract it into a helper returning an `` html`...` `` fragment (SSR-time), NOT a CSS class (no `@apply`); it lives in `modules/<feature>/utils/ui/` when one feature consumes it and `lib/utils/ui.ts` when the whole app does. Choose between a fragment and a display-only component on STRUCTURE, not bytes: a component is a tag in the DOM, so reach for the fragment where that extra wrapper cannot exist at all (a `<table>` child, which the parser foster-parents out per the HTML spec, and string output such as a `<webjs-stream>` payload) or where it lands wrong (a `<ul>` / `<dl>` / `<select>` child, which breaks `ul > li` and `select > option`, and a grid or flex child, which makes the wrapper the item), and prefer the component everywhere else. On cost they tie under a page (inert page, elided component) and both ship under an island, where the component additionally carries an element class, its registration, a per-instance upgrade, and the display-only components it renders. Reserve raw CSS for what utilities cannot express (design tokens / `@theme`, `@property` + `@keyframes`, scrollbar, `prefers-reduced-motion`, complex `color-mix()` / gradients); in light DOM the tag-prefix invariant (#7) still holds, and shadow-DOM components legitimately use `static styles = css\`\``. **Pin a header with `position: fixed`, never `position: sticky`** (a sticky header flickers on iOS WebKit during a client-router nav, #610, because the preserved header plus the scroll-to-top trips a WebKit sticky-repaint bug that the GPU-promotion hacks do NOT fix, so reserve the header height on the content with a `--header-height` offset). See `references/styling.md`.
 
 ---
 
diff --git a/examples/blog/CONVENTIONS.md b/examples/blog/CONVENTIONS.md
index f77ce5203..97b89faad 100644
--- a/examples/blog/CONVENTIONS.md
+++ b/examples/blog/CONVENTIONS.md
@@ -501,7 +501,10 @@ and available everywhere via utility classes (`text-foreground`, `bg-card`,
 
 **Dedup repeated Tailwind class bundles with JS helpers, not `@apply`.**
 When the same string of classes appears in 2+ places, extract it into a
-small function in `lib/utils/ui.ts`:
+small function returning an `html` fragment. App-wide chunks live in
+`lib/utils/ui.ts` (this file's examples); a chunk only one feature draws
+lives in `modules/<feature>/utils/ui/<name>.ts` instead, so a view helper
+never sits unlabelled beside the pure data helpers in `utils/`:
 
 ```ts
 // lib/utils/ui.ts
diff --git a/gallery/modules/stream/components/browser/stream-demo.test.js b/gallery/modules/stream/components/browser/stream-demo.test.js
new file mode 100644
index 000000000..65564b9bd
--- /dev/null
+++ b/gallery/modules/stream/components/browser/stream-demo.test.js
@@ -0,0 +1,64 @@
+// Co-located browser test for the stream demo, in real Chromium with real SSR
+// and hydration. The runner UI is `tdd` (suite/test) and there is no assertion
+// library, so a tiny inline assert does the job.
+//
+// This pins the one thing the row fragment has to get right: the SEEDED rows
+// (rendered from the html`` shape) and the STREAMED rows (rendered from the
+// string shape) come off one class list, so a mutation cannot leave the list
+// styled two ways. Both shapes are exercised through the real component.
+import { html } from '@webjsdev/core';
+import { ssrFixture } from '@webjsdev/core/testing';
+import '../stream-demo.ts';
+
+const assert = (cond, msg) => { if (!cond) throw new Error(msg || 'assertion failed'); };
+const rows = (el) => [...el.querySelectorAll('#stream-list > li')];
+const button = (el, label) => [...el.querySelectorAll('button')].find((b) => b.textContent.trim() === label);
+const tick = () => new Promise((r) => setTimeout(r, 0));
+
+suite('<stream-demo>', () => {
+  test('SSRs the two seeded rows as direct list children', async () => {
+    const el = await ssrFixture(html`<stream-demo></stream-demo>`);
+    const ids = rows(el).map((li) => li.id);
+    assert(ids.join(',') === 'row-1,row-2', `seeded ids, got ${ids}`);
+    // A direct child, no wrapper element between the list and the row. That is
+    // the structural reason the row is a fragment and not a display-only element.
+    assert(rows(el).every((li) => li.parentElement.id === 'stream-list'), 'rows are direct children of the list');
+  });
+
+  test('a streamed row carries the same classes as a seeded row', async () => {
+    const el = await ssrFixture(html`<stream-demo></stream-demo>`);
+    const seeded = rows(el)[0].className;
+    button(el, 'Append').click();
+    await tick();
+    const all = rows(el);
+    assert(all.length === 3, `three rows after append, got ${all.length}`);
+    const streamed = all[2];
+    assert(streamed.id === 'row-3', `appended row is row-3, got ${streamed.id}`);
+    assert(streamed.className === seeded, `streamed row classes match seeded:\n  ${streamed.className}\n  ${seeded}`);
+  });
+
+  test('the string shape escapes its holes', async () => {
+    // The html`` shape escapes its own holes; this plain-string one has to do
+    // it by hand, and it is the shape a reader copies. A raw value here would
+    // become markup as soon as renderStream() inserted it.
+    const { streamRowHTML } = await import('../../utils/ui/row.ts');
+    const out = streamRowHTML('x" onload="boom', '<img src=x onerror=boom>');
+    assert(!out.includes('<img'), `text hole is escaped, got ${out}`);
+    assert(!out.includes('" onload'), `attribute hole is escaped, got ${out}`);
+  });
+
+  test('replace keeps the id and reset restores the seed list', async () => {
+    const el = await ssrFixture(html`<stream-demo></stream-demo>`);
+    button(el, 'Replace Row 1').click();
+    await tick();
+    assert(rows(el)[0].id === 'row-1', 'replace keeps row-1');
+    assert(rows(el)[0].textContent.includes('replaced'), 'replace swaps the content');
+    button(el, 'Prepend').click();
+    await tick();
+    button(el, 'Reset').click();
+    await tick();
+    const ids = rows(el).map((li) => li.id);
+    assert(ids.join(',') === 'row-1,row-2', `reset restores the seed list, got ${ids}`);
+    assert(rows(el)[0].textContent.trim() === 'Row 1', 'reset restores the seed content');
+  });
+});
diff --git a/gallery/modules/stream/components/stream-demo.ts b/gallery/modules/stream/components/stream-demo.ts
index fca370a52..ba474cc2b 100644
--- a/gallery/modules/stream/components/stream-demo.ts
+++ b/gallery/modules/stream/components/stream-demo.ts
@@ -13,6 +13,15 @@
 // region-swap would clobber.
 import { WebComponent, html, renderStream } from '@webjsdev/core';
 import { buttonClass } from '#components/ui/button.ts';
+// The row markup lives in ONE place, a feature-local view fragment under
+// `utils/ui/` (see references/styling.md for that folder). A fragment rather
+// than a display-only <stream-row> element because BOTH of this demo's uses
+// rule an element out, which is the test to apply: the seeded list needs a
+// direct `<ul> > <li>` child (a wrapper tag would sit between them and break
+// the selector and the list semantics), and the streamed payload is an HTML
+// STRING, which a component cannot produce at all. Where a wrapper IS fine,
+// prefer the component.
+import { streamRow, streamRowHTML } from '../utils/ui/row.ts';
 
 // Build a <webjs-stream> payload string. It is a plain string (NOT an html``
 // template), so interpolating the row markup here is fine. `remove` needs no
@@ -22,9 +31,6 @@ function streamPayload(action: string, target: string, inner = '') {
   return `<webjs-stream action="${action}" target="${target}">${body}</webjs-stream>`;
 }
 
-const rowCls = 'flex items-center gap-2 px-3 py-2 rounded-xl bg-card border border-border text-[15px] text-foreground';
-const row = (id: string, label: string) => `<li id="${id}" class="${rowCls}">${label}</li>`;
-
 export class StreamDemo extends WebComponent {
   // A plain instance field, NOT a signal: incremented to mint unique row ids.
   // It is never read inside render(), so appending a row does not re-render the
@@ -37,16 +43,16 @@ export class StreamDemo extends WebComponent {
   // never runs. Name your handlers something else (see muscle-memory-gotchas).
   appendRow() {
     this.#n++;
-    renderStream(streamPayload('append', 'stream-list', row(`row-${this.#n}`, `Row ${this.#n} (appended)`)));
+    renderStream(streamPayload('append', 'stream-list', streamRowHTML(`row-${this.#n}`, `Row ${this.#n} (appended)`)));
   }
   prependRow() {
     this.#n++;
-    renderStream(streamPayload('prepend', 'stream-list', row(`row-${this.#n}`, `Row ${this.#n} (prepended)`)));
+    renderStream(streamPayload('prepend', 'stream-list', streamRowHTML(`row-${this.#n}`, `Row ${this.#n} (prepended)`)));
   }
   replaceFirst() {
     // `replace` swaps the target element itself. The replacement keeps id row-1,
     // so the button stays repeatable.
-    renderStream(streamPayload('replace', 'row-1', row('row-1', 'Row 1 (replaced)')));
+    renderStream(streamPayload('replace', 'row-1', streamRowHTML('row-1', 'Row 1 (replaced)')));
   }
   removeSecond() {
     // `remove` deletes the target and needs no <template>.
@@ -54,7 +60,7 @@ export class StreamDemo extends WebComponent {
   }
   reset() {
     // `update` replaces the target's children, restoring the seed list.
-    renderStream(streamPayload('update', 'stream-list', row('row-1', 'Row 1') + row('row-2', 'Row 2')));
+    renderStream(streamPayload('update', 'stream-list', streamRowHTML('row-1', 'Row 1') + streamRowHTML('row-2', 'Row 2')));
   }
 
   render() {
@@ -71,8 +77,7 @@ export class StreamDemo extends WebComponent {
         <!-- The target list. renderStream() mutates it by id; this markup renders
              once and is never re-rendered by the component. -->
         <ul id="stream-list" class="grid gap-2 m-0 p-0 list-none">
-          <li id="row-1" class="flex items-center gap-2 px-3 py-2 rounded-xl bg-card border border-border text-[15px] text-foreground">Row 1</li>
-          <li id="row-2" class="flex items-center gap-2 px-3 py-2 rounded-xl bg-card border border-border text-[15px] text-foreground">Row 2</li>
+          ${streamRow('row-1', 'Row 1')}${streamRow('row-2', 'Row 2')}
         </ul>
       </div>
     `;
diff --git a/gallery/modules/stream/utils/ui/row.ts b/gallery/modules/stream/utils/ui/row.ts
new file mode 100644
index 000000000..8ad3536b5
--- /dev/null
+++ b/gallery/modules/stream/utils/ui/row.ts
@@ -0,0 +1,41 @@
+// A feature-local VIEW FRAGMENT: pure, returns markup, used only by the stream
+// demo. It lives in `modules/<feature>/utils/ui/` rather than `utils/` (which
+// holds helpers returning DATA) or `components/` (which holds custom elements).
+// See .agents/skills/webjs/references/styling.md.
+//
+// WHY a fragment and not a display-only <stream-row> element: an element is a
+// tag in the DOM, and neither caller can carry one. The list wants a direct
+// `<ul> > <li>` child, so a wrapper would break that selector and the list
+// semantics; and <webjs-stream> takes its payload as an HTML STRING, which no
+// component can return. That is the test, not bytes: where a wrapper element is
+// harmless, reach for the component instead.
+//
+// Hence the two shapes below, off one class list, so the streamed row and the
+// seeded rows cannot drift apart. That drift was live: the class list used to
+// exist three times in this feature, once in a `rowCls` const and twice inlined
+// in the component's own template, which did not use the const.
+import { html, escapeAttr, escapeText } from '@webjsdev/core';
+
+const ROW =
+  'flex items-center gap-2 px-3 py-2 rounded-xl bg-card border border-border text-[15px] text-foreground';
+
+/**
+ * The row as a template, for the component's own render(). `unknown` on the
+ * label because it forwards straight into an `html` hole, which renders a
+ * string, a number, a TemplateResult, or an array of those.
+ */
+export function streamRow(id: string, label: unknown) {
+  return html`<li id=${id} class=${ROW}>${label}</li>`;
+}
+
+/**
+ * The same row as an HTML string, for a <webjs-stream> template payload.
+ *
+ * ESCAPE EVERY HOLE HERE. The `html` tag above escapes its own holes; this
+ * plain template literal does NOT, so an unescaped value becomes markup the
+ * moment renderStream() puts it in the document. The demo only ever passes its
+ * own literals, but this is the shape people copy, so it does the safe thing.
+ */
+export function streamRowHTML(id: string, label: string): string {
+  return `<li id="${escapeAttr(id)}" class="${ROW}">${escapeText(label)}</li>`;
+}
diff --git a/website/AGENTS.md b/website/AGENTS.md
index 6f2284ce7..72f5db7fb 100644
--- a/website/AGENTS.md
+++ b/website/AGENTS.md
@@ -207,7 +207,12 @@ folder once it reaches about three related files. The design system
 (`lib/design/`) and the composed page fragments (`lib/ui/`) both crossed that
 bar; `links.ts` and `samples.ts` have not, so they stay loose. Fragments in
 `lib/ui/` are one file per fragment for the same reason the framework keeps
-one action per file: the filename is the index.
+one action per file: the filename is the index. This is the app-wide fragment
+tier at its grown-up size; the skill's `references/styling.md` names all three
+sizes (`modules/<feature>/utils/ui/` for one feature, `lib/utils/ui.ts` for
+app-wide helpers, `lib/ui/` for a subsystem like this one). An app with a
+handful of small helpers is right to keep them in `lib/utils/ui.ts` instead;
+this site split because its fragments compose.
 
 The site is intentionally one page in long-form scroll. When you edit
 copy, find the section in `app/page.ts` (search for the visible text
diff --git a/website/app/docs/conventions/page.ts b/website/app/docs/conventions/page.ts
index eac3f63ae..5852eba43 100644
--- a/website/app/docs/conventions/page.ts
+++ b/website/app/docs/conventions/page.ts
@@ -14,7 +14,7 @@ export default function Conventions() {
       <li><strong>Module architecture</strong>: where actions, queries, and components go.</li>
       <li><strong>Testing rules</strong>: when unit vs E2E tests are required.</li>
       <li><strong>Component patterns</strong>: light DOM by default with Tailwind, shadow DOM opt-in, <code>Class.register('tag')</code>, and the class-prefix rule for light-DOM custom CSS.</li>
-      <li><strong>Styling convention</strong>: a static compiled Tailwind stylesheet (<code>css:build</code>) + <code>@theme</code> tokens, JS helpers in <code>lib/utils/ui.ts</code> to dedupe repeated class bundles, no <code>@apply</code>.</li>
+      <li><strong>Styling convention</strong>: a static compiled Tailwind stylesheet (<code>css:build</code>) + <code>@theme</code> tokens, JS helpers to dedupe repeated class bundles (<code>lib/utils/ui.ts</code> app-wide, <code>modules/&lt;feature&gt;/utils/ui/</code> per feature), no <code>@apply</code>.</li>
       <li><strong>Server action patterns</strong>: one function per file, <code>ActionResult</code> envelope.</li>
       <li><strong>Code style</strong>: TypeScript extensions, const/let preferences, async/await patterns.</li>
     </ul>
diff --git a/website/app/docs/styling/page.ts b/website/app/docs/styling/page.ts
index 9eaa0cbdc..8363949d1 100644
--- a/website/app/docs/styling/page.ts
+++ b/website/app/docs/styling/page.ts
@@ -183,7 +183,13 @@ Card.register('my-card');</code-block>
 .wordmark  { background: currentColor; }             /* the painted descendant */</code-block>
 
     <h2>DRY'ing up repeated Tailwind classes via JS helpers</h2>
-    <p>When the same bundle of Tailwind classes appears in 2+ places, extract it into a JS helper in <code>lib/utils/ui.ts</code>. The helper runs at SSR time inside <code>html\`\`</code>, so the browser sees fully materialised HTML. No client-side runtime, no diff from inline classes.</p>
+    <p>When the same bundle of Tailwind classes appears in 2+ places, extract it into a JS helper that returns an <code>html</code> fragment. The helper runs at SSR time inside <code>html\`\`</code>, so the browser sees fully materialised HTML. No client-side runtime, no diff from inline classes.</p>
+
+    <p>Where it lives follows who consumes it. A fragment used across the app goes in <code>lib/utils/ui.ts</code> (and once app-wide fragments become a subsystem of their own, one file each under <code>lib/ui/</code>); one used by a single feature goes in <code>modules/&lt;feature&gt;/utils/ui/&lt;name&gt;.ts</code>, one file per fragment. The <code>ui</code> segment is what separates a function returning markup from the plain <code>utils/</code> neighbours that return data, and from <code>components/</code>, which means custom elements.</p>
+
+    <p>Read-only markup can be a fragment or a display-only component, and structure decides it, not bytes. A component is a tag in the DOM, so it adds a wrapper node. Two cases rule the element out entirely: a <code>&lt;table&gt;</code> child, where the HTML parser foster-parents an unknown element out of the table so it never renders where you put it, and output that is a string rather than DOM, such as a <code>&lt;webjs-stream&gt;</code> payload. Three more render but land wrong, so they are strong reasons rather than hard blocks: a <code>&lt;ul&gt;</code> / <code>&lt;ol&gt;</code> / <code>&lt;dl&gt;</code> child, where <code>ul &gt; li</code>, <code>:nth-child</code>, and list markers now see the wrapper; a <code>&lt;select&gt;</code> child, where the control still offers the option but it is no longer <code>select &gt; option</code>; and a grid or flex child, where the wrapper becomes the laid-out item. Prefer the component everywhere else, since it gets a tag you can target and can grow behaviour later.</p>
+
+    <p>On cost the two tie under a page: the page is inert, so the fragment runs at SSR and is never fetched, and a component doing no client work is elided. Under an interactive island <em>both</em> ship, because an island's imports are fetched either way. The component additionally carries an element class plus its registration, an upgrade per instance, and the display-only components it renders, which stop being elided with it. Treat that as the last consideration, not the first.</p>
 
     <code-block>// lib/utils/ui.ts
 import { html } from '@webjsdev/core';