@loadbare/app 0.5.6 → 0.7.0

package/docs/reference/server.md

@@ -44,7 +44,7 @@ app.listen(8787);
 |------------------------------|-------------------------------|
 | `/client.js`                 | `dist/client.js`              |
 | `/app.css`                   | `dist/app.css`                |
-| `hubRoutes(hub, contextFor)` | `GET /lb/data` and `POST /lb` |
+| `hubRoutes(hub, contextFor)` | The hub's own route            |
 | Every other GET              | `dist/app.html`               |
 
 Everything else is optional:
@@ -66,9 +66,10 @@ Serve `dist/app.html` for every route the application does not claim,
 including a path that names no page. See [`chrome.html`](./chrome.md) for the
 `<dialog lb-unknown-page>` that announces that case to the user.
 
-Give the server the origin root. A proxy in front of it passes `/lb/data` and
-`/lb` through unchanged, and the application cannot be hosted under a subpath
-such as `example.com/myapp/`.
+Give the server the origin root. The hub reaches its own route by absolute
+path, so the 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.
 
 Leave `express.json()` to `hubRoutes`, which mounts it on its own routes.
 
@@ -85,7 +86,25 @@ Run the server under a TypeScript-capable runner. The builder writes
 }
 ```
 
-Restart the server after adding or changing a `.hooks.ts` or `.queries.ts`
+Node 22.18 and later also runs it with no runner at all, since Node strips
+TypeScript types itself. `dist/pages.ts` imports each `.requests.ts` and
+`.queries.ts` file by its full name, extension included, because Node looks
+for exactly the path an import names.
+
+Enable `allowImportingTsExtensions` in the application's `tsconfig.json`
+when `tsc` type-checks the server. Without it, `tsc` rejects the `.ts`
+extensions in `dist/pages.ts`:
+
+```json
+{
+  "compilerOptions": {
+    "noEmit": true,
+    "allowImportingTsExtensions": true
+  }
+}
+```
+
+Restart the server after adding or changing a `.requests.ts` or `.queries.ts`
 file.
 
 ## Database layer
@@ -119,5 +138,5 @@ declare module "@loadbare/app/server" {
 ```
 
 Add a field for anything else a request needs — the authenticated user, a
-request id, a feature flag set. Queries and hooks read them from `ctx`; see
+request id, a feature flag set. Queries and requests read them from `ctx`; see
 [page files](./page-files.md).

package/docs/reference/widgets.md

@@ -26,11 +26,12 @@ for where a listed package sits in the cascade.
 ## `lb-input`
 
 Wraps an `<input>`. `lb-value` sets the input's `.value`. The widget sends
-nothing on its own: `data-fire-on-change` asks it to send `cell-change` on the
-input's `change`, addressed by its own `lb-query`/`lb-key`/`lb-cell`
-coordinates.
+nothing on its own: `lb-action` names what the input's `change` sends. The
+reserved `lb-cell-change` sends `lb-cell-change`; any other name sends that
+action. Either carries the input's value, and the hub adds the scope the
+input sits in.
 
-An input inside an `lb-insert` or `lb-update` form leaves the attribute off.
+An input inside an `lb-row-insert` or `lb-row-update` form leaves the attribute off.
 The form reads every `lb-cell` in it on submit and sends one request for all
 of them, so an input that also sent its own would write the same edit twice.
 
@@ -41,7 +42,7 @@ of them, so an input that also sent its own would write the same edit twice.
 
 | Attribute | Asks for |
 | ---------- | ----- |
-| `data-fire-on-change` | an edit to be sent, on `change` |
+| `lb-action` | what to send on `change`; `lb-cell-change` for the cell's own edit |
 
 ## `lb-select`
 
@@ -57,15 +58,6 @@ action carries a value.
 
 Requires `lb-action` — a change with none logs and sends nothing.
 
-## `lb-list`
-
-The plain repeater: whatever the author writes inside a
-`<template lb-key="...">` is cloned once per row, in arrival order. No
-grouping, no sorting, no request of its own — it exists because a
-`Projection` has to land on something with `acceptRows`, and a bare
-`<table>` can't be one (a custom element written inside `<tbody>` is
-discarded by the parser).
-
 ## `lb-options`
 
 A `<select>` whose `<option>`s come from a query instead of being written by
@@ -73,8 +65,8 @@ hand. The author supplies the row template inside the widget (via
 `lb-slot`), same as any list widget:
 
 ```html
-<lb-options lb-query="statuses" exp-label="Status" lb-action="setStatus">
-  <template lb-key="id" lb-group="category">
+<lb-options lb-list="statuses" exp-label="Status" lb-action="setStatus">
+  <template lb-key="id" data-group="category">
     <option lb-cell="label"></option>
   </template>
 </lb-options>
@@ -84,11 +76,11 @@ hand. The author supplies the row template inside the widget (via
 | ---------- | ----- |
 | `exp-label` | the visible `<label>` text |
 
-- The row's key becomes the option's `value` — `lb-key` supplies both, so
-  nothing is declared twice.
-- `lb-group` on the row template sections the options into `<optgroup>`s,
+- The row's key becomes the option's `value`: the `lb-key-value` the hub
+  stamps on each option is copied across, so the page names the key column
+  once, with `lb-key`.
+- `data-group` on the row template sections the options into `<optgroup>`s,
   one per distinct value, created and removed as rows arrive and leave.
-- `lb-sort` is not read by this widget.
 - A `change` sends the action named by `lb-action`, value from the
   select's `.value`.
 
@@ -102,15 +94,15 @@ heading row, the row template, and optionally a footer, each as a
 `<template>` matched to a destination:
 
 ```html
-<lb-table lb-query="ledger" exp-caption="Ledger">
+<lb-table lb-list="ledger" exp-caption="Ledger">
   <template lb-template="head">
     <tr><th>Date</th><th>Amount</th></tr>
   </template>
-  <template lb-key="id" lb-sort="date" lb-group="month">
+  <template lb-key="id" data-sort="date" data-group="month">
     <tr><td lb-cell="date"></td><td lb-cell="amount"></td></tr>
   </template>
   <template lb-template="foot">
-    <tr lb-query="ledger-total"><td>Total</td><td lb-cell="total"></td></tr>
+    <tr lb-row="ledger-total"><td>Total</td><td lb-cell="total"></td></tr>
   </template>
 </lb-table>
 ```
@@ -125,13 +117,13 @@ heading row, the row template, and optionally a footer, each as a
 | `foot` (`lb-template="foot"`) | the `<tfoot>` content |
 | slot (no `lb-template`) | the row template, via `lb-slot` on `<tbody>` |
 
-- `lb-group` on the row template sections rows under a derived heading row,
+- `data-group` on the row template sections rows under a derived heading row,
   one per distinct value, whose `colSpan` matches the row's own column
-  count. `lb-sort` orders rows within a section (or the whole body, with no
+  count. `data-sort` orders rows within a section (or the whole body, with no
   grouping) by comparing each row's cell text.
-- The `foot` destination is not delivered through `acceptRows` — it's an
-  ordinary scope carrying its own `lb-query`, resolved by name like any
-  other on the page. A grand total is a second projection of the same
+- The `foot` destination is not delivered through `lbPlaceRow` — it's an
+  ordinary scope carrying its own `lb-row`, resolved by name like any
+  other on the page. A grand total is a second query over the same
   data, not a row the hub hands the table.
 
 ## `lb-picker`
@@ -141,7 +133,7 @@ the page — for when every row is one option and nothing else varies:
 
 ```html
 <lb-picker
-  lb-query="statuses"
+  lb-list="statuses"
   exp-label="Status"
   exp-key="id"
   exp-cell="label"
@@ -155,7 +147,7 @@ the page — for when every row is one option and nothing else varies:
 | `exp-label` | the visible `<label>` text |
 | `exp-key` | the row template's `lb-key` |
 | `exp-cell` | the option's `lb-cell` |
-| `exp-group` | the row template's `lb-group` |
+| `exp-group` | the row template's `data-group` |
 
 Behavior — grouping, key-as-value, the action on change — is inherited
 whole from `lb-options`; a page author who needs a second element in the

package/docs/roadmap.md

@@ -17,32 +17,17 @@ wrong thing. Revisit when the described symptom actually shows up.
 
 ### Staleness and concurrent writers
 
-Two tabs, or two users, updating the same projection at once. A solo
-developer testing in one browser will not produce this by accident, and
-retrofitting a version or conflict check onto every tuple after the fact
-touches every widget that writes.
+Two tabs, or two users, updating the same list at once. A solo developer
+testing in one browser will not produce this by accident, and retrofitting a
+version or conflict check onto every row after the fact touches every widget
+that writes.
 
 ### Nesting
 
-Whether a tuple may contain a projection (master-detail, an expanding
-row). [Theory](./theory.md) already flags this as possibly load-bearing if
+Whether a row may contain a list (master-detail, an expanding row). [Theory](./theory.md) already flags this as possibly load-bearing if
 disallowed. Worth a decision-in-principle the first time a master-detail
 page is built, even before the mechanism is needed elsewhere.
 
-### Whether `lb-query` may be inherited
-
-Currently every scope states its own `lb-query`; nothing resolves one from
-an ancestor. Inheritance would be friendlier to the page author but adds a
-resolution rule, and a resolution rule is a mechanism this framework has
-otherwise avoided. Worth deciding before an application grows deep enough
-nesting that restating the query on every level starts to hurt.
-
-### Whether `lb-key` is always required
-
-Undecided whether every row needs `lb-key`, or only a row something
-targets (a delete button, an update form). Revisit if a list widget shows
-up that never needs to address an individual row by key.
-
 ### Pending appearance
 
 A value that hasn't arrived yet is probably derivable from an absent
@@ -112,12 +97,53 @@ enough to measure.
 
 ### Data binding utilities
 
-If a dev team wishes to make their own widgets that identify `lb-query`,
-`lb-key`, `lb-cell`, they must repeat the code that is present in the hub.
+If a dev team wishes to make their own widgets that identify `lb-list` or `lb-row`,
+`lb-key-value`, `lb-cell`, they must repeat the code that is present in the hub.
 
 Perhaps a utility that can be called, like `getDataScope(el)`, to help
 clean up the code in these cases.
 
+### Build-time checking of `lb-action` against the declared requests
+
+Release 1.0 resolves every `lb-action` value at request time. A value naming
+no entry under `actions`, or a reserved operation naming a list with no entry
+under `crud`, is found on the first click: a server console warning and an
+empty answer, described in
+[Page files](./reference/page-files.md). A typo builds cleanly.
+
+The builder already expands each page and walks the finished document in
+`checkBinding`, tracking the enclosing `lb-list` scope, so collecting every
+action name together with the list it sits in needs no new machinery. What
+it lacks is the other half of the comparison: it knows the path of a
+`.requests.ts` file and never reads its contents.
+
+Two routes to the declared names, and the choice is the decision:
+
+- **Load the built module.** Bundle the generated `pages.ts`, import it, and
+  read the keys off the finished objects. Exact, and indifferent to how the
+  object was written. The build then executes application import-time code,
+  and a builder that only reads files stops being that.
+- **Parse the source.** Read the keys statically with the TypeScript compiler
+  API. No application code runs, at the price of a real dependency and of
+  guessing wrong on anything not written as a plain object literal.
+
+Three smaller calls come with either route. The chrome belongs to no page, so
+an action there can only be required of every page or forbidden. A page with
+no requests file makes any action on it an error. And the check sees markup
+only, so it is sound only if `lb-action` is authored and never assigned by
+script — no widget assigns it today, and the rule has never been written
+down.
+
+This reverses the position stated above `walkBinding`, that markup and server
+are separate artifacts and the comparison belongs to `createHub`. The same
+machinery would then also let `lb-list` and `lb-row` names be checked against
+the declared queries.
+
+One piece is separable and needs none of the above: an `lb-action` beginning
+with `lb-` that names none of the four operations is a typo the builder can
+refuse from markup alone. `LB_ACTIONS` in `core/lb-constants.ts` exists for
+this, and the builder does not yet import it.
+
 ### A language server
 
 ...for Loadbare HTML.
@@ -128,3 +154,23 @@ Internationalization would require a potential extension to build-time
 expansion allows a strings file.  We could either preserve the fully 
 static build-time system and create multiple versions of `app.html`, or we
 could add label hydration to the page navigation stage.
+
+## Decided against
+
+Settled questions, kept here so they are not reopened.  Each names what was
+asked for and why the answer is no.
+
+### Interpolation in a placeholder
+
+`{{name}}` is the whole of an attribute value or the whole of a text node.  A
+placeholder inside a longer string, such as `title="Hello {{name}}"`, ships
+literal braces.
+
+A value that is absent with no default drops the attribute, which is how a
+boolean attribute is turned off.  Inside a longer string the same placeholder
+could only become an empty string, so one syntax would mean two things.
+Interpolation would also reserve `{{` and `|` in every text node and
+attribute value, with no escape for either.
+
+Text has a workaround: `<div>Hello, <span>{{world}}</span></div>` places the
+placeholder in a text node of its own.  Attribute values have none.

package/docs/testing.md

@@ -19,8 +19,8 @@ emulation has given up the only failure mode it was looking for.
 |------|--------------------------------------------------|-------------|
 | 1    | Expansion and the build — `build/`               | node        |
 | 2    | The engine — `server/`, and the Express adapter  | node        |
-| 3    | Landing — `hub/lb-apply.ts`, `hub/lb-rows.ts`    | jsdom       |
-| 4    | The hub — `hub/lb-hub.browser.ts`                        | jsdom       |
+| 3    | Landing — `hub/lb-apply.ts`                      | jsdom       |
+| 4    | The hub — `hub/lb-hub.browser.ts`                | jsdom       |
 
 All four tiers run under `npm test` today and need no dependency that is not
 already installed. A fifth environment — a real browser — is discussed at the
@@ -112,7 +112,7 @@ needs a browser either.
 `createHub` takes a plain object and returns an object. Nothing in
 `server/lb-server.ts` opens a socket, so the fixtures are counting stubs.
 
-- `beforeGet` runs before any query, and the whole query set runs after it
+- `onPageEnter` runs before any query, and the whole query set runs after it
 - an unknown page answers `{}` and says so
 - an unknown query name in a refresh set is skipped, and its siblings run
 - an action the page did not declare is refused — the rule that keeps the
@@ -128,7 +128,7 @@ malformed body does not throw.
 
 ## Tier 3 — Landing
 
-`applyData`, `applyTuple` and `applyRows` are the most intricate code in the
+`applyData`, `applyRow` and `applyList` are the most intricate code in the
 framework and the most likely to break in ways nobody notices. They are also
 pure DOM: no fetch, no widget upgrade, no history. jsdom is real evidence
 here.
@@ -137,11 +137,11 @@ here.
 - the root of a scope counts as a cell if it carries one, which is what makes
   an `<option>` row possible
 - a query with no scope is reported and skipped; several scopes for one query
-  are all filled; a projection landing on something that is not a list widget
+  are all filled; a set of rows landing on a scope bound with `lb-row`
   is reported rather than thrown
 - `rows` decides membership and order, so a key that did not arrive is gone
 - `patch` disturbs only what it names, in contents and in position
-- `data-rows` is counted from the DOM after reconciliation, so a set and a
+- `lb-row-count` is counted from the DOM after reconciliation, so a set and a
   patch ending in the same state report the same number
 - the `place` callback is called for a fresh row always, and for an existing
   row only under `rows`. That is today's behavior, not a decision — a patch
@@ -149,8 +149,8 @@ here.
   is true now, and is the one that flips if that changes.
 
 **Two properties**, written as loops rather than with a library. Applying the
-same `rows` twice is applying it once. And `rows(S)` reached through any
-sequence of patches is `rows(S)` reached from empty. Convergence is the
+same set twice is applying it once. And a set reached through any
+sequence of patches is that set reached from empty. Convergence is the
 actual contract of a reconciler, and those two say it better than twenty
 examples.
 
@@ -159,7 +159,40 @@ examples.
 The widget half of this tier lives in `@loadbare/widgets` and is tested
 there, against the same jsdom harness described below — see
 [`packages/widgets/AGENTS.md`](../../widgets/AGENTS.md). What follows applies
-to both, and the hub is what remains here.
+to both, and the hub element is what remains here.
+
+The hub is the one source file whose coverage is split across two tiers, so
+the split is written down rather than left to judgment. jsdom is evidence
+for everything the hub does to the document it is already holding: which
+element an event came from, what request that produces, which attributes
+land where, and which page host a path selects. It is not evidence for
+anything about a real network or a real frame, and those cases are listed
+under the browser tier below and are not written.
+
+Two things the hub reaches for do not exist in jsdom 25, so the harness
+supplies them. `fetch` is absent, and a test wants a scripted one anyway.
+`HTMLDialogElement.showModal` is absent, so the harness records the call
+instead. `history.pushState` and `popstate` are real, so navigation needs no
+help.
+
+What the hub is tested for here:
+
+- `requestFor` builds each of the three operations a native element can
+  send, and refuses a reserved name it cannot turn into one
+- a click finds the nearest `lb-action`, and skips a hyphenated tag and a
+  form, both of which own the interaction themselves
+- a submit gathers the form's cells, and reports a cell with no control
+- a request arriving with no action, or with a reserved name that is not one
+  of the four, is refused before it reaches the wire
+- `lb-pending` lands on the element that dispatched, `lb-error` replaces it
+  on failure, and the next request clears it
+- a path with no page host reports and opens the unknown-page dialog; two
+  hosts for one name report and take the first
+- `lb-navigation` lands with the path and the label of the link that names it
+- `lb-nav-link` pushes state and swaps the host, `popstate` reverses it, and
+  an ordinary anchor is left alone
+- `hidden` comes off the body once a page has landed, including the page
+  that failed to load
 
 Widgets are small and their logic is local, so jsdom carries them: a value
 reaches the control the widget owns, a change dispatches the declared action,
@@ -183,19 +216,16 @@ painting, or navigation.
 
 ## Not built: the browser tier
 
-The hub is where jsdom stops being evidence. Fetch, `history.pushState`,
-`popstate`, and the claim that insertion and hydration in one synchronous
-block never paint an empty frame are all statements about a browser.
+Tier 4 stops at the document. A real network and a real frame are statements
+about a browser, and stubbing either of them proves nothing about it.
 
 No browser test runner is installed and none of the following exists. They
 are recorded here as the shape of the work, not as coverage:
 
 1. a cold load fills `<main>` with no empty flash
-2. `lb-nav-link` pushes state, swaps the host and lands data; `popstate`
-   reverses it; an ordinary anchor is not hijacked
-3. a native action button produces the same event a widget produces
-4. the wizard never displays a step the server has not confirmed
-5. the view-source invariant
+2. the ten-second deadline aborts a request that never answers
+3. the wizard never displays a step the server has not confirmed
+4. the view-source invariant
 
 The last is the one worth a browser. Loadbare's central claim is that no
 markup exists in the DOM that is not in view-source, and that the difference

package/docs/theory.md

@@ -138,7 +138,7 @@ returns data objects.  The HTML contains attributes identifying how
 elements are bound to data, so the framework can update them.
 
 This should be self-evidently efficacious for scalar cells and
-tuples.  Something like `<span lb-query="siteStats" lb-cell="visitCount"></span>`
+rows.  Something like `<span lb-row="siteStats" lb-cell="visitCount"></span>`
 or the same type of addressing for an input makes it trivial to 
 both hyrdrate and refresh forms, and to gather a form's values
 to send to the server.
@@ -325,7 +325,7 @@ Javascript seems cool if you need a fully mutatable DOM, but when you realize
 you don't need that, it's back to plain old reliable HTML.
 
 Another big win is the server code for pages.  The clean organization
-of hooks, actions, CRUD and queries without boilerplate is pure
+of requests, actions, CRUD and queries without boilerplate is pure
 Essential Complexity.  The automatic building of the API and 4 lines to
 handle it in Express is lower than I have seen in any other tool.
 
@@ -344,4 +344,117 @@ I wrote Loadbare originally in 2003, as "Andromeda", before Node existed
 and even 4 years before we had JQuery.  Andromeda was not nearly as
 optimized as Loadbare is now, but the principles were the same then as 
 they are now.  It has always worked for me, and I hope that it will work
-for you.
+for you.
+
+## A Consistency Model
+
+> **LLM-authored, not yet revised by a person.**  Drafted by Claude on
+> 2026-09-13, from a design session against `@loadbare/app` 0.6.0.  Treat
+> it as a proposal for this essay, not as the author's statement.
+
+### From a subjective claim to a checkable one
+
+Whether Loadbare carries less accidental complexity than another tool will
+always be disputable.  A developer fluent in React has muscle memory for its
+rules and will see Loadbare's rules as foreign, and foreign work feels
+accidental.  That objection is about familiarity, and familiarity is a cost
+paid once, in the same way this essay treats the Express boilerplate.
+
+A stronger claim can be checked, and a single counterexample in markup
+would refute it.  The model for applying data to HTML is:
+
+1. **Internally consistent.**  A few rules, each applied the same way
+   everywhere, with no exceptions.
+2. **Consistent with HTML.**  Each rule has a counterpart in how HTML
+   already behaves, and none contradicts it.
+3. **Consistent with relational data.**  What the server sends is the shape
+   a SQL query already returns, so nothing is translated on the way.
+
+### Where the vocabulary comes from
+
+This essay says the vocabulary is small because the operations a database
+affords are small and coherent.  A sharper statement is that the vocabulary
+sits where two systems that are already coherent meet: the relational model
+and HTML's containment model.  Each attribute is a relational idea placed on
+an element.
+
+| Loadbare                                 | Relational                                   | HTML precedent                                               |
+| ---------------------------------------- | -------------------------------------------- | ------------------------------------------------------------ |
+| `lb-list`                                | a relation, a set of rows                    | `<select>`, `<ul>`: a container whose contents are its items |
+| `lb-row`                                 | a single row                                 | `<form>`: one record of fields                               |
+| `lb-cell`                                | a column                                     | `name` on a control: which field this is                     |
+| `lb-key`, `lb-key-value`                 | the primary key                              | `value` on `<option>`: identity apart from the label         |
+| `lb-action`                              | a closed set of writes, and named procedures | `action` on `<form>`: where a submission goes                |
+| scope from ancestors                     |                                              | form ownership, `lang`, `<fieldset disabled>`                |
+| a nested scope begins a new one          |                                              | a nested element owns its own contents                       |
+| `lb-row-count`, `lb-pending`, `lb-error` |                                              | state attributes such as `open` on `<details>`               |
+
+### The rules
+
+1. **An element's own attributes describe what it displays.  Its ancestors
+   describe where it belongs.**  A picker carrying `lb-list` displays that
+   list, and its choice is addressed to the row it sits in, the way a
+   `<select>` displays its options and submits to the form around it.
+2. **A name answers with one shape, a row or a set of rows, and a cell holds
+   one value.**  Master-detail is a row and a list under two names.  Many
+   masters with their details is one list of joined rows, grouped for
+   display.
+3. **A value lands where the element shows its state, and a form gathers
+   from the same places.**  A widget receives `lb-value`, a form control its
+   `value`, and any other element its text.
+4. **A request is an action and a position.**  The hub supplies the position
+   from the document.  Only an interaction supplies a value.
+5. **The hub owns position and reconciliation.  A widget owns interaction and
+   placement.**
+
+### Evidence
+
+The following decisions each removed an exception or a conflict, and none
+added an attribute.  Over the same span the model gained pickers inside rows,
+native selects that show their own state, and nested lists that do not
+destroy each other.
+
+| Decision                                                      | Removed                                                                              |
+| ------------------------------------------------------------- | ------------------------------------------------------------------------------------ |
+| The hub scopes every request                                  | Native requests were scoped and widget requests were not                             |
+| Scope comes from ancestors, never the element's own `lb-list` | `lb-list` meant "display" in one place and "address" in another                      |
+| A form control receives its value as `value`                  | A `<select>` was treated as text, against HTML, and landing did not mirror gathering |
+| Row and template lookups stop at a nested scope               | Cells respected nesting while rows and templates did not                             |
+| Master-detail is a row and a list                             | An open question born of document-shaped data                                        |
+| `lb-value` on every cell                                      | Only a widget's landed value was visible to a stylesheet                             |
+
+Two signs suggest these are rules rather than patches.  Fixing where a
+request's scope comes from also fixed an unrelated console error about insert
+forms, which was never worked on directly.  Making rows respect nested scopes
+needed no change to the reference, which already described that behavior.
+
+### Where the claim is not yet proven
+
+- **Parameters and view state.**  A query takes no argument from the
+  browser, so there is nowhere to put which record is selected, a filter, a
+  sort, or a collapsed section.  The model is incomplete here rather than
+  inconsistent.  If the answer is HTML's own, the URL, in the way
+  `<form method="get">` puts its fields in the query string, the claim grows
+  stronger.  If it needs a state mechanism with no HTML precedent, that will
+  be the model's first real exception.
+- **Checkboxes and radio buttons.**  HTML's boolean convention is presence or
+  absence, as with `checked`, `hidden` and `disabled`.  A rule following it
+  would avoid inventing truthiness, though it still touches data types.
+- **Data types.**  HTML attributes are strings, so comparing values as strings
+  in a stylesheet is consistent with HTML.  What is not yet reconciled is
+  that a database's typed values arrive untyped.
+- **A nested list shows the same rows in every outer row.**  That follows
+  from the second rule: one name is one relation.  Only a new outer row
+  starting with an empty nested list is a mechanical gap.
+
+### A test for every change
+
+Before a change is made, ask:
+
+- Does it remove an exception, or add one?
+- Does it have an HTML precedent?
+- Does it have a relational counterpart?
+
+Stamping every column of a row onto the row element as `data-*` fails the
+first two: attributes nobody wrote, with no precedent in HTML.  Writing
+`lb-value` on every cell passes all three.

package/docs/tutorials/010-pages-and-navigation.md

@@ -56,7 +56,7 @@ display something to the user if they type a URL that has no matching page.
         <a href="/about" lb-nav-link>About</a>
       </nav>
       <main></main>
-      <dialog lb-unknown-page lb-query="lb-navigation">
+      <dialog lb-unknown-page lb-row="lb-navigation">
         The URL <span lb-cell="page-uri"></span> is not in this app.
       </dialog>
     </lb-hub>
@@ -75,7 +75,7 @@ link.
 
 If a `<dialog lb-unknown-page>` element is present in the HTML, it will be
 displayed to the user when a URL is entered that has no matching page in the app.
-The `lb-query` and `lb-cell` attributes will be explained when we get to data
+The `lb-row` and `lb-cell` attributes will be explained when we get to data
 binding; for now, know that `lb-navigation` is a query the hub itself answers
 on every navigation, and `page-uri` is the path that was asked for.  The
 widget library ships this dialog ready-made as `<lb-unknown-page>`, which
@@ -112,12 +112,12 @@ catch-all answers that request too.
 
 ## If you look at the console
 
-On every navigation, the hub also asks the server for that page's data, at
-`/lb/data?page=<name>`.  Neither of these pages is serving any data, and our
-Express server has no route handler for /lb/*, so the catch-all route is currently
-returning the same `app.html` for data requests as it does for the inital 
-app load.  This is expected in this early stage of the tutorial, we will fix
-it when we get to data binding and handling.
+On every navigation, the hub also asks the server for that page's data.  It
+posts that request, so it never collides with the routes above.  Neither of
+these pages is serving any data, and our Express server has no route handler
+for the hub yet, so those posts currently go unanswered.  This is expected in
+this early stage of the tutorial, we will fix it when we get to data binding
+and handling.
 
 ## Run it
 

package/docs/tutorials/040-displaying-data.md

@@ -20,7 +20,7 @@ the cell `count`.
 <h1>About</h1>
 <p class="about-note">This is the about page.</p>
 
-<div lb-query="visits">
+<div lb-row="visits">
   <p>This page has been visited <span lb-cell="count"></span> times.</p>
 </div>
 ```
@@ -45,14 +45,14 @@ When the user navigates to a page, the loadbare hub `<lb-hub>` swaps
 the contents of `<main>` and sends a request to the server for the
 query results defined for that page.  
 
-For a visit counter, we need to write a `beforeGet` hook to fire first
+For a visit counter, we need to write a `onPageEnter` hook to fire first
 and increment the counter:
 
 
 ```ts
-// src/pages/about.hooks.ts
-export const hooks = {
-  beforeGet: (ctx) => ctx.db.recordVisit(),
+// src/pages/about.requests.ts
+export const requests = {
+  onPageEnter: (ctx) => ctx.db.recordVisit(),
 };
 ```
 
@@ -103,7 +103,7 @@ the authenticated caller instead of the same file for everyone.
 
 ## Wiring the server
 
-The Loadbare builder compiles a list of all hooks and queries.  
+The Loadbare builder compiles a list of all requests and queries.  
 Add the four
 lines below, and our server will correctly route all data channel 
 requests to the correct page code.
@@ -121,8 +121,8 @@ const app = express();
 app.use("/client.js", express.static("dist/client.js"));
 app.use("/app.css", express.static("dist/app.css"));
 
-// New: answers GET /lb/data?page=<name> and POST /lb?page=<name>.
-// Must come before the catch-all, or the catch-all answers these too.
+// New: answers the hub's own route, which is the one the browser posts to.
+// Must come before the catch-all, or the catch-all answers it too.
 function contextFor(_req) {
   return { db: openDb() };
 }
@@ -160,7 +160,7 @@ to About.
 View source on either page: the host HTML is exactly what's on disk. Only
 the `<span>`'s text changes, never the markup around it.
 
-This tutorial only used `lb-query` and `lb-cell` to display one value.
+This tutorial only used `lb-row` and `lb-cell` to display one value.
 The full attribute vocabulary — actions, CRUD operations, lists, and
 navigation — is in [Data Binding](../reference/data-binding.md).