@loadbare/app 0.18.2 → 0.19.1

package/docs/TECHREF-1.0.md

@@ -1,2312 +0,0 @@
-# What 1.0 release means
-
-This is the complete technical reference to the upcoming Release 1.0.
-
-Method-of-work is to continually revise this document to what we want
-to be true, then revise the code, docs, and tests to ensure it is true.
-
-## Blockers
-
-We cannot declare 1.0 until we determine if these blockers can be
-added later w/o breaking changes.  If we are reasonably confident
-that they can be decided later w/o breaking changes, then we rename
-them to "Out of Scope" or move them to the roadmap.  Otherwise, 
-they must be resolved before we declare 1.0.
-
-### Nested queries
-
-Imagine an HTML `<select>` that shows a fixed set of choices on every row of
-a table, such as `customer_type` for a table of customers.  When every
-customer may take every customer type, the system as written today is
-fine, because every `<select>` receives the same rows.
-
-But the allowed values may depend on other values in the row.
-
-- **Decide whether a nested query's rows may depend on its row.** A nested
-  query has one answer, which every live row receives.  See
-  [Master-detail](#master-detail) for what a nested query is for.
-
-```html
-<tbody lb-query="accounts">
-  <template><tr>
-    <td lb-column="name"></td>
-    <td><select lb-query="statuses" lb-column="status"><template><option lb-column="label"></option></template></select></td>
-  </tr></template>
-</tbody>
-```
-
-### The server API
-
-- **Land `staticRoutes`.**  It closes the last place where an
-  application hand-writes facts the builder owns.
-
-### The builder
-
-- **Adopt a configuration file and fold `imports.ts` into it.** It holds
-  `out`, `minify` and `imports`, and lives where `imports.ts` lives now, so a
-  repository with several applications gets one per application.  `--src`
-  stays a flag, since it is what locates the file.  State the precedence
-  between a flag and a key once.  Its key names join the permanent surface,
-  so this lands before 1.0 or not at all.  It reserves a key for the
-  roadmap's tree-shaking CSS by tag name.
-- **Confirm the three output names.** `app.html`, `client.js` and `app.css`
-  are about to be fixed in `staticRoutes` as well as in the builder.
-
-### The internal surface
-
-None of this is surface.  It is listed here because trimming it is free
-today and breaking after 1.0.
-
-- **Audit what the hub does.** Every routine it runs answers to an `lb-*`
-  attribute, a [reserved query](#reserved-queries), or a
-  [reserved event](#reserved-events) or [method](#reserved-methods).  Trim
-  whatever does not, and leave what stays clean: no dead code, no routine
-  written twice, no comment the code contradicts.
-- **Keep the rest as constants.** The endpoint, `index` and the timeout are
-  linkage between the builder and the hub rather than facts an application
-  varies.  Adding a knob for any of them buys a second shape of application
-  to reason about.
-
-## The build
-
-### Running the builder
-
-```
-loadbare-app-build [--src src] [--out dist] [--watch] [--minify]
-```
-
-`--src` names the tree the builder scans, and is defined under
-[What the builder scans](#what-the-builder-scans).
-
-`--out` names the directory the builder writes into, and defaults to `dist`.
-Every output path in this document is written relative to it, so an
-application that passes `--out` reads `dist/app.html` here as
-`<out>/app.html`.  See [Build outputs](#build-outputs).
-
-`--watch` builds once, then rebuilds on every change to an `.html`, `.ts` or
-`.css` file under `--src`.  A build that throws is reported and the watch
-continues.  There is no dev server and no browser reload.
-
-`--minify` minifies `client.js` and `app.css`.  It leaves `app.html` alone,
-which stays markup an application can read.
-
-The builder bundles `client.js` from a `client-entry.ts` it generates into
-`--out` and leaves there.  Nothing reads it after the bundle, and an
-application neither writes nor imports it.
-
-Every `.css` file in every origin joins `app.css`.  There is no custom element, page
-or chrome stylesheet: the builder concatenates them all, with nothing added,
-removed or scoped, so what ships is what was authored.  Within one origin
-they are ordered by filename, the full path breaking a tie, and a
-subdirectory never affects the order.  Origins follow the cascade — this
-package's own custom elements, then each package named in `imports.ts`, then `--src`
-last — so an application's own stylesheet always lands after the ones it
-imported.  A file named `00-global.css` sorts first by saying so.
-
-### What the builder scans
-
-#### The current project
-
-The builder scans one directory named by its `--src` parameter,
-which defaults to `src/`.  
-
-The sections below often state something like, "anywhere in 
-the `--src` tree", because Loadbare/app assigns semantic meaning
-to file names, not subdir names.
-
-#### Imported widget libraries
-
-Any number of widget libraries can be used.  They are named
-in the file `imports.ts`, located anywhere in builder `--src`.
-A project can leave out `imports.ts`, or have exactly one, but
-two or more is an error.
-
-```ts
-// imports.ts, anywhere in --src
-export default ["@namespace/widget-library"];
-```
-
-If the named package's `package.json` declares where the widgets
-are, Loadbare scans that.  Otherwise it scans the entire installed
-directory.  The declaration, if present, would look like this:
-
-```json
-"loadbare": { "widgets": "./dist" }
-```
-
-### File names and the builder
-
-The builder finds a file by its name.  A subdirectory carries no meaning, so
-the whole of `--src` is one flat namespace, as stated in
-[What the builder scans](#what-the-builder-scans).
-
-Three kinds of file hold HTML.
-
-| File               | Holds                                     | Found in     |
-| ------------------ | ----------------------------------------- | ------------ |
-| `chrome.html`      | The one HTML document                     | `--src`      |
-| `<stub>.page.html` | One page's markup, as a fragment          | `--src`      |
-| `<tag-name>.html`  | One custom element's markup, as a fragment | Every origin |
-
-As stated in [Chrome](#chrome), `chrome.html` is a required singleton. 
-
-As stated in [Pages](#pages), the `<stub>` of a `.page.html` is the path the
-page maps to.  The builder puts all pages into `dist/app.html` as HTML `<template>` objects
-that carry `lb-page="<stub>"`, and `lb-page-title` when the page file has a
-`<title>`.
-
-An element file is exactly `<kebab-case-name>.html`. A
-[custom element](#custom-elements) is suitable for organizing large HTML
-trees, or adding custom behavior, or both.  An element file is named for the
-tag it expands.
-
-Any other HTML file, one that is not `chrome.html`, or `<stub>.page.html` or
-`<kebab-case-name>.html` will either:
-- be an error if it looks like an element file with capitalization
-- be skipped
-
-
-## HTML
-
-In a Loadbare/app application, HTML is static after the build, and once
-it is sent to the browser on initial page load, no HTML is ever sent
-again.
-
-The developer writes `lb-*` attributes in markup.  Script never assigns
-them.  The hub and the builder write only their stamps, and the hub writes
-the `name` of a radio button in a row template.  See
-[The markup checks](#the-markup-checks).
-
-### Expansion
-
-The builder executes a process we call "expansion".  When it finds
-a custom element in the HTML it is processing, such as `<my-element>`,
-it looks for the element file `my-element.html`, and follows the expansion
-rules to place its contents.
-
-A custom element with no element file is left alone.  A custom element
-with neither an element file nor a `.browser.ts` script is a build error, as
-stated in [Custom elements](#custom-elements).
-
-Each file is parsed on its own, and expansion joins them through the DOM,
-which applies none of HTML's rules for what an element may hold.  The browser
-reads the shipped text by those rules, so a join it would rearrange, such as
-a definition's `<dialog>` inside a page's `<p>`, is a build error naming the
-file, the custom element and the path to what would move.
-
-#### Build time parameters
-
-A build time parameter is supplied as an attribute on a custom element,
-and is converted to a fixed value within the HTML by the builder.
-
-The attribute name carries an `exp-` prefix, as in `exp-label`, and
-the substitution locations use `{{label}}` (no prefix) inside the
-element file:
-
-```html
-<!-- note-field.html, the element file -->
-<label>{{label}} <input readonly="{{readonly}}" /></label>
-```
-
-```html
-<!-- a page -->
-<note-field exp-label="Name"></note-field>
-```
-
-```html
-<!-- dist/app.html -->
-<note-field exp-label="Name"
-  ><label>Name <input /></label
-></note-field>
-```
-
-An element file states a default with `{{name|default}}`, as in
-`{{button-label|OK}}`.  Whitespace around the name and around the default is
-discarded.  The default is a literal.
-
-| The attribute is assigned | Expansion defines   | Result                           |
-| ------------------------- | ------------------- | -------------------------------- |
-| `exp-name="text"`         | `{{name}}`          | `text`                           |
-| `exp-name=""`             | `{{name}}`          | An empty string                  |
-| Nothing                   | `{{name\|default}}` | `default`                        |
-| Nothing                   | `{{name}}`          | Nothing, and the attribute drops |
-| `exp-name`                | No `{{name}}`       | A build error                    |
-
-Attributes without the `exp-` prefix are ignored during expansion.
-
-A placeholder is the whole of an attribute value or the whole of a text node.
-`title="Hello {{name}}"` ships literally.
-
-A placeholder name carrying a capital is a build error.
-
-A parameter value cannot become markup.
-
-#### Slots and templates
-
-An element file may contain any number of named templates and optionally
-one slot.
-
-| Attribute         | The builder                                             |
-| ----------------- | ------------------------------------------------------- |
-| `lb-exp-slot`     | Puts in it the rest of the custom element's content     |
-| `lb-exp-template` | Puts in it the content of the template of the same name |
-| `exp-<name>`      | Replaces `{{name}}` in the element file with its value  |
-
-- `lb-exp-slot` goes on one element in an element file.
-- `lb-exp-template` goes on an element in an element file, and on a
-  `<template>` in the custom element's content.  Both name the same
-  template.
-- `exp-<name>` goes on a custom element.
-
-This simplified element file for `lb-table` names two templates, `head` and
-`foot`, and marks `<tbody>` as the slot.  A page supplies whichever templates
-it wants, and everything else it writes goes to the slot.
-
-```html
-<!-- lb-table.html, the element file -->
-<table>
-  <caption>
-    {{caption}}
-  </caption>
-  <thead lb-exp-template="head"></thead>
-  <tbody lb-exp-slot></tbody>
-  <tfoot lb-exp-template="foot"></tfoot>
-</table>
-```
-
-The page below supplies the `head` template and a row template.  The row
-template names no destination, so it goes to the slot.  This page writes no
-footer.
-
-```html
-<!-- a page -->
-<lb-table lb-query="staff" exp-caption="Everyone, by team">
-  <template lb-exp-template="head">
-    <tr><th>Name</th><th>Role</th></tr>
-  </template>
-  <template>
-    <tr><td lb-column="name"></td><td lb-column="role"></td></tr>
-  </template>
-</lb-table>
-```
-
-When a named template is expanded, the `<template>` tag is discarded and its
-contents are placed as children of the element that names it.  Both
-`lb-exp-slot` and `lb-exp-template` are gone from what ships.  The built
-document holds:
-
-```html
-<!-- dist/app.html -->
-<lb-table lb-query="staff" exp-caption="Everyone, by team"
-  ><table>
-    <caption>
-      Everyone, by team
-    </caption>
-    <thead>
-      <tr>
-        <th>Name</th>
-        <th>Role</th>
-      </tr>
-    </thead>
-    <tbody>
-      <template>
-        <tr>
-          <td lb-column="name"></td>
-          <td lb-column="role"></td>
-        </tr>
-      </template>
-    </tbody>
-    <tfoot></tfoot></table
-></lb-table>
-```
-
-These are build errors:
-
-- An element file with two destinations of one name
-- An element file with more than one `lb-exp-slot`
-- A page naming a template the element file does not have
-- A page giving two templates for one name
-- Content written in a custom element whose element file has no slot
-
-### Names
-
-Loadbare owns the `lb-` prefix in several namespaces: attribute names, the
-values of its attributes, query names, the column names of its own queries,
-request names, custom element names and custom event names.  It also owns
-custom element method names beginning with `lb`.
-
-The application should never name anything with the `lb-` prefix anywhere.
-
-`createHub` refuses, at startup, a page that declares a query or a handler
-whose name begins with `lb-`.
-
-### Landing
-
-A query is a name for rows, of kind `row` or `rows`, with a key.  The server
-declares a page's queries in `<stub>.queries.ts`, and answers every request,
-a page load included, with response items.  A response item carries a query
-name, its kind, its key's column name, and one of a row, all rows, or a
-patch.  See [The wire](#the-wire).
-
-The hub lands a response item on every element whose `lb-query` names its
-query.
-
-| Attribute   | Names    | The hub                                            |
-| ----------- | -------- | -------------------------------------------------- |
-| `lb-query`  | a query  | Puts its rows in the element's content             |
-| `lb-column` | a column | Sets the element from that column                  |
-| `lb-show`   | a column | Removes it while the named column is null or false; `!column` reverses it |
-
-| Stamp                | The hub stamps it with           |
-| -------------------- | -------------------------------- |
-| `lb-column-value`    | The value it set                 |
-| `lb-key-value`       | The row's key                    |
-| `lb-row-live`        | Nothing; it marks a live row     |
-| `lb-query-row-count` | The number of live rows it shows |
-
-The markup names a query and the columns it shows.  The kind and the key are
-the server's, and the markup states neither.
-
-The row template is the first `<template>` among the descendants of an
-element with `lb-query`, outside any nested `lb-query`, or, when that
-template is a [group template](#groups), the innermost template inside it.
-A live row is an element the hub cloned from a row template for one row,
-and carries `lb-row-live`.
-
-| Kind   | Row template | The hub                             |
-| ------ | ------------ | ----------------------------------- |
-| `row`  | no           | Lands the row on the element itself |
-| `row`  | yes          | Lands one live row                  |
-| `rows` | yes          | Lands one live row per row          |
-| `rows` | no           | Lands nothing                       |
-
-A `rows` query with no row template names the query without showing it,
-which is what an insert form naming the query it adds to is.
-
-The nearest ancestor row of an element is the nearest of: the element
-itself when it is a live row, an ancestor that is a live row, and an
-ancestor that carries `lb-query` of kind `row`.  The hub reads `lb-column`
-and `lb-show` from the nearest ancestor row.  A nested `lb-query` begins a
-new query, and what is inside it is that query's.
-
-An element's own `lb-query` names what the element holds, and its own
-`lb-column` reads from the row around it.  So a
-`<select lb-query="statuses" lb-column="status">` in a live row of
-`accounts` holds the statuses as its options and shows that account's
-`status`.  `lb-column` on an element with `lb-query` is undefined unless the
-element is a control.
-
-Name one query on more than one element to show it in more than one place.
-Every one of them receives it.
-
-A query that arrives with nowhere to land is reported to the console,
-unless its name begins with `lb-`.
-
-#### How a column lands
-
-| Element                                          | The hub sets                   |
-| ------------------------------------------------ | ------------------------------ |
-| A control                                        | Its `value`                    |
-| A custom element that is not a control           | `lb-column-value` only         |
-| Any other element                                | Its text content               |
-
-A control is an `<input>`, `<select>` or `<textarea>`, or a form-associated
-custom element with a `value` property that fires `change`.  A checkbox and
-a radio button are controls too, by the rules below.  A
-form-associated custom element declares `static formAssociated = true`.
-
-The hub stamps `lb-column-value` with the value on every element it sets.
-It never replaces the content of a custom element, which the builder placed
-there from its element file.  A custom element that is not a control
-renders `lb-column-value` itself.
-
-The hub gathers from the same controls it lands on, so a value read back is
-the one that landed.
-
-A checkbox's state is `checked`, not `value`: HTML's quirk, and so the
-hub's, so that every other part of the vocabulary treats it as any control.
-The hub checks it by the rule `lb-show` is on by: `null` and `false` are
-unchecked, and every other value is checked, with no string read.  It
-gathers `"true"` or `"false"`, so an unchecked box still says so, where a
-native form submission leaves it out.  The checkbox's own `value`
-attribute means nothing to the hub.
-
-```html
-<input type="checkbox" lb-column="active" lb-request="lb-row-update" />
-```
-
-A radio button's state is `checked` as well.  The hub checks it when its
-`value` attribute equals the value as a string, and unchecks it otherwise,
-`null` included.  Of the radio buttons naming one column, the hub gathers
-the `value` of the one checked, or `""` when none is.
-
-```html
-<input type="radio" lb-column="shift" value="day" lb-request="lb-row-update" />
-<input type="radio" lb-column="shift" value="night" lb-request="lb-row-update" />
-```
-
-An `<input>` of type `file` receives nothing, not even `lb-column-value`,
-and the hub reports it to the console.  The hub does not gather one either.
-
-A `<select>` with no option for the value shows no selection.
-
-An element with `lb-column` and no ancestor row receives nothing.  The hub
-still gathers from it.
-
-The value arrives as the query produced it, with no conversion, so the
-browser decides what a non-string looks like.
-
-A column holds one value.  A set of values is a query of its own, never an
-array in a column.
-
-A custom element sees `attributeChangedCallback` for an `lb-column-value`
-already present when it upgrades, so it cannot tell a first landing from a
-refresh, and does not need to.
-
-#### Rows
-
-The hub matches each row to a live row by its key.  It stamps
-`lb-key-value` on each live row, and on an element a `row` lands on itself.
-It stamps `lb-row-live` on each live row and nowhere else, so a `row`
-landed inside another query, such as a total in a table's foot, is not one
-of that query's rows.  A stylesheet or a custom element selects live rows
-with `[lb-row-live]`, and never with `[lb-key-value]`.
-
-A `row` query answering `null` lands every column its element names as
-null, and the element loses `lb-key-value`.  Under a row template, its live
-row leaves.
-
-A key is unique within a query.  Two rows with one key in the same answer,
-or two live rows showing one key, are reported on the console.
-
-All rows decide membership: a live row whose key did not arrive leaves —
-see [What happened to a row](#what-happened-to-a-row).  A patch touches only
-the rows it names, and leaves every other live row's contents alone.
-
-The hub places every live row by the query's [order](#order), immediately
-before the row template, or before its clone in the row's
-[group](#groups).  A row moves only when the order puts it somewhere else,
-so all rows landing again unchanged move nothing.  A live row already in the
-markup when the first answer lands is one of the query's rows.
-
-After every landing the hub stamps the element with `lb-query-row-count`,
-the number of live rows it shows.  A row a [filter](#filters) hides is not
-counted.  The server answers with rows and says
-nothing about how many survived, so this is the one fact a page cannot be
-sent.  It makes an empty query a stylesheet rule:
-
-```css
-[lb-query-row-count="0"] .roster-empty {
-  display: revert;
-}
-```
-
-A row missing its key column is reported to the console and not landed.
-
-When the focus is in a live row that placing moves, the hub puts it back on
-the same element and scrolls it into view.  When that row leaves, or a
-filter hides it, the focus goes to the first element the user can operate
-in the first row showing.
-
-#### Order
-
-A `rows` query's order is a rule over its columns.  The server declares it
-with the query, and the user may choose another:
-
-```ts
-accounts: rows("id", (ctx) => ctx.db.accounts(), {
-  order: "category_order,account_name",
-}),
-```
-
-An order is columns separated by commas.  A column written after `-` sorts
-descending.  `lb-order`, on the element carrying `lb-query`, names a column
-of [`lb-choices`](#choices) holding the user's order, and while that column
-is not empty it replaces the declared order.  With neither, rows show in the
-order the server sent them, and a patch's new rows go last.
-
-| Values               | Compare                                    |
-| -------------------- | ------------------------------------------ |
-| Two numbers          | Numerically                                |
-| Two strings          | As the user's language orders them         |
-| Two booleans         | `false` before `true`                      |
-| Two different types  | Booleans, then numbers, then strings       |
-| `null` or missing    | After everything ascending, first descending |
-
-A number sent as a string sorts as a string, so a column the order reads
-numerically arrives as a JSON number, or its query declares its type.
-`types` names a type for any of a `rows` query's columns, one of `number`,
-`boolean` and `text`, and the column compares read as that type whatever
-JSON type its values arrive as:
-
-```ts
-accounts: rows("id", (ctx) => ctx.db.accounts(), {
-  order: "-balance",
-  types: { balance: "number" },
-}),
-```
-
-A value that is no value of its declared type compares as `null` does.
-`createHub` refuses at startup a type it does not know.
-
-The declared order and types travel once, on the answer that loads the
-page, and the hub keeps them with the query's answer for every answer after
-it, all rows or a patch.  `readAs` in
-`@loadbare/app/types` is the rule the hub applies.
-
-Rows that compare equal keep the order they arrived in, and a patch's new
-rows come after the rows already showing.
-
-The hub sorts the rows it has, so a choice of order places them again with
-no round trip:
-
-```html
-<div lb-query="lb-choices">
-  <select lb-column="accounts_order" lb-request="lb-row-update">
-    <option value="">By category</option>
-    <option value="account_name">By name</option>
-  </select>
-</div>
-
-<table lb-query="accounts" lb-order="accounts_order">
-  ...
-</table>
-```
-
-#### Filters
-
-`lb-filter`, on the element carrying `lb-query`, names the columns of its
-rows a choice may filter, separated by commas.  The column of
-[`lb-choices`](#choices) of the same name holds the filter.  A row that does
-not pass every filter is `hidden`, and a ticked `lb-select` in it is
-cleared.  A group whose rows are all hidden is hidden.  An empty choice
-filters nothing.
-
-```html
-<table lb-query="accounts" lb-filter="account_name, balance">
-```
-
-A filter is terms, each an operator and a value.  A term begins wherever
-whitespace comes before an operator, so a value may hold spaces.  Text with
-no operator is `*=`.  A term with no value is left out.  Every term must
-pass: `>=2026-01-01 <=2026-03-31`.
-
-| Operator                   | Compares                                          |
-| -------------------------- | ------------------------------------------------- |
-| `^=`, `$=`, `*=`           | As text, ignoring case: begins with, ends with, contains |
-| `=`, `!=`, `<`, `<=`, `>`, `>=` | As the [order](#order) compares, with the value read as the column's type |
-
-The column's type is its declared [type](#order), if its query declares
-one.  Otherwise it is a number for a JSON number, `true` or `false` for a
-boolean, and text otherwise.  A value that is not of the column's type, and
-a column that is null or missing, pass only `!=`.
-
-`parseFilter`, `passes` and `passesTerm` in `@loadbare/app/types` are the
-rule the hub applies.
-
-#### Groups
-
-A group is a run of rows sharing the order's leading term.  A group
-template is a `<template lb-group>` in the row template's place, holding the
-group's heading and exactly one nested `<template>`, which is where the
-group's contents go: the next group template, or the row template.  The nth
-group template breaks on the order's nth term, so groups nest to any depth.
-
-```html
-<table lb-query="accounts">
-  <thead><tr><th>Account</th></tr></thead>
-  <template lb-group>
-    <tbody>
-      <tr><th scope="rowgroup" lb-column="category"></th></tr>
-      <template><tr><td lb-column="account_name"></td></tr></template>
-    </tbody>
-  </template>
-</table>
-```
-
-The hub clones the group template where the order breaks and puts the
-group's contents immediately before the clone of its nested template.  The
-markup's nesting decides the shape:
-
-| The nested template is            | The group's contents land           | Example                          |
-| --------------------------------- | ----------------------------------- | -------------------------------- |
-| Inside the heading's element      | Inside it                           | `<tbody>`, `<li>`, `<details>`   |
-| Beside the heading                | After the heading, as its siblings  | A heading `<tr>` in one `<tbody>` |
-
-`<tbody>` and `<optgroup>` do not nest, so a table's levels below the first
-are heading rows beside their rows.  Content after the nested template lands
-after the group's rows, which is where a group's footer goes.
-
-A group's heading is filled from its first row, the same way a live row is
-filled, so it shows any column of the row.  The example breaks on
-`category_order` and shows `category`.  The hub fills it from no other row.
-
-The hub stamps each top-level element of a group's clone with
-`lb-group-live`, `lb-group-column`, the column it breaks on, and
-`lb-group-value`, its value there.  A row creates its group, and a group
-leaves with its last row.  When the order changes, a group whose run goes
-on is kept and moved, and a group whose run ended leaves.
-
-A group template with no nested template is reported to the console.  More
-group templates than the order has terms show each extra level as one
-group, and are reported once.
-
-#### Aggregates
-
-An aggregate attribute sets an element from the rows of the nearest group
-around it, or of the whole list outside any group.
-
-| Attribute       | Sets the element to                           |
-| --------------- | --------------------------------------------- |
-| `lb-count`      | The number of rows                            |
-| `lb-sum="col"`  | The sum of `col`                              |
-| `lb-avg="col"`  | The average of `col`                          |
-| `lb-min="col"`  | The least value of `col`, by the [order](#order)'s comparison |
-| `lb-max="col"`  | The greatest, likewise                        |
-
-```html
-<tr><td><span lb-count></span> accounts</td><td lb-sum="balance"></td></tr>
-```
-
-It lands as a column does, with `lb-column-value`.  A sum and an average
-are exact decimals, read from JSON numbers and from strings holding a plain
-decimal, as Postgres sends `numeric`.  A sum has as many places as the most
-precise value, and an average up to two more.  `null` and empty values are
-left out, as SQL leaves them out.  Any other value is left out and reported
-once.  The hub does not format the result.
-
-An aggregate covers the rows showing, so a row a [filter](#filters) hides
-is left out.  Where the true total
-matters beyond what the page shows, it is a row the server answers.
-
-#### What happened to a row
-
-Every change the hub makes to a list is one a stylesheet can see, so an
-application animates with CSS alone and the hub starts no animation.
-
-| Attribute          | On                   | Means                                              |
-| ------------------ | -------------------- | -------------------------------------------------- |
-| `lb-row-created`   | A live row           | Created when the hub last touched it               |
-| `lb-row-changed`   | A live row           | Its values changed when the hub last touched it    |
-| `lb-row-moved`     | A live row           | Its values changed, and it now stands elsewhere    |
-| `lb-row-requested` | A live row           | `created`, `changed` or `moved` by this page's request |
-| `lb-row-leaving`   | A row on its way out | No longer live                                     |
-| `lb-group-leaving` | A group on its way out | No longer live                                   |
-
-The hub touches a row when an answer names it.  `lb-row-created`,
-`lb-row-changed` and `lb-row-moved` are cleared when it next does, and one
-applied again is removed and added as two changes, so an animation keyed to
-it plays again.  `lb-row-requested` is cleared at every landing of the
-row's query, and set only by a landing that answers a request from the page.
-
-A row or a group that leaves loses `lb-row-live` or `lb-group-live`, takes
-`lb-row-leaving` or `lb-group-leaving` and `inert`, and is removed once the
-animations running on it have finished, at once when there are none.  A
-row leaves when all rows arrive without its key, or a patch drops it.
-
-A row is moved when its values changed and the nearest rows whose values did
-not change, before and after it, are not the ones it stood between.  A row
-it passed is not stamped, and a change of the user's order, which changes no
-values, stamps none.  A moved row stays live and moves.
-
-```css
-[lb-row-created] { animation: arrive 200ms; }
-[lb-row-leaving] { animation: depart 200ms forwards; }
-```
-
-A row never travels between the two places, since that takes measuring, and
-measuring takes script.  Scrolling to a row is script too: a custom element
-reads `lb-row-requested` in [`lbRowsLanded`](#row-hooks).
-
-#### Displaying by condition
-
-`lb-show` names the column that decides whether an element is present.
-`null` and `false` are off, and every other value is on.  No string is read,
-so `"false"` is on, and a query spells a condition as a boolean or a null.
-
-```html
-<template>
-  <tr>
-    <td lb-column="name"></td>
-    <td><button lb-request="lb-row-delete" lb-show="removable">Remove</button></td>
-  </tr>
-</template>
-```
-
-Write `!` before the column to reverse it: `lb-show="!chosen"` is present
-while `chosen` is null or false.  One column then decides both of two
-elements, rather than a column and its opposite, which could disagree.
-
-It reads from the nearest ancestor row, as `lb-column` does, and on an
-element that carries `lb-query` the column belongs to the row around it.  A
-row that does not carry the column leaves the element as it is.
-`lb-show` with no ancestor row is undefined.
-
-An element that is off is moved into a `<template lb-show="column">`
-standing where it stood, and moved back out when the column turns on.  It is
-not rendered, focused, clicked, announced or gathered.  It is moved and
-never rebuilt, so a custom element keeps its instance and a control keeps
-what was typed into it.  Landing reaches into that template, so the element
-and everything inside it return current.  A custom element hears nothing
-going in or coming out, and still receives `lb-column-value` while it is
-away.
-
-The builder ships every `lb-show` element already inside its template, so
-nothing conditional shows until its row lands.  An absent element's template
-keeps its place among its siblings, and a position selector counts it.
-
-These are build errors: `lb-show` on a row template's root, `lb-show` with
-no `lb-query` around it, `lb-show` on a `<template>`, and `lb-show="!"` or
-`lb-show="!!column"`.
-
-Hiding is presentation, and the server still refuses what a request may not
-do.
-
-#### Master-detail
-
-A master is a `row` query and its detail is a `rows` query, as two names
-answered side by side.  A column never holds rows.
-
-```html
-<section lb-query="invoice">
-  <h2 lb-column="number"></h2>
-  <span lb-column="customer"></span>
-</section>
-
-<table>
-  <tbody lb-query="invoiceLines">
-    <template><tr><td lb-column="item"></td><td lb-column="amount"></td></tr></template>
-  </tbody>
-</table>
-```
-
-Many masters, each with its own detail, is one `rows` query of joined rows:
-each detail row carries its master's columns.  A [group
-template](#groups) shows each master as a group, ordered by the master's
-key first.
-
-A query nested in another query's row template receives the same rows in
-every live row.  That serves a picker offering the same choices on every
-row, and is not a way to show a different detail per row.  A live row added
-later is filled from the nested query's last answer, so a request that adds
-one does not refresh the nested query to fill it.
-
-Which master a page shows is a query parm, which a query reads off `ctx`
-since it takes no argument from the browser — see [Query parms](#query-parms).
-When a write creates or removes the master, the server response moves the
-URL — see
-[When a server response moves the URL](#when-a-server-response-moves-the-url).
-
-### Requests
-
----- UNEDITED ----
-
-| Attribute    | Names     | The hub                                      |
-| ------------ | --------- | -------------------------------------------- |
-| `lb-request` | a request | Issues that request when the element commits |
-
-| Stamp                | The hub stamps it                          |
-| -------------------- | ------------------------------------------ |
-| `lb-request-pending` | While the round trip is in flight          |
-| `lb-request-error`   | When the round trip fails, until the next  |
-
-The request name is the attribute value of `lb-request`.  It names either a
-request Loadbare provides or a declared request: a name the page declares
-under `handlers`, which runs application code.
-
-Every request has one shape, on the event and on the wire:
-
-```
-{ name: "lb-row-insert", query: "roster", values: { name: "Ann" } }
-{ name: "lb-row-update", query: "roster", key: "42", values: { name: "Ann" } }
-{ name: "lb-row-delete", query: "roster", key: "42" }
-{ name: "mailRoster",    query: "roster", key: "42" }
-{ name: "lb-row-update", query: "roster", keys: ["42", "43"], values: { role: "lead" } }
-{ name: "lb-row-insert", query: "invoice", values: { memo: "May" }, rows: { lines: [{ key: "1", values: { qty: "3" } }] } }
-```
-
-The hub sends `query`, `key` and `values` as present, and `keys` in place of
-`key` for a request acting on the rows selected — see
-[Selecting rows](#selecting-rows).
-
-#### Committing
-
-An element commits on `submit` when it is a form, on `change` when it is a
-control, and on `click` otherwise.
-
-A submit button with a form owner never commits on `click`.  On a form's
-`submit`, the hub issues the submitter's `lb-request` when it carries one,
-and the form's otherwise, the way `formaction` replaces `action`.
-
-A click on a descendant of an element carrying `lb-request` commits that
-element, as long as the element is inside `<lb-hub>` and no interactive
-content lies between them.  Interactive content is HTML's: `<a href>`,
-`<button>`, `<input>` other than hidden, `<select>`, `<textarea>`, `<label>`,
-`<details>`, `<iframe>`, `<embed>`, `<audio controls>`, `<video controls>`
-and `<img usemap>`, plus any form-associated custom element.  A click on
-one of them belongs to it: a click into an input inside a deletable row
-focuses the input and deletes nothing.
-
-The hub ignores a commit on an element carrying `lb-request-pending`.
-
-#### Gathering
-
-The hub gathers values when it issues a request.  It gathers each control
-value under the column its `lb-column` names.
-
-| Attribute      | The hub                                     |
-| -------------- | ------------------------------------------- |
-| `lb-query`     | Issues the request for it                   |
-| `lb-column`    | Gathers the control value under that column |
-| `lb-key-value` | Takes `key` from it                         |
-
-- When the element carrying `lb-request` has `lb-column`, the hub gathers
-  its value alone, and sends `values` with one member.
-- Otherwise, when the element is a `<form>`, the hub gathers every
-  `lb-column` whose form owner is the element.
-- Otherwise, when the element is in a live row, the hub gathers every
-  `lb-column` in that live row.
-- Otherwise the hub gathers every `lb-column` whose form owner is the
-  element's form owner.
-
-The form owner includes a control that names the form with the HTML `form`
-attribute from anywhere in the document, which is how a table row's
-controls belong to a form that cannot wrap a `<tr>`:
-
-```html
-<form id="add-member" lb-request="lb-row-insert"></form>
-<table lb-query="roster">
-  <tbody>
-    <template>
-      <tr><td lb-column="name"></td><td lb-column="role"></td></tr>
-    </template>
-  </tbody>
-  <tfoot>
-    <tr>
-      <td><input lb-column="name" form="add-member" /></td>
-      <td>
-        <input lb-column="role" form="add-member" />
-        <button form="add-member">Add</button>
-      </td>
-    </tr>
-  </tfoot>
-</table>
-```
-
-The hub gathers from controls only.  It skips a control whose nearest
-ancestor `lb-query` is a descendant of the live row or form, since that
-control belongs to a nested query, except that a form gathers the rows of a
-query nested in its own — see [A form over a set of rows](#a-form-over-a-set-of-rows).  An element carrying `lb-query` and
-`lb-column` both, such as a picker, belongs to the row around it and is
-gathered.
-
-The hub issues the request for the nearest ancestor `lb-query` of the
-controls it gathered, and takes `key` from their nearest ancestor row when
-that row is of the same query.  When the gathered controls have different
-nearest ancestor `lb-query`, the hub reports an error and sends nothing.
-
-When it gathers nothing, the hub issues the request for the nearest
-ancestor `lb-query` of the element carrying `lb-request`, and takes `key`
-from that element's nearest ancestor row when that row is of the same
-query.
-
-#### A form over a set of rows
-
-A form gathers the live rows of a query nested directly in its own query,
-besides its own controls.  Each goes as its key and the values of the
-controls in it, under the nested query's name:
-
-```
-{ name: "lb-row-insert", query: "paychecks", values: { pay_date: "2026-10-02" },
-  rows: { deduction_types: [{ key: "401k", values: { amount: "50" } },
-                            { key: "dental", values: { amount: "" } }] } }
-```
-
-The form's own query is the one it carries, or else the nearest around it.
-A nested query is gathered when its nearest ancestor `lb-query` is the
-form's own, so one level only: a query nested deeper shows the same rows in
-every row around it, and its keys would repeat.  Every live row of it goes,
-whatever its values, and only controls inside a live row of it.
-
-An insert, an update and a declared request carry `rows`; a delete does
-not.  A form whose only controls are in nested rows sends for its own query,
-keyed by the row landed on it or the row it is pointed at, with empty
-`values`.  A live row gathers nothing nested.
-
-The handler for the form's query receives `rows` beside `values`, so the
-master and its details are written together.  The server checks that
-`rows` holds string keys and string values by query, and ignores a request
-whose `rows` does not.
-
-A nested query answers once for the page, as anywhere — see
-[Master-detail](#master-detail).  The form enters a new master with its
-details, or edits the master the page shows by a query parm, whose details
-the nested query reads from the same parm.  A pointed form fills its own
-controls from the row it points at, and its nested rows stay the nested
-query's answer.
-
-#### A row not yet entered
-
-A row whose key is the empty string is a new one, not yet entered.  It
-arises two ways: a `row` query answers with an empty key, as one reading
-the master's key from an empty query parm does, or `--lb-new` points a form
-(see [A form pointed at a row](#a-form-pointed-at-a-row)).  Either way the
-element carries `lb-key-value=""`.
-
-The hub sends no `key` for it, whether the key came from where the element
-sits or from a request a custom element dispatched.  An `lb-row-insert` and
-a declared request are sent without one.  An `lb-row-update` and an
-`lb-row-delete` are not sent, because nothing is on record to change, and
-nothing is reported: it is the row's state, not a mistake.  So a control
-saving its own column on `change` saves on a row on record, and on a new
-row only holds what a submit will gather.  No ancestor sees a request not
-sent, and it gets no `lb-request-done`.
-
-An update or a delete with no row around it at all has no key either, and
-is reported to the console, as any request missing what it needs is.
-
-A field the request already carries is its issuer's and is kept.  A custom
-element that dispatches its own request with `values` is not gathered over.
-
-#### The request names
-
-| Request name    | Needs                    | Runs under `crud` |
-| --------------- | ------------------------ | ----------------- |
-| `lb-row-insert` | `query`, `values`        | `rowInsert`       |
-| `lb-row-update` | `query`, `key`, `values` | `rowUpdate`       |
-| `lb-row-delete` | `query`, `key`           | `rowDelete`       |
-
-`keys` stands in for `key`.  The hub issues one of these only when it has
-what the table lists.  An
-`lb-row-insert` or `lb-row-update` that gathers nothing is not issued.  A
-request that is not issued is reported to the console.
-
-Loadbare provides the handlers for these names: each runs the page's `crud`
-entry for the request's query.  A declared request runs the application's
-handler under `handlers`, and the hub issues it with whatever it found.
-
-A request name beginning with `lb-` that is none of these three is refused
-by the builder in markup, and by the hub when a script dispatches it.
-
-For a query the hub serves, the hub answers the request itself, with no
-round trip.  The hub serves `lb-url`, and answers `lb-row-update` for it —
-see [Query parms](#query-parms).
-
-#### A form pointed at a row
-
-A set of rows the user edits or adds to has one form on the page, naming
-the same query, outside every row.  A button points it with HTML's
-`commandfor`, naming the form's `id`, and `command`:
-
-| Command        | On a button                       | The hub                                   |
-| -------------- | --------------------------------- | ----------------------------------------- |
-| `--lb-edit`    | In a live row of the form's query | Fills the form from that row, keyed by it |
-| `--lb-new`     | Anywhere                          | Starts the form empty, for an insert      |
-| `--lb-release` | Anywhere                          | Lets the form go without saving           |
-
-HTML requires a custom command to begin with `--`, and fires it as a
-`command` event on the form, which the hub hears.
-
-```html
-<tbody lb-query="paychecks">
-  <template><tr>
-    <td lb-column="pay_date"></td>
-    <td><button type="button" commandfor="paycheck" command="--lb-edit">Edit</button></td>
-  </tr></template>
-</tbody>
-<button type="button" commandfor="paycheck" command="--lb-new">New</button>
-
-<dialog>
-  <form id="paycheck" lb-query="paychecks" lb-request="lb-row-update">
-    <input lb-column="pay_date" type="date" />
-    <button type="submit">Save</button>
-    <button type="submit" lb-request="lb-row-insert">Save new</button>
-    <button type="button" commandfor="paycheck" command="--lb-release">Cancel</button>
-  </form>
-</dialog>
-```
-
-Which row a form edits is interaction state, not a view, so it is not a
-query parm.  The user edits only a row they can see, so Edit fills the form
-from the row as the hub holds it, every column the query answered, with no
-round trip.  A row that must be fetched to be edited is another page, with
-that row as its master.
-
-Pointing a form first empties it: every column it names lands as null, and
-the form resets, so each control returns to its default.  Edit then lands
-the row on the form as on any element a `row` lands on, stamps the form
-`lb-key-value` with the row's key, and stamps the row `lb-row-editing`.
-Gathering then takes the key from the form.  New stamps an empty key, making
-the form [a row not yet entered](#a-row-not-yet-entered).  Both focus the
-form's first control.
-
-| The form's `lb-key-value` | The form is        |
-| ------------------------- | ------------------ |
-| A key                     | Editing that row   |
-| Empty                     | Entering a new row |
-| Absent                    | Not in use         |
-
-A stylesheet shows the form's buttons by it, such as Save while it has a
-key and Save new while the key is empty.
-
-A request from the form that succeeds lets it go, as `--lb-release` does:
-the form empties, and both stamps go.  One that fails leaves the form
-pointed, as the user had it.
-
-When the form is inside a `<dialog>`, Edit and New call `showModal()` on it,
-and letting go closes it.  The dialog closing by any of HTML's means,
-Escape, `command="close"` or `method="dialog"`, lets the form go.  A form in
-no dialog opens nothing; it is always showing, or a stylesheet shows it
-while it carries `lb-key-value`.
-
-The form names a `rows` query and holds no row template, so that query's
-answers land nothing on it, and what the user typed survives a refresh.
-
-A command the hub cannot carry out is reported to the console: Edit from
-outside a live row of the form's query, Edit for a key the hub holds no row
-for, and any command aimed at an element that is not a form carrying
-`lb-query`.
-
-#### Selecting rows
-
-A checkbox carrying `lb-select` in a row template selects the live row it
-sits in, and the hub stamps the row `lb-row-selected` while it is ticked.
-It is not a column: it carries no `lb-column` or `lb-request`, lands
-nothing, and is not gathered.
-
-A request for the query that names no one row, neither from inside one of
-its rows nor from a form pointed at one, acts on the rows selected.  When
-any `lb-select` checkbox of that query is showing, the hub adds the keys of
-those ticked as `keys`:
-
-```
-{ name: "lb-row-update", query: "transactions", keys: ["4", "9"], values: { acct: "12" } }
-```
-
-- `lb-row-update` and `lb-row-delete` are sent with `keys`, and with none
-  ticked are not sent, silently, as for [a row not yet
-  entered](#a-row-not-yet-entered).
-- A declared request is sent with `keys`, empty when none is ticked, and the
-  handler decides.
-- `lb-row-insert` adds a row, and the selection is not its.
-- With no `lb-select` checkbox of the query showing, the request is an
-  ordinary one, and carries no `keys`.
-
-The server runs the page's `rowUpdate` or `rowDelete` once for each key,
-with that key, as for each row alone, so a handler written for one row
-serves several.  It lays the patches the runs return together, and runs the
-refresh set once.  A run returning `url()` is reported and ignored, since
-several rows cannot each choose one view.  A declared request receives
-`keys` as sent.
-
-After the request succeeds, the hub clears every `lb-select` checkbox of the
-query and the stamps with them.  A failed request leaves the selection.
-
-Only a checkbox that is showing counts: one parked by `lb-show` is in
-template content, out of reach.  Parking one also clears its tick, so a
-selection never waits out of sight to return stale.
-
-Which rows are selected is interaction state, as which row a form edits is.
-A selecting mode the page keeps in the URL reaches the rows as a column the
-query computes from the parm, which `lb-show` reads, since `lb-show` reads
-from the row it sits in.
-
-#### The request event
-
-The hub dispatches every request as the bubbling `lb-request` event before
-sending it, with the request as its `detail`.  The event is dispatched from
-the element that committed.
-
-A custom element uses the same event to issue a request of its own, with at
-least `name` in its `detail`.  A native element and a custom element
-therefore produce identical events.
-
-The hub completes the request on the event's way down, so every ancestor
-sees it whole on the way up.  A request that cannot be issued is stopped
-there.  An ancestor may stop it too: the event is not cancelable, so an
-interceptor calls `stopPropagation`, not `preventDefault`.  This is what
-makes a confirmation wrapper possible without the wrapped element knowing
-about it.
-
-Once what the request brought back has landed, or its round trip has failed,
-the hub calls `lbRequestDone(detail, origin)` on the committing element and
-every custom element around it, innermost first (see
-[Lifecycle](#lifecycle)), then dispatches the bubbling `lb-request-done`
-event from the same element.  Its `detail`, `HubRequestDone` in `@loadbare/app/types`, holds
-the request as the hub sent it and `items`, every response item that landed
-because of it, in order.  An answer that moved the URL contributes its
-`lb-url` item and the page load.  `error` is set instead when the round trip
-failed.  By then `lb-request-pending` is gone, and a listener sees the page
-as the answer left it.  A request the hub or an ancestor stopped was never
-sent, and gets no `lb-request-done`.  An element the answer removed from the
-document, such as the row a delete took away, dispatches the event where it
-now is, and no ancestor it had on the page hears it.
-
-#### Request state
-
-The hub stamps `lb-request-pending` on the element that issued a request
-while its round trip is in flight, together with `aria-busy="true"`, and
-removes both when it settles.  It stamps `lb-request-error` when the round
-trip fails, and clears it when that element issues its next request.
-
-A custom element observes them by naming them in `observedAttributes`.  On
-plain HTML a stylesheet is the only consumer: dim a pending button, mark a
-failed one.
-
-The hub ignores a commit on an element carrying `lb-request-pending`, so a
-pending element is disabled in fact and a stylesheet only has to show it.
-
-#### Refusals
-
-A handler refuses a request by throwing `refusal()`, exported by
-`@loadbare/app/server`, with words written for the user: a message for the
-request as a whole, a message per column, or both.
-
-```ts
-throw refusal("That series already has paychecks entered.");
-throw refusal({ amount: "Must be more than zero" });
-throw refusal("Two fields need attention.", { amount: "…", pay_date: "…" });
-```
-
-It is thrown rather than returned, so it may come from anything the handler
-calls, and rolls back whatever the application has open as any throw does.
-`hubRoutes` answers it with status 422 and `{ refusal: { message?, columns? } }`.
-Anything else thrown is a failure, answered 500 with no body, so no stack
-or database message reaches the browser.
-
-The hub shows a refusal where it belongs:
-
-- It stamps the element that committed `lb-request-refused`, whose value is
-  the whole-request message, empty when there is none.  A stylesheet shows
-  it with `attr()`.
-- For each column, it calls `setCustomValidity(message)` on the control the
-  request gathered that column from, and `reportValidity()` on the first,
-  so the browser shows the message there and moves focus to it.  A column
-  the request gathered no such control for is reported to the console.
-- `lb-request-done` carries the refusal as `refusal`, beside `error`.
-
-A refusal is not a failure: `lb-request-error` is not stamped and nothing is
-reported.  It stands until the user edits any control the request gathered,
-a form holding them resets, or the element that committed sends again;
-then every message it put up is withdrawn at once.  While a control carries
-one, the browser holds its form's submit, as for any invalid control.
-
-A form-associated custom element takes a column's message when it defines
-`setCustomValidity` and `reportValidity`; one wrapping a native control
-passes both to it.  A request for several rows takes the whole-request
-message only.
-
-#### The round trip
-
-A request the hub sends has ten seconds to come back.  Past that the hub
-aborts it and treats it as a failure, since `fetch` imposes no deadline of
-its own.  An application cannot change the deadline.
-
-A round trip fails on a server error, on a network failure, or on that
-deadline, and all three stamp `lb-request-error` on the element that issued
-the request — see [Request state](#request-state).  A refusal is not a
-failure — see [Refusals](#refusals).
-
-After a successful `lb-row-insert` gathered from a form, the hub resets the
-form, after it lands the response.  A failed insert resets nothing, so the
-entry can be corrected.  An `lb-row-update` resets nothing: the row it sent
-lands back on its controls.
-
-A reset of any form, whether the hub's, a reset button's or a script's,
-returns its controls to their defaults, and the hub removes
-`lb-column-value` from each of them.  A cancelled reset keeps both.
-
-A page load that fails lands nothing and is reported to the console.  A load
-started by a request for `lb-url` stamps the element that issued it, as any
-request stamps its element.
-
-A response answers for the URL its request was sent from, path and query
-string both.  One that returns after the URL has moved lands nothing, since
-it describes what the user is no longer looking at: a request's answer,
-including any `url()` it carries, and a page load overtaken by a newer one.
-A write whose answer is dropped this way has still happened.  Its
-`lb-request-done` carries no items and no error, and an insert still resets
-its form.
-
-### The URL
-
----- UNEDITED ----
-
-The hub serves the query `lb-url`, of kind `row`, keyed by `lb-path`.  It
-lands wherever an element names it, like any server query.
-
-| Column            | The hub sets it to                             |
-| ----------------- | ---------------------------------------------- |
-| `lb-path`         | The path.  The row's key                       |
-| `lb-page-label`   | The page's title, or its stub when it has none |
-| `lb-page-unknown` | Whether no page's stub matches the path        |
-| any other name    | That query parm                                |
-
-| Attribute        | The hub                                                  |
-| ---------------- | -------------------------------------------------------- |
-| `lb-url-link`    | On a plain primary click, sets `lb-path` from the `href` |
-| `lb-url-push`    | Pushes a history entry for this element's update         |
-| `lb-url-unknown` | Calls `showModal()` when `lb-page-unknown` is `true`     |
-
-- `lb-url-link` goes on an `<a>`.
-- `lb-url-push` goes on an element with `lb-request`.
-- `lb-url-unknown` goes on a `<dialog>` inside `<lb-hub>`.
-
-The hub shows in `<main>` the page whose stub is `lb-path`.  `/` is
-`index`.  When `lb-path` takes a new value, the hub loads the page: the
-server runs its `onPageEnter`, then its queries.  When a query parm takes a
-new value, the hub reloads the page's queries, and keeps the page's DOM, so
-live rows that come back keep their place.
-
-Once an entered page's queries have landed, the hub focuses the first
-element in `<main>` the user can operate: not disabled, not in a closed
-`<dialog>`, not `inert`, not `hidden`, not in an absent `lb-show` branch,
-and one that takes the focus.  Entering is a cold load, a new `lb-path`,
-and Back or Forward to another page.  A change of query parm enters no
-page, and focus stays where it is, as it does when it is already in
-`<main>`.
-
-The page's title is the text of the page file's `<title>`, which the builder
-stamps on the page as `lb-page-title`.  The hub sets the document title to
-`lb-page-label` when it is not null.
-
-```html
-<header lb-query="lb-url">
-  <h1>Membership Roster</h1>
-  <h2 lb-column="lb-page-label"></h2>
-</header>
-```
-
-#### What a URL names
-
-The path names a page, a place in the application.  It never names a
-resource, and Loadbare/app does not reproduce REST: `/accounts/42` is not a
-way to reach account 42.
-
-The query string describes what that page has on screen:
-`/accounts?acct=23&from=2026-09-09`.  It never commands, and the server
-remembers nothing, so a URL is a reproducible view.  Reload it, bookmark it,
-or mail it to someone, and what they see is what the sender saw.
-
-A page declares what it shows, its queries, and what it allows, its
-requests.  Loading a page runs its queries.  A request names a query and,
-where it has one, a key, taken from where the element sits, which is how the
-database already names a row.  Nothing is fetched by URL, so an application
-designs no endpoints.
-
-That last is where query parms move Loadbare's position.  A query still takes
-no argument from the browser, and a parm arrives the way the session cookie
-does, as part of the request the context is built from.  But a user who
-types `?acct=99999` influences what a query returns.  A query parm is user
-input, validated like any other where the application reads it, and a
-per-session database role means an id outside the caller's reach finds
-nothing.
-
-Loadbare is for applications, not sites.  Every route is answered with the
-same document, and a path that names no page is found out in the browser —
-see [An unknown page](#an-unknown-page).
-
-#### Links
-
-An `<a>` carrying `lb-url-link` moves within the application.  On a plain
-primary click — the first button, no modifier key, not already handled — the
-hub pushes a history entry for the `href`'s path and query string, and loads
-the page there.  Any other click, and any anchor without `lb-url-link`,
-behaves like any other link, so leaving the application is the default and
-staying in it is the opt-in.
-
-```html
-<nav>
-  <a href="/" lb-url-link>Home</a>
-  <a href="/members" lb-url-link>Members</a>
-  <a href="https://example.com/docs">Docs</a>
-</nav>
-```
-
-The attribute takes no value.
-
-Path space is flat.  A path such as `/members` links to the `members.*` files
-on the server.
-
-The query string is kept.  `/transactions?date_begin=2026-09-01` opens the
-transactions page narrowed to those dates.
-
-The browser's Back and Forward load the page at the URL they arrive at, the
-same way.
-
-#### Query parms
-
-A control that narrows what a page shows updates `lb-url` rather than
-sending a request.  Put it inside an element naming `lb-url`, with
-`lb-column` naming the parm and `lb-request="lb-row-update"`:
-
-```html
-<div lb-query="lb-url">
-  <select lb-column="team" lb-request="lb-row-update">
-    <option value="">Every team</option>
-    <option value="Engines">Engines</option>
-  </select>
-</div>
-```
-
-The hub answers the request itself.  It sets the parms the request names in
-the URL and leaves every other parm as it is, since one may have arrived by
-link with no control on screen to say it again.  An empty value takes the
-parm out, so a URL is as long as the user has narrowed the page.  A request
-that leaves the URL as it was does nothing.  `lb-page-label` and
-`lb-page-unknown` are the hub's, and a request never sets them.
-
-The update replaces the current history entry: changing what a page shows is
-not going anywhere, so Back leaves the page rather than walking back through
-every choice.  `lb-url-push` on the element carrying `lb-request` makes the
-update push an entry instead.
-
-When `lb-path` takes a new value, the hub pushes a history entry, and the
-new URL carries only the query parms the request names.
-
-Every load lands `lb-url`, and a parm the URL does not carry lands empty on
-every element naming it as a column, so a control shows what the address
-bar says after Back as well as after a reload.  This is the one exception
-to landing, where a row sets the columns it names and leaves the rest as
-they were: the hub reads the column names under `lb-query="lb-url"` and
-names each one in the row it lands.
-
-The hub sends the query parms with every round trip, a page load and a
-request alike.  The server passes them to `contextFor` — see
-[The Express server](#the-express-server).  Loadbare assigns no parm a
-meaning: a column of `lb-url` whose name begins with `lb-` is never a query
-parm.  An order or a filter the hub applies to rows already on the page is
-a [choice](#choices), not a parm.
-
-#### An unknown page
-
-When no page's stub matches the path, `lb-page-unknown` is `true` and
-`lb-page-label` is null.  The hub calls `showModal()` on the
-`<dialog lb-url-unknown>`, where the chrome has one, and reports the path to
-the console.  A chrome with none shows nothing.
-
-`lb-url` lands before the page is looked up, so the dialog shows it by
-naming it like any other element:
-
-```html
-<dialog lb-url-unknown lb-query="lb-url">
-  The URL <span lb-column="lb-path"></span> is not in this app.
-</dialog>
-```
-
-A path that names no page is detected in the browser, after a successful
-200: every route gets the same document, so there is no server-delivered
-404.
-
-#### When a server response moves the URL
-
-Some query parms can only be known once a write has run.  After an insert,
-the key of the new row exists only on the server.  After a delete, only the
-server knows that the row the page was showing is gone.
-
-The usual web answer is Post/Redirect/Get: the server answers the write with
-a redirect to a URL naming the result, and the browser makes a second request
-to load it.  Loadbare/app does the same work in one round trip.
-
-A handler returns `url()`, a new row for `lb-url`.  The server loads the page
-at the resulting URL, as a cold load of it would: `onPageEnter`, then every
-query.  The response carries the `lb-url` item followed by that load.  The
-hub writes the URL and then lands the load.
-
-```ts
-rowInsert: {
-  run: async (ctx, { values }) => {
-    const id = await ctx.db.addAccount(values);
-    return url({ acct: String(id) });
-  },
-  refresh: [],
-},
-```
-
-- A column other than `lb-path` is a query parm.  Parms the row does not
-  name are kept, and an empty value removes its parm.
-- A row carrying `lb-path` for another page enters that page with only the
-  parms the row names, and pushes a history entry.  Otherwise the update
-  replaces the history entry, or pushes one when the element that issued the
-  request carries `lb-url-push`.
-- The row names at least one column, and every value is a string.  Otherwise
-  the server warns, ignores the row, and runs the refresh set as usual.
-- The refresh set does not run, and anything else the handler returned is
-  dropped.  Both were answers for the URL the page is leaving.
-- If loading the page fails, the write has still happened.  The response
-  carries the `lb-url` item alone, and the hub loads the page itself.  A
-  failure there is a page load's, and is not stamped on the element that
-  issued the request.
-- A user who has moved by the time the response arrives, to another page or
-  to other query parms, keeps the URL they are on.
-
-`onPageEnter` may return `url()` the same way, to move the page before
-anything shows, as an application restoring the parms the user last had
-does.  The page loads at the new URL in the same round trip, and
-that load does not follow `onPageEnter` again.  A `url()` leading to the
-page and parms already in hand is ignored, so the page loads once.  When to
-restore is the application's rule, such as only when the URL carries no
-parms of its own.
-
-```ts
-// The application put the parms on ctx in contextFor.
-onPageEnter: async (ctx) => {
-  if (ctx.parms.size > 0) return;
-  const saved = await ctx.db.savedView("accounts");
-  if (saved) return url(saved);
-},
-```
-
-Saving what the user has on screen is a declared request with
-`refresh: []`, whose handler each page passes to a routine the
-application's pages share.  A custom element naming `lb-url` sees every
-change of the URL and issues it.
-
-The page is loaded with a second context, built by `contextFor` from the new
-parms — see [The Express server](#the-express-server).
-
-### Choices
-
-The hub serves the query `lb-choices`, of kind `row`, keyed by `lb-path`,
-with a column for each choice the user made for how rows show: an
-[order](#order) or a [filter](#filters).  The application names the
-columns.  It lands wherever an element names it, like any server query.
-
-A control inside `lb-query="lb-choices"` that sends `lb-row-update` makes a
-choice.  A request with `lb-row-update` for `lb-choices` or `lb-url` from
-anywhere on the page is keyed by the path, so a custom element may
-dispatch one without sitting inside the query.
-
-A choice joins the ones already made, and needs no round trip to show:
-every element whose `lb-order` or `lb-filter` reads a column that changed
-lands its query's last answer again, so it shows what a round trip carrying
-the choice would.  Then the hub sends `lb-row-update` for `lb-choices`,
-keyed by the path, with every choice made on the page as `values`, and no
-element pending.  The server runs the page's `onChoices` with them, when it
-has one, and otherwise answers nothing.  Whatever `onChoices` returns lands,
-and by convention it returns nothing.
-
-Choices hold until the page changes, and a change of query parm keeps them.
-On entering a page, every column named under `lb-query="lb-choices"` lands
-empty.  `onPageEnter` restores them by returning `choices()`, alone or
-spread beside `url()`:
-
-```ts
-onPageEnter: async (ctx) => {
-  const saved = await ctx.db.savedChoices("accounts");
-  if (saved) return choices(saved);
-},
-onChoices: (ctx, chosen) => ctx.db.saveChoices("accounts", chosen),
-```
-
-The page load then answers the `lb-choices` item first, then the queries.
-When `url()` moves the page, the choices arrive with the load at the new
-URL.  A
-`choices()` naming no column, or holding a value that is not a string, is
-reported on the server console and ignored, as for `url()`.
-
-### The markup checks
-
-The builder checks the chrome and every page, after expansion, and refuses
-to build on any of these:
-
-- An `lb-` attribute that is not a developer attribute: `lb-query`,
-  `lb-column`, `lb-show`, `lb-group`, `lb-count`, `lb-sum`, `lb-avg`,
-  `lb-min`, `lb-max`, `lb-order`, `lb-filter`, `lb-request`, `lb-select`,
-  `lb-url-link`, `lb-url-push`, `lb-url-unknown`.  Every other `lb-` attribute is a stamp.
-  `lb-exp-slot` and `lb-exp-template` are consumed by expansion and never
-  reach the check.
-- `lb-request` naming a value that begins with `lb-` and is not one of the
-  three request names.
-- `lb-url-link` on anything but an `<a>`.
-- `lb-url-push` on an element with no `lb-request`.
-- `lb-url-unknown` on anything but a `<dialog>`, and in the chrome, outside
-  `<lb-hub>`.
-- `lb-show` on a `<template>`, on a row template's root, or with no
-  `lb-query` around it.
-- `lb-show="!"` or `lb-show="!!column"`, which reverse no column.
-- `lb-order` or `lb-filter` on an element not carrying `lb-query`, or naming
-  no column.
-- `lb-select` on anything but an `<input type="checkbox">`, outside a row
-  template, or beside `lb-column` or `lb-request`.
-- A `command` beginning `--lb-` that is not one of the three
-  [commands](#a-form-pointed-at-a-row), and one of them with no
-  `commandfor`.
-- `lb-group` on anything but a `<template>`, or on one holding no
-  `<template>` for its contents.
-- An aggregate on a `<template>`, and any but `lb-count` naming no column.
-- A chrome without exactly one `<lb-hub>` and exactly one `<main>`, a
-  `<main>` outside `<lb-hub>`, or a `<main>` with anything in it but
-  whitespace.
-- A page carrying an `<lb-hub>` or a `<main>`.
-
-The builder also reads the script of every custom element it ships, other
-than `<lb-hub>`, and refuses one that declares a method, accessor or field
-whose name begins with `lb` and a capital and is not in
-[Reserved methods](#reserved-methods).
-
-`lb-column` with no ancestor row is allowed: the hub gathers from it.
-
-Script never assigns an `lb-` attribute, so the markup states every one
-that exists, and checking the markup is sound.
-
-### Uncommon layouts
-
-The hub supports these layouts and adds no check to refuse them.  They are
-uncommon, and Loadbare/app does not shape itself around them.
-
-- **A radio button in a row template.**  The browser groups radio buttons
-  by `name`, and a row template repeats one `name` in every live row.  The
-  hub stamps each radio button's `name` with the `name` written, or its
-  column when none is, followed by `-` and the live row's key, so each live
-  row holds a group of its own.
-- **Several rows not yet entered, each holding radio buttons.**  A
-  [row not yet entered](#a-row-not-yet-entered) has an empty key, so the
-  radio buttons of every such row share one `name` and form one group.
-- **Radio buttons populated from a query.**  A radio button in a query's row
-  template answers to that query's row, as any element there does, so which
-  row and column it lands from and gathers to follows from where the layout
-  puts it.  The result is the same as in any framework that populates radio
-  buttons from a query.  A choice among a query's rows is better made with a
-  form-associated control, such as `lb-options` in `@loadbare/widgets`.
-
-## Application files
-
-### Chrome
-
-The Loadbare/app builder always requires exactly one file
-named `chrome.html`, located anywhere in builder `--src`.
-
-The chrome is the application's single HTML document.  This is
-where the standard landmarks go: header, nav, footer, main.
-
-The file is an HTML document, which must contain:
-- `<lb-hub>` inside `<body>`.  The hub can only act on its children,
-  that is why it is usually nested right below `<body>`. 
-- One empty `<main>` inside `<lb-hub>`.  The builder refuses a chrome
-  without exactly one of each, and a page carrying either.
-- The script tag for `/client.js`, the javascript bundle.
-
-It may also contain:
-- `/app.css`, the stylesheet bundle
-- A `<dialog lb-url-unknown>`, which the hub opens when the path names no
-  page.  It goes inside `<lb-hub>`, like everything the hub acts on; the
-  builder rejects one placed elsewhere.
-- The `hidden` attribute on `<body>`, which the hub removes once the first page has landed.
-
-```html
-<!-- src/chrome.html -->
-<!doctype html>
-<html lang="en">
-  <head>
-    <meta charset="utf-8" />
-    <title>Membership Roster</title>
-    <script src="/client.js" defer></script>
-    <link rel="stylesheet" href="/app.css" />
-  </head>
-  <body hidden>
-    <lb-hub>
-      <header lb-query="lb-url">
-        <h1>Membership Roster</h1>
-        <h2 lb-column="lb-page-label"></h2>
-      </header>
-      <nav>
-        <a href="/" lb-url-link>Home</a>
-        <a href="/members" lb-url-link>Members</a>
-        <a href="https://example.org/">Our website</a>
-      </nav>
-      <main></main>
-      <dialog lb-url-unknown lb-query="lb-url">
-        The URL <span lb-column="lb-path"></span> is not in this app.
-      </dialog>
-    </lb-hub>
-  </body>
-</html>
-```
-
-The chrome's `<title>` shows until the first page lands, and each page's
-title replaces it — see [The URL](#the-url).
-
-### Pages
-
-The page namespace is flat.  Loadbare/app does not care where in the `--src`
-the page files are located, but they must be unique across the application.
-A page `/deep/path/to/mypage.page.html` is routed to `/mypage`.
-
-Pages are grouped as
-- `<stub>.page.html` is recognized as navigable and capable of
-  having associated queries and requests
-- `<stub>.queries.ts` are the queries for a page
-- `<stub>.requests.ts` respond to the requests from the browser
-
-The stub of a page must match the path used in links,
-so that `<a href="/members" lb-url-link>Members</a>` has matching
-files `members.page.html` et al.
-
-#### Page HTML
-
-The markup in `<stub>.page.html` is the same HTML as everywhere else
-in a Loadbare/app application, see [HTML](#html).
-
-A page file may carry a `<title>`.  The builder removes it and stamps its
-text content as `lb-page-title` on the page, and the hub shows it as
-`lb-page-label`.
-
-```html
-<!-- src/pages/members.page.html -->
-<title>Members</title>
-<h1>Members</h1>
-```
-
-The builder wraps each expanded page in
-`<template lb-page="<stub>" lb-page-title="...">` and puts it in the built
-document.  The hub reads `lb-page` to find the page a path names.
-
-| Stamp           | The builder stamps it with                    |
-| --------------- | --------------------------------------------- |
-| `lb-page`       | The page's stub, which the hub reads          |
-| `lb-page-title` | The text content of the page file's `<title>` |
-
-## The server
-
-A page's server half is two files, `<stub>.queries.ts` and
-`<stub>.requests.ts`.  Each pairs with `<stub>.page.html` by sharing its
-stub, as stated in [Pages](#pages).  Either may be absent, and one with no
-matching page is a build error.
-
-### The Express server
-
-Loadbare/app ships no server.  The application writes an ordinary Express
-app.  Express is a peer dependency, installed by the application.
-
-The builder's artifacts oblige that server to handle four things: the
-client script, the stylesheet, the hub's data channel, and the one HTML
-document.
-
-| Handle                       | With                |
-| ---------------------------- | ------------------- |
-| `/client.js`                 | `dist/client.js`    |
-| `/app.css`                   | `dist/app.css`      |
-| `hubRoutes(hub, contextFor)` | The hub's own route |
-| Every other GET              | `dist/app.html`     |
-
-The builder writes `pages.ts` into `--out` whenever any page has a
-`.queries.ts` or a `.requests.ts` file.  It imports each of them, calls
-`createHub()` once over the lot, and exports the result as `hub`.  The
-server imports that rather than maintaining the registry by hand.
-`createHub` is the only implementation of the `Hub` interface, which may
-gain members in any release; an application never implements it.
-
-```ts
-// server.ts
-import path from "node:path";
-import { readFileSync } from "node:fs";
-import express, { type Request } from "express";
-import { hubRoutes } from "@loadbare/app/express";
-import type { HubContext } from "@loadbare/app/server";
-import { hub } from "./dist/pages";
-import { openDb } from "./src/database";
-
-const DIST = path.resolve("dist");
-const app = express();
-
-// All data requests are handled by the hub
-// This example shows an application-specific openDB()
-function contextFor(_req: Request): HubContext {
-  return { db: openDb() };
-}
-app.use(hubRoutes(hub, contextFor));
-
-// Static assets, then the catch-all for app.html
-app.get("/client.js", (_req, res) => res.sendFile(path.join(DIST, "client.js")));
-app.get("/app.css", (_req, res) => res.sendFile(path.join(DIST, "app.css")));
-app.get(/.*/, (_req, res) =>
-  res.type("html").send(readFileSync(path.join(DIST, "app.html"), "utf-8")),
-);
-
-app.listen(8787);
-```
-
-Explaining Express is beyond the scope of this technical reference.  The
-only real requirement is that the catch-all for app.html is at the end,
-so it does not catch any other files.
-
-`hubRoutes` mounts `express.json()` on its own routes, and takes that
-function's options under `json` in an optional third argument.  The default
-limit of 100 KB refuses an oversized body with a 413 before any handler
-runs, and the server log names the option.  A page that sends a file's text
-as a value needs more:
-
-```ts
-app.use(hubRoutes(hub, contextFor, { json: { limit: "5mb" } }));
-```
-
-`hubRoutes` answers `POST /lb/<stub>`, with the query string the browser is
-showing after it, verbatim.  It hands `contextFor` that query string's parms
-as a second argument, and `contextFor` puts on the context whatever a query
-reads from them.  They are user input:
-
-```ts
-function contextFor(req: Request, parms: URLSearchParams): HubContext {
-  return { db: openDb(), acct: parms.get("acct") ?? "" };
-}
-```
-
-Read the parms from that argument, not from `req.query`.  After a request
-whose handler returned `url()`, `contextFor` is called a second time for
-the same request, with the new parms, to load the page at them.  So it must
-be safe to call twice, and a write must be visible to the second context by
-the time its `run` returns.  A handle opened per request without a
-transaction around it is both.
-
-Give the server the origin root.  The hub reaches its own endpoints by
-absolute path, so an application cannot be hosted under a subpath such as
-`example.com/myapp/`, and anything proxying in front of the server passes
-the whole path space through unchanged.
-
-### Page Queries
-
-`<stub>.queries.ts` exports one object named `queries`, typed `Queries`.
-Each key is a query name, which the markup names with `lb-query`.
-
-A query's kind and key belong to its name.  Declare each query with
-`row(key, run)` or `rows(key, run, options)`, naming the key column first.
-A `rows` query's `options` declare its [order](#order).  A query
-cannot be built without one of these functions.  Every query has a key; an
-aggregate row answers with a constant one.
-
-```ts
-// members.queries.ts
-import { row, rows, type Queries } from "@loadbare/app/server";
-
-export const queries: Queries = {
-  roster: rows("id", (ctx) => ctx.db.members()),
-  summary: row("id", async (ctx) => ({
-    id: "all",
-    count: String(await ctx.db.memberCount()),
-  })),
-};
-```
-
-A `row` query returns one object, or `null` when it finds no row, and a
-`rows` query returns an array of objects, which the page shows in that order when the query declares none.  An answer that disagrees with
-its declared kind is left out of the response, with a warning naming the
-query.
-
-Query names cannot begin with `lb-`, that namespace is reserved for
-Loadbare/app queries the hub serves in the browser, such as
-[`lb-url`](#the-url).  `createHub` refuses at startup a page that declares
-such a name as a query, a handler or a `crud` entry, and a query whose order
-has a term naming no column.
-
-Every query and every handler receives `ctx`, the application's own request
-context.  The application builds it once per request and hands it to the hub,
-see [The Express server](#the-express-server).  Loadbare/app declares it empty
-and never reads it, so a query finds exactly what the application put there,
-which is usually a database handle opened for the authenticated caller.
-
-Queries should not return deltas, deltas are handled in the `.requests.ts` file
-as explained in the next section.
-
-### Page Requests
-
-`<stub>.requests.ts` exports one object named `requests`, typed `Requests`.
-It has four optional keys.
-
-| Key           | Keyed by              | Answers                                            |
-| ------------- | --------------------- | -------------------------------------------------- |
-| `handlers`    | The request name      | The page's declared requests                       |
-| `crud`        | A query name          | The three requests Loadbare provides               |
-| `onPageEnter` | Nothing               | Runs once on entering the page, before its queries, and may move the URL or restore [choices](#choices) |
-| `onChoices`   | Nothing               | Runs with every choice made on the page, each time the user makes one |
-
-The server resolves a declared request against `handlers`, and a request
-Loadbare provides against `crud` under the request's query.  A name with no
-entry there logs a server console warning naming the page and the missing
-entry, and answers 200 with no response items, so nothing lands and
-`lb-request-pending` clears from the element that issued the request.  A
-request carrying no name answers 400, and a `run` that throws answers 500.
-
-Every handler under `handlers` and `crud` has the same two members.  `run`
-performs the work, and `refresh` names the queries to re-run once it has.
-A query belongs there when its answer changed, never to fill an element the
-request's answer creates: that element is filled from the last answer its
-query landed.
-
-`run` receives the same `ctx` and the request less its name: `query`, `key`
-and `values`, as present.
-
-`run` may also return answers of its own, by query name, which are laid over
-the refreshed ones.  That is how a delta reaches the browser: wrap it in
-`patch()`, naming the rows that arrived or changed and the keys that went.
-
-A refreshed `rows` query sends every row to say what changed.  An update or
-a delete names its row by key, and an insert has the new row's key once it
-has written it, so each handler knows what changed and answers with a
-patch, which the hub places by the query's [order](#order): `createHub`
-refuses at startup a `crud` `rowInsert`, `rowUpdate` or `rowDelete` on a
-`rows` query whose `refresh` names that same query.  A `row` query sends one
-row and may refresh itself.
-
-`run` may instead return `url()`, a new row for `lb-url`, naming query parms
-only the write can know, such as the key of a row it inserted.  The page
-then loads at them in the same round trip, in place of the refresh set — see
-[When a server response moves the URL](#when-a-server-response-moves-the-url).
-A `rowDelete` that removes the row on screen returns `url({ acct: "" })`
-and leaves any other delete to its refresh set.
-
-```ts
-// members.requests.ts
-import { patch, type Requests } from "@loadbare/app/server";
-
-export const requests: Requests = {
-  handlers: {
-    resetRoster: {
-      run: (ctx) => ctx.db.resetMembers(),
-      refresh: ["roster"],
-    },
-  },
-  crud: {
-    roster: {
-      rowDelete: {
-        run: async (ctx, { key }) => {
-          await ctx.db.deleteMember(key);
-          return { roster: patch({ drop: [key] }) };
-        },
-        refresh: [],
-      },
-    },
-  },
-};
-```
-
-Each key under a `crud` entry is a request name with its prefix stripped and
-the rest camel-cased, so the attribute, the wire and this key are one
-vocabulary.  A query with no `crud` entry permits none of them.
-
-| Request name    | Key under `crud` | `run` receives  |
-| --------------- | ---------------- | --------------- |
-| `lb-row-insert` | `rowInsert`      | `values`        |
-| `lb-row-update` | `rowUpdate`      | `key`, `values` |
-| `lb-row-delete` | `rowDelete`      | `key`           |
-
-A `rowUpdate` sets the columns `values` names and leaves the rest as they
-are, as an SQL `UPDATE` does.  A form sends the controls it holds and a
-control carrying `lb-request` sends itself, so one handler answers both.
-
-### The wire
-
----- UNEDITED ----
-
-One path, one method.  The hub sends every round trip as
-`POST /lb/<stub>?<query string>`, with the query string the browser is
-showing.  An empty body asks for the page load.  Any other body is a
-request:
-
-```ts
-interface HubRequest {
-  name: string;
-  query?: string;
-  key?: string;
-  keys?: string[];
-  values?: Record<string, string>;
-  rows?: Record<string, { key: string; values: Record<string, string> }[]>;
-}
-```
-
-A refused request is answered with status 422 and
-`{ refusal: { message?, columns? } }`, and any other failure with 500 and
-no body — see [Refusals](#refusals).  Every other response is an array of
-response items:
-
-```ts
-interface ResponseItem {
-  query: string;
-  kind: "row" | "rows";
-  key: string;
-  row?: Row;
-  rows?: Row[];
-  patch?: { rows?: Row[]; drop?: unknown[] };
-}
-```
-
-A response item carries exactly one of `row`, `rows` or `patch`.  A patch
-answers a `rows` query only: rows named in `rows` are added or updated, keys
-in `drop` are removed, and every other row is left alone.
-
-A `rows` item also carries `order` when the query declares one.
-
-A choice is sent as `lb-row-update` for `lb-choices`, keyed by the path,
-with every choice made on the page as `values`; see [Choices](#choices).
-
-`createHub(pages)` builds the `Hub`, which has two calls, both answering
-with response items: `dataForPage(page, ctx, options)` for a page load, and
-`runRequest(page, request, ctx)` for a request.  `options.parms` are the
-parms the page is loaded at, and `options.follow` false ignores a `url()`
-from `onPageEnter`; `hubRoutes` passes both.
-
-## Custom elements
-
----- UNEDITED ----
-
-A custom element is an element defined by `customElements.define`, and
-follows these fixed rules in a Loadbare/app application:
-- Its name contains a hyphen, as HTML requires, like `<my-custom-element>`.
-- Its element file, if present, is `my-custom-element.html`.
-- Its script, if present, is `my-custom-element.browser.ts`.  The
-  `browser` segment is a safety feature, requiring the file to be
-  explicitly named as a browser file, to help prevent unfortunate
-  naming collisions where a server file happens to have the name of
-  a custom element and gets built into the browser bundle.
-
-A custom element must have one or the other of an element file and a
-script, and it may have both.  If it has neither, the builder reports an
-error.
-
-To use custom elements from a widget library, add the library to
-`imports.ts` anywhere in the builder's `--src`:
-
-```ts
-export default ["@scope/library-name"];
-```
-
-Import every attribute name from `@loadbare/app/constants` — see
-[Constants](#constants).  Never write one as a string literal.
-
-### What the hub and an element say to each other
-
-Each direction has one mechanism for each kind of message:
-
-| Direction      | What                                        | How                          | Today                                            |
-| -------------- | ------------------------------------------- | ---------------------------- | ------------------------------------------------ |
-| Hub to element | State that lasts                            | An attribute the hub stamps  | `lb-column-value`, `lb-key-value`, `lb-query-row-count`, `lb-group-*`, `lb-row-*`, `lb-request-pending`, `lb-request-error` |
-| Hub to element | State the platform already names           | A property                   | A control's `value`                              |
-| Hub to element | What the hub did                            | An optional `lb` method      | `lbAttached`, `lbRowsLanded`, `lbRequestDone`, `lbDetached` |
-| Hub to element | A moment an element started                 | A bubbling event             | `lb-request-done`                                |
-| Element to hub | A moment                                    | A bubbling event             | `lb-request`, and `change`, `click` and `submit` |
-
-State is an attribute, because a stylesheet can select on it.  A method is
-how the hub tells one element what it just did to that element.  A moment is an event, because the element that cares is
-often an ancestor of the one it concerns, and an event reaches it with no
-knowledge of either.
-
-### Controls
-
-A form-associated custom element with a `value` property that fires
-`change` is a control.  The hub sets its `value` when a column lands, and
-gathers its `value` when a request is issued, exactly as for a native
-`<input>`.  It commits on `change`, and belongs to its form owner, which the
-browser tracks and the `form` attribute names.
-
-```ts
-class NoteField extends HTMLElement {
-  static formAssociated = true;
-  // a `value` property, and a `change` event when the edit commits
-}
-```
-
-A custom element that is not a control receives `lb-column-value` and
-renders it; its content is never replaced.
-
-### Lifecycle
-
-A custom element hears the hub's lifecycle, never the browser's.  The hub
-calls four optional methods, which the `HubLifecycle` interface in
-`@loadbare/app/types` declares:
-
-| The hub                                          | A custom element hears          |
-| ------------------------------------------------ | ------------------------------- |
-| Places it: chrome at startup, a page, a new live row, a new group | `lbAttached()`, once, after every column has landed on it |
-| Lands rows on it                                 | `lbRowsLanded()`                |
-| Finishes a request committed by it or inside it  | `lbRequestDone(detail, origin)` |
-| Removes it: a row or group done leaving, the page replaced | `lbDetached()`, once  |
-| Moves a live row the order put elsewhere         | Nothing                         |
-| Turns `lb-show` off or on                        | Nothing                         |
-| Hides a row or a group for a filter              | Nothing                         |
-
-The chrome and a page are placed as the page's first answer lands, or once
-that round trip fails.  An element under an `lb-show` that is off is placed
-inside its template, so `lbAttached` runs whether it shows or not.  `lbAttached` reaches an outer
-custom element before the ones inside it, and `lbDetached` the inner ones
-first.  `lbRequestDone` reaches the committing element and every custom
-element around it, innermost first, before the `lb-request-done` event.
-An element a script creates hears none of them.
-
-A listener on the element itself goes in the constructor, which reads no
-attribute and no child.  A child is looked up when it is needed.  Work done
-once per instance goes in `lbAttached`, and its undoing in `lbDetached`.
-
-The build refuses a script that declares `connectedCallback`,
-`disconnectedCallback`, `adoptedCallback` or `connectedMoveCallback`.
-
-### Row hooks
-
-The hub calls `lbRowsLanded()` on a custom element with `lb-query` and a row
-template, after the rows land, with every row placed and stamped.  The hub
-places every row and builds every group itself, so a custom element reacts
-to rows and never places them.  Scrolling to the row the page's request
-created is the case:
-
-```ts
-lbRowsLanded() {
-  this.querySelector(`[${ATTR_ROW_REQUESTED}="${REQUESTED_CREATED}"]`)
-    ?.scrollIntoView({ block: "nearest" });
-}
-```
-
-A custom element under an `lb-show` that is off holds its rows all the
-same, and the hook runs as they land.
-
-`applyRow(root, row)`, exported by `@loadbare/app`, fills `root` from one
-row, the same operation that fills a live row.
-
-## Internal linkage
-
----- UNEDITED ----
-
-The endpoint path, `index` for the bare path, the constant holding the
-request deadline, the generated client entry, and the `./build` export.
-Nobody outside this package reads any of it.  The deadline itself is
-behavior an application sees — see [The round trip](#the-round-trip) — and
-giving it a knob later takes nothing away.
-
-## Cross-reference
-
-Every name Loadbare/app owns, in one place. Each row names the section
-that defines it. The definition lives there and only there.
-
-### Builder flags
-
-Loadbare/app owns every flag in this table.
-
-| Flag       | Default | Names                                     | Defined in                                        |
-| ---------- | ------- | ----------------------------------------- | ------------------------------------------------- |
-| `--src`    | `src`   | The application's own tree, scanned whole | [What the builder scans](#what-the-builder-scans) |
-| `--out`    | `dist`  | Where the builder writes                  | [Running the builder](#running-the-builder)       |
-| `--watch`  | off     | Rebuild on change under `--src`           | [Running the builder](#running-the-builder)       |
-| `--minify` | off     | Minify `client.js` and `app.css`          | [Running the builder](#running-the-builder)       |
-
-### Reserved file names
-
-Loadbare/app owns every file name and pattern in this table.  A file so
-named carries its meaning wherever it sits in the `--src` tree, so an
-application must not use one of these names for anything else.
-
-| File                    | How many                       | Holds                                                    | Defined in                                              |
-| ----------------------- | ------------------------------ | -------------------------------------------------------- | ------------------------------------------------------- |
-| `chrome.html`           | Exactly one                    | The application's one HTML document                      | [Chrome](#chrome)                                       |
-| `imports.ts`            | Zero or one                    | Default-exports an array of widget library package names | [Imported widget libraries](#imported-widget-libraries) |
-| `<stub>.page.html`      | One per page                   | One page's markup, as a fragment                         | [Pages](#pages)                                         |
-| `<stub>.queries.ts`     | Zero or one per page           | That page's queries                                      | [Page Queries](#page-queries)                           |
-| `<stub>.requests.ts`    | Zero or one per page           | That page's requests                                     | [Page Requests](#page-requests)                         |
-| `<tag-name>.html`       | Zero or one per custom element | One element file, as a fragment                          | [Custom elements](#custom-elements)                     |
-| `<tag-name>.browser.ts` | Zero or one per custom element | One custom element's script, `.js` also accepted         | [Custom elements](#custom-elements)                     |
-| `*.css`                 | Any number                     | A stylesheet, concatenated into `app.css`                | [Running the builder](#running-the-builder)             |
-
-### Build outputs
-
-Loadbare/app owns every file name in this table.  The builder writes them
-into `--out`.  Which of them exist depends on the application: `app.css`
-only when some origin has a stylesheet, `pages.ts` only when some page has a
-`.queries.ts` or a `.requests.ts`.
-
-| Path               | Written           | Holds                                                              | Read by    | Defined in                                  |
-| ------------------ | ----------------- | ------------------------------------------------------------------ | ---------- | ------------------------------------------- |
-| `/app.html`        | Always            | The chrome, built                                                  | The server | [Chrome](#chrome)                           |
-| `/client.js`       | Always            | `<lb-hub>` and every custom element the application uses           | The chrome | [Chrome](#chrome)                           |
-| `/client-entry.ts` | Always            | The generated entry `client.js` is bundled from                    | Nothing    | [Running the builder](#running-the-builder) |
-| `/app.css`         | With a stylesheet | Every stylesheet in the cascade, concatenated                      | The chrome | [Chrome](#chrome)                           |
-| `/pages.ts`        | With page data    | The one `createHub()` call, over every page's queries and requests | The server | [The Express server](#the-express-server)   |
-
-### Reserved package.json keys
-
-Loadbare/app owns every key in this table. A widget library declares them.
-An application never does.
-
-| Key                | Value                     | Means                                                                                | Defined in                                              |
-| ------------------ | ------------------------- | ------------------------------------------------------------------------------------ | ------------------------------------------------------- |
-| `loadbare.widgets` | A path inside the package | Where this package's custom elements are. Absent means the whole installed directory | [Imported widget libraries](#imported-widget-libraries) |
-
-### Reserved namespaces
-
-Loadbare/app owns every namespace in this table. Ownership of a name and
-ownership of its behavior are stated separately, because they differ.
-
-| Namespace | Applies to                                                  | Loadbare owns                                       | Defined in                                      |
-| --------- | ----------------------------------------------------------- | --------------------------------------------------- | ----------------------------------------------- |
-| `lb-*`    | Attributes, their values, queries, columns of `lb-` queries, requests, custom elements, events | The names and their behavior | [The lb-* namespace](#the-lb--namespace)        |
-| `--lb-*`  | Values of HTML's `command` attribute                        | The names and their behavior                        | [Reserved commands](#reserved-commands)         |
-| `exp-*`   | Attributes on a custom element                              | The behavior; element file authors pick the names   | [Build time parameters](#build-time-parameters) |
-| `lb*`     | Methods on custom elements                                  | The names and their behavior                        | [Row hooks](#row-hooks)                         |
-
-#### The lb-* namespace
-
-Every name beginning with `lb-` belongs to Loadbare/app — see
-[Names](#names).  An application writes the attributes this section names,
-and invents none of its own, because a name Loadbare has not defined today
-it may define tomorrow.
-
-| Attribute         | Written by    | On                                  | Defined in                                    |
-| ----------------- | ------------- | ----------------------------------- | --------------------------------------------- |
-| `lb-query`        | Developer     | Any element                         | [Landing](#landing)                           |
-| `lb-column`       | Developer     | Any element                         | [Landing](#landing)                           |
-| `lb-show`         | Developer     | Any element but a `<template>`      | [Displaying by condition](#displaying-by-condition) |
-| `lb-request`      | Developer     | Any element                         | [Requests](#requests)                         |
-| `lb-select`       | Developer     | A checkbox in a row template        | [Selecting rows](#selecting-rows)             |
-| `lb-url-link`     | Developer     | An `<a>`                            | [Links](#links)                               |
-| `lb-url-push`     | Developer     | An element with `lb-request`        | [Query parms](#query-parms)                   |
-| `lb-url-unknown`  | Developer     | A `<dialog>` inside `<lb-hub>`      | [An unknown page](#an-unknown-page)           |
-| `lb-group`        | Developer     | A `<template>` holding a `<template>` | [Groups](#groups)                           |
-| `lb-count`, `lb-sum`, `lb-avg`, `lb-min`, `lb-max` | Developer | Any element but a `<template>` | [Aggregates](#aggregates) |
-| `lb-order`        | Developer     | An element with `lb-query`          | [Order](#order)                               |
-| `lb-filter`       | Developer     | An element with `lb-query`          | [Filters](#filters)                           |
-| `lb-exp-slot`     | Developer     | One element in an element file      | [Slots and templates](#slots-and-templates)   |
-| `lb-exp-template` | Developer     | An element file, and a `<template>` | [Slots and templates](#slots-and-templates)   |
-| `lb-column-value` | Hub           | Every element set from a column     | [How a column lands](#how-a-column-lands)     |
-| `lb-key-value`    | Hub           | A live row, an element a `row` lands on, and a pointed form | [Rows](#rows), [A form pointed at a row](#a-form-pointed-at-a-row) |
-| `lb-row-editing`  | Hub           | The live row a form is pointed at   | [A form pointed at a row](#a-form-pointed-at-a-row) |
-| `lb-row-selected` | Hub           | A live row its `lb-select` checkbox ticks | [Selecting rows](#selecting-rows)       |
-| `lb-row-live`     | Hub           | A live row                          | [Rows](#rows)                                 |
-| `lb-query-row-count` | Hub        | An element with a row template      | [Rows](#rows)                                 |
-| `lb-group-live`, `lb-group-column`, `lb-group-value` | Hub | Each top-level element of a group | [Groups](#groups) |
-| `lb-row-created`, `lb-row-changed`, `lb-row-moved`, `lb-row-requested` | Hub | A live row | [What happened to a row](#what-happened-to-a-row) |
-| `lb-row-leaving`, `lb-group-leaving` | Hub | A row or a group on its way out | [What happened to a row](#what-happened-to-a-row) |
-| `lb-request-pending` | Hub        | The element that issued a request   | [Request state](#request-state)               |
-| `lb-request-error`   | Hub        | The element that issued a request   | [Request state](#request-state)               |
-| `lb-request-refused` | Hub        | The element whose request was refused | [Refusals](#refusals)                       |
-| `lb-show` on a `<template>` | Hub and builder | Where an absent element stands | [Displaying by condition](#displaying-by-condition) |
-| `lb-page`         | Builder       | A page's `<template>`               | [Page HTML](#page-html)                       |
-| `lb-page-title`   | Builder       | A page's `<template>`               | [Page HTML](#page-html)                       |
-
-The builder refuses any other `lb-` attribute in markup — see
-[The markup checks](#the-markup-checks).
-
-### Reserved queries
-
-| Query    | Kind  | Key       | Columns                                                         | Defined in          |
-| -------- | ----- | --------- | --------------------------------------------------------------- | ------------------- |
-| `lb-url` | `row` | `lb-path` | `lb-path`, `lb-page-label`, `lb-page-unknown`, every query parm | [The URL](#the-url) |
-| `lb-choices` | `row` | `lb-path` | `lb-path`, every choice                                     | [Choices](#choices) |
-
-### Reserved query parms
-
-None.  A column of `lb-url` whose name begins with `lb-` is never a query
-parm — see [Query parms](#query-parms).
-
-### Reserved request names
-
-| Request name    | Runs under `crud` | Defined in                          |
-| --------------- | ----------------- | ----------------------------------- |
-| `lb-row-insert` | `rowInsert`       | [The request names](#the-request-names) |
-| `lb-row-update` | `rowUpdate`       | [The request names](#the-request-names) |
-| `lb-row-delete` | `rowDelete`       | [The request names](#the-request-names) |
-
-### Reserved commands
-
-Loadbare/app owns every value of HTML's `command` attribute beginning with
-`--lb-`.
-
-| Command        | Defined in                                          |
-| -------------- | --------------------------------------------------- |
-| `--lb-edit`    | [A form pointed at a row](#a-form-pointed-at-a-row) |
-| `--lb-new`     | [A form pointed at a row](#a-form-pointed-at-a-row) |
-| `--lb-release` | [A form pointed at a row](#a-form-pointed-at-a-row) |
-
-### Reserved tags
-
-Loadbare/app owns every tag in this table.  An application writes them and
-never defines them.
-
-| Tag        | Written in | Means                          | Defined in        |
-| ---------- | ---------- | ------------------------------ | ----------------- |
-| `<lb-hub>` | The chrome | The application's live element | [Chrome](#chrome) |
-
-### Reserved events
-
-Loadbare/app owns every DOM event in this table, both the name and what its
-`detail` carries.
-
-| Event        | Dispatched from                  | Bubbles | Cancelable | Defined in                              |
-| ------------ | -------------------------------- | ------- | ---------- | --------------------------------------- |
-| `lb-request` | The element that committed       | Yes     | No         | [The request event](#the-request-event) |
-| `lb-request-done` | The element that committed  | Yes     | No         | [The request event](#the-request-event) |
-
-### Reserved methods
-
-| Method          | On                                                  | Defined in              |
-| --------------- | --------------------------------------------------- | ----------------------- |
-| `lbAttached`    | Any custom element the hub places                   | [Lifecycle](#lifecycle) |
-| `lbRowsLanded`  | A custom element with `lb-query` and a row template | [Row hooks](#row-hooks) |
-| `lbRequestDone` | A custom element that committed, or holds one that did | [Lifecycle](#lifecycle) |
-| `lbDetached`    | Any custom element the hub removes                  | [Lifecycle](#lifecycle) |
-
-### Constants
-
-`@loadbare/app/constants` exports every name above.  Custom element code
-imports them rather than writing a string.
-
-| Constant                  | Value                                   |
-| ------------------------- | --------------------------------------- |
-| `ATTR_QUERY`              | `lb-query`                              |
-| `ATTR_COLUMN`             | `lb-column`                             |
-| `ATTR_SHOW`               | `lb-show`                               |
-| `ATTR_COLUMN_VALUE`       | `lb-column-value`                       |
-| `ATTR_KEY_VALUE`          | `lb-key-value`                          |
-| `ATTR_ROW_LIVE`           | `lb-row-live`                           |
-| `LIVE_ROW`                | `[lb-row-live]`, the selector for a live row |
-| `ATTR_QUERY_ROW_COUNT`    | `lb-query-row-count`                    |
-| `ATTR_GROUP`              | `lb-group`                              |
-| `ATTR_GROUP_LIVE`         | `lb-group-live`                         |
-| `ATTR_GROUP_COLUMN`       | `lb-group-column`                       |
-| `ATTR_GROUP_VALUE`        | `lb-group-value`                        |
-| `LIVE_GROUP`              | `[lb-group-live]`, the selector for a group's element |
-| `ATTR_COUNT`, `ATTR_SUM`, `ATTR_AVG`, `ATTR_MIN`, `ATTR_MAX` | `lb-count`, `lb-sum`, `lb-avg`, `lb-min`, `lb-max` |
-| `AGGREGATES`              | All five aggregate attributes           |
-| `ORDER_DESCENDING`        | `-`, written before a column in an order |
-| `CHOICES_QUERY`           | `lb-choices`                            |
-| `ATTR_ORDER`              | `lb-order`                              |
-| `ATTR_FILTER`             | `lb-filter`                             |
-| `FILTER_OPERATORS`        | Every filter operator, the longer first |
-| `ATTR_ROW_CREATED`        | `lb-row-created`                        |
-| `ATTR_ROW_CHANGED`        | `lb-row-changed`                        |
-| `ATTR_ROW_MOVED`          | `lb-row-moved`                          |
-| `ATTR_ROW_REQUESTED`      | `lb-row-requested`                      |
-| `REQUESTED_CREATED`, `REQUESTED_CHANGED`, `REQUESTED_MOVED` | `created`, `changed`, `moved` |
-| `ATTR_ROW_LEAVING`        | `lb-row-leaving`                        |
-| `ATTR_GROUP_LEAVING`      | `lb-group-leaving`                      |
-| `COMMAND_EDIT`, `COMMAND_NEW`, `COMMAND_RELEASE` | `--lb-edit`, `--lb-new`, `--lb-release` |
-| `LB_COMMANDS`             | All three commands                      |
-| `LB_COMMAND_PREFIX`       | `--lb-`                                 |
-| `ATTR_ROW_EDITING`        | `lb-row-editing`                        |
-| `ATTR_SELECT`             | `lb-select`                             |
-| `ATTR_ROW_SELECTED`       | `lb-row-selected`                       |
-| `ATTR_REQUEST`            | `lb-request`                            |
-| `ATTR_REQUEST_PENDING`    | `lb-request-pending`                    |
-| `ATTR_REQUEST_ERROR`      | `lb-request-error`                      |
-| `ATTR_REQUEST_REFUSED`    | `lb-request-refused`                    |
-| `LB_REFUSAL_STATUS`       | `422`                                   |
-| `ATTR_URL_LINK`           | `lb-url-link`                           |
-| `ATTR_URL_PUSH`           | `lb-url-push`                           |
-| `ATTR_URL_UNKNOWN`        | `lb-url-unknown`                        |
-| `ATTR_EXP_SLOT`           | `lb-exp-slot`                           |
-| `ATTR_EXP_TEMPLATE`       | `lb-exp-template`                       |
-| `ATTR_PAGE`               | `lb-page`                               |
-| `ATTR_PAGE_TITLE`         | `lb-page-title`                         |
-| `DEVELOPER_ATTRIBUTES`    | The sixteen attributes a developer writes |
-| `LB_EVENT_NAME`           | `lb-request`                            |
-| `LB_DONE_EVENT_NAME`      | `lb-request-done`                       |
-| `SHOW_NOT`                | `!`, written before a column in `lb-show` |
-| `LB_RESERVED_PREFIX`      | `lb-`                                   |
-| `REQUEST_ROW_INSERT`      | `lb-row-insert`                         |
-| `REQUEST_ROW_UPDATE`      | `lb-row-update`                         |
-| `REQUEST_ROW_DELETE`      | `lb-row-delete`                         |
-| `LB_ROW_REQUESTS`         | All three request names                 |
-| `KIND_ROW`                | `row`                                   |
-| `KIND_ROWS`               | `rows`                                  |
-| `URL_QUERY`               | `lb-url`                                |
-| `URL_COLUMN_PATH`         | `lb-path`                               |
-| `URL_COLUMN_PAGE_LABEL`   | `lb-page-label`                         |
-| `URL_COLUMN_PAGE_UNKNOWN` | `lb-page-unknown`                       |
-| `HUB_TAG_NAME`            | `lb-hub`                                |
-| `LB_ENDPOINT`             | `/lb`                                   |
-| `LB_REQUEST_TIMEOUT_MS`   | `10000`                                 |