@loadbare/app 0.9.0 → 0.11.0

package/skills/loadbare-app/references/widgets.md

@@ -1,13 +1,12 @@
 # The Basic Widget Library
 
-Seven widgets: `lb-input`, `lb-select`, `lb-list`, `lb-options`, `lb-table`,
-`lb-picker`, `lb-unknown-page`. Every one of them is written against the same two contracts
-documented elsewhere — [Custom Elements](./custom-elements.md#html) for its
-definition, [Custom Elements](./custom-elements.md#code) for its class —
-nothing here is special-cased machinery.
+Six widgets: `lb-input`, `lb-select`, `lb-options`, `lb-picker`, `lb-table`,
+`lb-unknown-page`. Every one of them is an ordinary custom element, written
+against the contracts in [Custom Elements](./custom-elements.md#html) for its
+definition and [Custom Elements](./custom-elements.md#code) for its class.
 
 They ship compiled, in `@loadbare/widgets`, a package the builder resolves the
-way it resolves anyone else's — it declares `"loadbare": { "widgets": "./dist" }`
+way it resolves any other: it declares `"loadbare": { "widgets": "./dist" }`
 and the builder scans that. Install it and list it:
 
 ```
@@ -23,140 +22,133 @@ See [Widgets from packages](./builder.md#widgets-from-packages) for what
 listing a package does, and [The Builder](./builder.md#where-the-builder-looks)
 for where a listed package sits in the cascade.
 
+`lb-input`, `lb-select`, `lb-options` and `lb-picker` are controls:
+form-associated custom elements with a `value` property that fire `change`.
+Each carries `lb-column` and `lb-request` itself, the way an `<input>` does;
+see [Being a control](./custom-elements.md#being-a-control).
+
 ## `lb-input`
 
-Wraps an `<input>`. `lb-value` sets the input's `.value`. The widget sends
-nothing on its own: `lb-action` names what the input's `change` sends. The
-reserved `lb-row-update` saves the input's own cell; any other name sends that
-action. Either carries the input's value, and the hub adds the scope the
-input sits in.
+Wraps an `<input>`. The hub sets its `value` from the column `lb-column`
+names, and `lb-request` names what the widget sends on `change`:
 
-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.
+```html
+<lb-input lb-column="name" lb-request="lb-row-update" exp-label="Name"></lb-input>
+```
 
-| Parameter | Fills |
-| ---------- | ----- |
-| `exp-label` | the visible `<label>` text |
-| `exp-readonly` | the input's `readonly` attribute |
+Inside a form, leave `lb-request` off. The form gathers the widget on submit
+like any other control, so a widget that also sent its own request would
+write the same edit twice.
 
-| Attribute | Asks for |
-| ---------- | ----- |
-| `lb-action` | what to send on `change`; `lb-row-update` to save the cell's own edit |
+| Parameter      | Fills                            |
+|----------------|----------------------------------|
+| `exp-label`    | The visible `<label>` text       |
+| `exp-readonly` | The input's `readonly` attribute |
 
 ## `lb-select`
 
-Wraps a `<select>` whose `<option>`s the author writes directly inside (via
-`lb-slot`). `lb-value` sets the select's `.value`; a `change` sends the
-action named by `lb-action`, with the select's `.value` as the request's
-`value` — the choice is the interaction, so this is the case where an
-action carries a value.
+Wraps a `<select>` whose `<option>`s the page writes inside the tag:
 
-| Parameter | Fills |
-| ---------- | ----- |
-| `exp-label` | the visible `<label>` text |
+```html
+<lb-select lb-column="team" lb-request="lb-row-update" exp-label="Team">
+  <option value="">No team</option>
+  <option value="Engines">Engines</option>
+</lb-select>
+```
 
-Requires `lb-action` or `lb-query-parm` — a change with neither logs and
-sends nothing. With `lb-query-parm` the hub writes the choice into the URL.
+| Parameter   | Fills                      |
+|-------------|----------------------------|
+| `exp-label` | The visible `<label>` text |
 
 ## `lb-options`
 
-A `<select>` whose `<option>`s come from a query instead of being written by
-hand. The author supplies the row template inside the widget (via
-`lb-slot`), same as any list widget:
+A `<select>` whose `<option>`s are the rows of the query it names. The page
+writes the row template inside the widget:
 
 ```html
-<lb-options lb-list="statuses" exp-label="Status" lb-action="setStatus">
-  <template lb-key="id" data-group="category">
-    <option lb-cell="label"></option>
+<lb-options lb-query="statuses" lb-column="status" lb-request="lb-row-update" exp-label="Status">
+  <template data-group="category">
+    <option lb-column="label"></option>
   </template>
 </lb-options>
 ```
 
-| Parameter | Fills |
-| ---------- | ----- |
-| `exp-label` | the visible `<label>` text |
+| Parameter   | Fills                      |
+|-------------|----------------------------|
+| `exp-label` | The visible `<label>` text |
 
-- 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`.
+- Each option's `value` is its row's key, the `lb-key-value` the hub stamps
+  on the live row, so the widget holds a key and shows a label.
 - `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-value` selects the option with that key, including one that arrives
-  after the value did.
-- A `change` sends the action named by `lb-action`, value from the
-  select's `.value`. With `lb-query-parm` instead, the hub writes the
-  choice into the URL.
+  one per distinct value of that column, added and removed as rows arrive
+  and leave.
+- Its `value` selects the option with that key, including an option that
+  arrives after the value did.
+
+`lb-picker` is the same class with the row template supplied by its
+definition.
+
+## `lb-picker`
+
+`lb-options`, with the row template built in, for a list where every row is
+one option showing one column:
+
+```html
+<lb-picker
+  lb-query="statuses"
+  lb-column="status"
+  lb-request="lb-row-update"
+  exp-label="Status"
+  exp-column="label"
+  exp-group="category"
+></lb-picker>
+```
 
-`lb-picker` is this same class with its row template supplied by the
-definition instead of the page — see below.
+| Parameter    | Fills                                   |
+|--------------|-----------------------------------------|
+| `exp-label`  | The visible `<label>` text              |
+| `exp-column` | The column each option shows            |
+| `exp-group`  | The row template's `data-group`         |
+
+An option built from two columns, or a row with a second element, is
+`lb-options` with the page's own row template.
 
 ## `lb-table`
 
-A `<table>` that supplies its own scaffolding; the author supplies the
-heading row, the row template, and optionally a footer, each as a
-`<template>` matched to a destination:
+A `<table>` that supplies its own scaffolding. The page supplies the heading
+row, the row template, and optionally a footer, each as a `<template>`:
 
 ```html
-<lb-table lb-list="ledger" exp-caption="Ledger">
-  <template lb-template="head">
+<lb-table lb-query="ledger" exp-caption="Ledger">
+  <template lb-exp-template="head">
     <tr><th>Date</th><th>Amount</th></tr>
   </template>
-  <template lb-key="id" data-sort="date" data-group="month">
-    <tr><td lb-cell="date"></td><td lb-cell="amount"></td></tr>
+  <template data-sort="date" data-group="month">
+    <tr><td lb-column="date"></td><td lb-column="amount"></td></tr>
   </template>
-  <template lb-template="foot">
-    <tr lb-row="ledger-total"><td>Total</td><td lb-cell="total"></td></tr>
+  <template lb-exp-template="foot">
+    <tr lb-query="ledger-total"><td>Total</td><td lb-column="total"></td></tr>
   </template>
 </lb-table>
 ```
 
-| Parameter | Fills |
-| ---------- | ----- |
-| `exp-caption` | the `<caption>` text |
-
-| Destination | Fills |
-| ------------ | ----- |
-| `head` (`lb-template="head"`) | the `<thead>` content |
-| `foot` (`lb-template="foot"`) | the `<tfoot>` content |
-| slot (no `lb-template`) | the row template, via `lb-slot` on `<tbody>` |
-
-- `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. `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 `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`
-
-`lb-options`, with the row template supplied by the definition instead of
-the page — for when every row is one option and nothing else varies:
-
-```html
-<lb-picker
-  lb-list="statuses"
-  exp-label="Status"
-  exp-key="id"
-  exp-cell="label"
-  exp-group="category"
-  lb-action="setStatus"
-></lb-picker>
-```
+| Parameter     | Fills                |
+|---------------|----------------------|
+| `exp-caption` | The `<caption>` text |
 
-| Parameter | Fills |
-| ---------- | ----- |
-| `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 `data-group` |
+| Template                          | Fills                                   |
+|-----------------------------------|-----------------------------------------|
+| `<template lb-exp-template="head">` | The `<thead>`                         |
+| `<template lb-exp-template="foot">` | The `<tfoot>`                         |
+| Any other `<template>`            | The row template, in the `<tbody>`      |
 
-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
-row, or an option built from two columns, writes `lb-options` and its own
-`<template>` instead.
+- `data-group` on the row template sections rows under a heading row, one
+  per distinct value of that column, spanning every column of the row.
+- `data-sort` orders rows within a section, or within the whole body with no
+  grouping, by the text of that column.
+- The footer is not a row of `ledger`. Its `<tr>` names a `row` query of its
+  own, which lands on the `<tr>` itself. A grand total is a second query over
+  the same data.
 
 ## `lb-unknown-page`
 
@@ -170,9 +162,11 @@ The chrome's dialog for a URL that names no page, as one tag:
 </lb-hub>
 ```
 
-It expands to a `<dialog lb-unknown-page>` scoped to the hub's own
-`lb-navigation` query, so `page-label` and `page-uri` land in it the way any
-cell lands anywhere, and the hub opens it on a miss. It takes no parameters
-and, so far, shows both cells rather than choosing between them. See
-[`chrome.html`](./chrome.md#where-the-page-is) for the query, and for the same
-dialog written by hand.
+It expands to a `<dialog lb-url-unknown lb-query="lb-url">` showing
+`lb-path`, and the hub opens it when no page's stub matches the path. See
+[An unknown page](./chrome.md#an-unknown-page) for the same dialog written
+by hand.
+
+| Parameter         | Fills                                    |
+|-------------------|------------------------------------------|
+| `exp-button-text` | The text of the button that closes it, `OK` by default |

package/docs/analysis-accidental-complexity.md

@@ -1,149 +0,0 @@
-# Assessing the accidental complexity claim
-
-[Theory](./theory.md) claims that Loadbare/app carries less accidental
-complexity than React, Angular, or the hypermedia libraries.  This document
-tests that claim against [TECHREF-1.0](./TECHREF-1.0.md), which is the
-authoritative statement of what 1.0 means.
-
-Written 2026-09-07, against `@loadbare/app` 0.6.0.
-
-Brooks separates the difficulty of the user's problem from the work the tool
-demands.  The second kind is accidental, and the test applied here is whether
-Loadbare removes such work or relocates it somewhere the author still pays
-for it.
-
-## Where the claim holds
-
-The whole owned surface fits in the technical reference's cross-reference
-section.
-
-| Owned            | Count |
-|------------------|-------|
-| `lb-*` attributes | 15   |
-| `lb*` methods     | 3    |
-| Builder flags     | 4    |
-| Reserved filenames| 8    |
-| Reserved tags     | 1    |
-| Reserved events   | 1    |
-
-React reaches that size before an application adds a router, a data layer, or
-a bundler configuration, and each of those carries a surface of its own.
-Loadbare/app asks for no configuration file today.
-
-The server half is the strongest part of the argument.  A page is markup, a
-queries file, and a requests file.  The application designs no endpoints,
-writes no route table, and picks no serialization contract.  Four lines of
-Express carry the data channel.  Neither the fat frameworks nor the
-hypermedia libraries remove that category of work; htmx in particular leaves
-the developer designing every endpoint and every fragment it answers with.
-
-Building the HTML once removes reconciliation, keys, memoization, and effect
-dependencies together.  That is the largest single deletion in the design,
-and it is the one the hypermedia libraries do not make either, since they
-ship markup at run time and carry swap semantics to place it.
-
-## What the technical reference already knows
-
-Most of what an assessment finds is already on the blocker list.  Each
-concern below adds weight to an open item rather than naming a new one.
-
-| Concern                                    | Blocker                                    |
-|--------------------------------------------|--------------------------------------------|
-| Values carry no type, so every application formats its own dates and money | Data types |
-| No page is reachable by row                | Take a position on the URL space           |
-| A widget receives one cell at a time       | Whether a widget may receive a whole row   |
-| A widget repeats hub code to fire a request| Give a widget a way to fire its own request|
-| Master-detail is unspecified               | Decide what a nested list means            |
-| Every page redeclares the chrome's queries | Give the chrome a way to state its own queries |
-
-The technical reference's own sample query calls `String()` on a count by
-hand, which is the data-type blocker showing up in the documentation.
-
-Two [roadmap](./roadmap.md) items carry the same weight as these and appear
-in the first real application.  Concurrent writers on one list have no
-version or conflict story.  Per-keystroke validation has no home, and the
-roadmap expects it to sit in the widget while the server stays authoritative
-for the same field.
-
-Five sections of the technical reference are still marked `UNEDITED`:
-Binding, Requests, Links, Widgets, and Widget authoring.  Those are the
-mechanisms an author touches on every page.
-
-## Positions that carry a cost
-
-Two constraints appear in the body of the technical reference as current
-behavior rather than on the blocker list, so the project has taken a position
-on each.  Naming the cost is still fair.
-
-The hub reaches its endpoint by absolute path, so an application cannot be
-hosted under a subpath such as `example.com/myapp/`.  A deployment that wants
-several applications behind one host gives each one an origin.
-
-Every route answers 200 with the same document, so the browser detects an
-unknown page after the fact and the chrome's `lb-unknown-page` dialog reports
-it.  A crawler or a monitor that reads status codes sees a healthy response
-for a path the application does not have.
-
-## The gap recorded nowhere
-
-Loadbare/app offers no way to display or style an element according to the
-value that landed in it.
-
-A cell lands on a custom element as the `lb-value` attribute, which a
-stylesheet can select.  A cell lands on a native element as its
-`textContent`, which no selector reaches.  The hub stamps `lb-pending`,
-`lb-error`, and `lb-row-count`, which cover a request in flight, a request
-that failed, and an empty list.  Nothing covers a row whose `status` column
-reads `overdue`.
-
-An application that wants this writes a widget, and a widget that fires a
-request pays the cost the widget-protocol blocker already names.  So the
-missing piece pushes the author toward the mechanism that is itself
-unfinished.
-
-This appears in neither the blockers, the roadmap's open questions, nor the
-decided-against section.  It is the one finding here that the technical
-reference does not already record.
-
-## The general form of the query gap
-
-The URL-space blocker names one consequence of a broader constraint, and
-stating the constraint directly is more useful than stating the consequence.
-
-A query takes no argument from the browser.  Its signature is `(ctx) => Row`
-or `(ctx) => Row[]`, and `ctx` is what the application built from the Express
-request.  The hub's own request carries `page=<name>`.  The hub reads
-`location.pathname`, which drops the query string, so a path segment and a
-search parameter are both invisible to the server.
-
-An application that shows one selected record therefore holds the selection
-in server state.  A click fires an action, the handler records the selection
-where `ctx` reaches it, and the refreshed query reads it back.  That works
-today and needs no new mechanism.  It puts selection in the same territory as
-the roadmap's concurrent-writers question, and it means a reload or a shared
-link does not carry the record.
-
-## Comparison with the hypermedia libraries
-
-Theory rejects the existing tools for combining interpolation with
-conditional and list rendering.  The distinction is narrower than that.
-Loadbare/app interpolates at build time, with defaults and a substitution
-grammar, and renders lists at run time through `<template lb-key>`.  What the
-design rules out is conditionals and interpolation after the build.
-
-Loadbare/app also adds a builder, a filename grammar, and a slot and template
-system, where htmx asks for no build step.  Against React and Angular the
-surface comparison is decisive.  Against htmx it is close, and the server
-half is where Loadbare/app wins instead.
-
-## Verdict
-
-The claim holds on the server, and it holds on the client for everything the
-reconciliation layer used to cost.
-
-On the rest of the client it currently holds partly by not doing several
-things database applications need, and the technical reference lists most of
-them itself.  Whether the claim survives 1.0 depends on how the URL space,
-the row hook, the chrome queries, and value-driven display are answered, and
-an answer of "decided against" counts as an answer only where an application
-can still reach the behavior some other way.

package/docs/analysis-closed-set.md

@@ -1,210 +0,0 @@
-# A closed set for the Loadbare/app vocabulary
-
-> **LLM-authored, not yet revised by a person.**  Drafted by Claude on
-> 2026-09-13, from a design session against `@loadbare/app` 0.7.3 while
-> building a chart of accounts page.  Treat it as a proposal, not as the
-> author's statement.
-
-## The question
-
-Relational algebra is closed: every operation takes relations and returns a
-relation.  CRUD is closed in the same way on the write side.  Closure is what
-makes both easy to program against.  Combinations do not explode, the cases
-are finite, and nothing falls outside the model.
-
-Loadbare/app maps three data shapes (cell, row, list) and three relational
-operations (insert, update, delete) into HTML.  This document asks whether
-recent iterations have shown enough to state a **closed** vocabulary and set
-of behaviors: one where every combination of shape, operation, position,
-nesting and timing is defined, so application code never meets an edge case
-outside the model.
-
-Author note: a page can of course define invalid combinations, but their
-lack of validity must be intelligibly reported as a failure to stick to the
-closed set.
-
-"Closed" is tested four ways:
-
-1. **Shapes are closed.**  Everything a page receives is one of the shapes,
-   or a patch on a list.
-2. **Operations are closed over shapes.**  Each operation yields a defined
-   result in the same vocabulary.
-3. **Composition is closed.**  Nesting, many scopes bound to one name, scopes
-   that appear late, and several names in one response all stay inside the
-   rules.
-4. **Anything outside the spine is justified.**  It either reduces to the
-   spine or is a separate, deliberately bounded axis.
-
-## The model in one sentence
-
-> **A page holds named relations.  Every read and every write answers with
-> new values for those names.  Every scope is a view of one name.**
-
-Every rule below follows from it.
-
-## 1. Shapes: three, plus identity
-
-| Shape    | Attribute                                   | Relational                                                        |
-| -------- | ------------------------------------------- | ----------------------------------------------------------------- |
-| list     | `lb-list`                                   | a relation, as a variable that holds rows                         |
-| row      | `lb-row`                                    | a single row, read-only; a writable single row is a list of one   |
-| cell     | `lb-cell`                                   | a column value                                                    |
-| identity | `lb-key` written, `lb-key-value` stamped    | the primary key                                                   |
-
-## 2. What every answer is made of: three forms
-
-Every query, CRUD operation, declared action and refresh answers with
-`{ name: result }`, and each result is one of:
-
-- **a whole list** (an array), which replaces the relation, membership and
-  order included;
-- **a patch** (`{ rows, drop }`), which upserts rows by key and drops keys;
-- **a row** (an object), which replaces the single row.
-
-This is the closure property.  No operation answers with HTML, a redirect, or
-instructions.  Declared actions are open-ended, like stored procedures, but
-their results are still in these three forms, so the landing side stays
-closed.
-
-## 3. Operations: three, plus one open door
-
-| Operation        | Takes from position    | Carries                                      | Answers      |
-| ---------------- | -------------------    | -------------------------------------------- | ------------ |
-| `lb-row-insert`  | list                   | values, gathered from the record             | patch rows   |
-| `lb-row-update`  | list, key              | values, gathered, or one cell from a widget  | patch rows   |
-| `lb-row-delete`  | list, key              | nothing                                      | patch drop   |
-| a declared name  | list or row, key, cell | value                                        | any names    |
-
-### Done: `lb-cell-change` folded into `lb-row-update`
-
-A cell change is an update whose `values` holds one entry.  SQL has one
-UPDATE whether it sets one column or many.  On the server, `cellChange` and
-`rowUpdate` merged into `rowUpdate(key, values)`, where a column absent from
-`values` is left as it is.
-
-The fold needed one rule beyond this proposal.  Without it, a widget sending
-`lb-row-update` gathers its whole record, and every other editable cell in
-the row goes with it.  The rule: an element carrying `lb-cell` is a record
-of one cell, the way a control has a value and a form has values.  Its
-`values` holds that cell alone, from the `value` the widget sent or else its
-control, so a widget never writes its own column name into the request.
-
-### Reordering is not an operation
-
-Position is not a relational concept; order is a column.  A drag is an update
-to an ordering column such as `display_order`, which the wire already
-carries in `values`.  No move operation is needed, and no field for "where
-the row went".
-
-## 4. Position: taken from the page, never written in the request
-
-- An element's own attributes say what it displays.  Its ancestors say where
-  it belongs.
-- A nested scope begins a new scope.
-- A request is an action plus a position.  The hub supplies the position;
-  only an interaction supplies a value.
-
-These are the rules [Theory](./theory.md) already states.  They are listed
-here because closure depends on them.
-
-## 5. Landing: every combination defined
-
-| Result → target | list scope   | row scope                         | no scope yet               |
-| --------------- | ------------ | --------------------------------- | -------------------------- |
-| whole list      | reconcile    | error: one name has one shape     | stored                     |
-| patch           | upsert, drop | error                             | applied to the stored copy |
-| row             | error        | fill                              | stored                     |
-
-A result lands on every scope bound to its name, at any depth of nesting.
-0.7.3 already does this: a patch to `groups` reaches a picker in every row of
-an outer table, and the outer list's reconciliation does not mistake the
-picker's rows for its own.
-
-### The missing rule: timing
-
-In 0.7.3 a scope that appears after its name has landed stays empty.  A row
-added to an outer list by a patch starts with every nested list empty, and a
-widget's scaffolding built during landing, such as a ghost row holding a
-picker, starts empty too.  Pages work around it by ordering their queries so
-the outer list lands first, which only covers the first load.
-
-The closed rule:
-
-> **The hub holds each name's current value.  A scope shows that value
-> whenever it appears.**
-
-In relational terms a name is a relation variable, results are assignments to
-it, and scopes are views of it.  Whether a scope existed before or after its
-data arrived stops mattering.
-
-It also settles several things that were not worked on directly:
-
-- The blocker in [TECHREF-1.0](./TECHREF-1.0.md), "Decide how a new row
-  fills a nested list".
-- Pickers in newly created rows, and pickers in ghost rows built after the
-  first load.
-- Query order in a page's queries file stops mattering.
-- **What a partial patch row means.**  A patch row upserts by key, and a
-  column it does not name is left unchanged, as an SQL UPDATE leaves it.
-  The reference is silent on this today.
-- "No scope for a name" becomes an ordinary state rather than a console
-  warning, since a scope may simply not exist yet.
-
-#### Mechanism
-
-- The hub fills a cloned row, nested scopes included, before inserting it.
-  This extends the rule it already follows of filling before insertion.
-- After each landing, it sweeps for scopes that have never received data.
-  For a list, an absent `lb-row-count` already marks one.  A row scope would
-  need an equivalent mark.
-- A widget that builds scopes outside a landing, at some later time, would
-  need a `MutationObserver`.  No widget built so far does that.
-
-#### What would prove it wrong
-
-A case where the stored copy and the document legitimately disagree.  The
-only candidate is a control holding an edit not yet sent, and landing already
-overwrites that in 0.7.3, so the rule introduces nothing new.
-
-## 6. State attributes: four, stamped by the hub, read by CSS
-
-`lb-value`, `lb-row-count`, `lb-pending`, `lb-error`.
-
-## 7. Outside the algebra, deliberately bounded
-
-- **Composition at build time:** `lb-slot`, `lb-template`.
-- **The host channel:** `lb-page`, `lb-nav-link`, `lb-unknown-page`, and the
-  hub's own `lb-navigation` row.  That row already shows the hub's own state
-  landing through the same three forms.
-- **The widget protocol:** the `lb-request` event, which an ancestor may
-  stop, and the `lbPlaceRow` and `lbRowsLanded` hooks.
-
-## What this changes in 0.7.3
-
-1. The hub holds each name's current value and fills scopes that appear
-   late.
-2. `lb-cell-change` folds into `lb-row-update`, with an element carrying
-   `lb-cell` sending itself alone, and the server's `cellChange` and
-   `rowUpdate` merge.  Done.
-3. The reference states the patch row rule: upsert by key, unnamed columns
-   unchanged.
-
-Everything else is the current vocabulary, now justified as closed.
-
-## What the evidence has not settled
-
-Everything above is backed by pages already built.  These are not:
-
-1. **Parameters and view state:** a filter, a selection, a collapsed
-   section.  The likely closed answer is that URL query parameters become
-   columns of the `lb-navigation` row and reach queries as arguments, as
-   `<form method="get">` puts its fields in the query string.  No page needs
-   it yet, so this is a prediction rather than evidence.
-2. **Checkboxes and data types:** probably HTML's presence-or-absence
-   convention, still undecided.
-3. **Concurrent writers:** staleness is a property of the stored copy, so
-   the rule in section 5 makes this question easier to state without
-   answering it.
-4. **Error content:** `lb-error` records that a round trip failed, not why.
-   A closed answer would deliver the message as a result like any other,
-   perhaps as a hub row.  Untested.