@loadbare/app 0.7.3 → 0.8.0

package/docs/prior-art.md

@@ -0,0 +1,216 @@
+# Prior art
+
+> **LLM-researched, not yet revised by a person.**  Compiled by Claude on
+> 2026-09-16 from web sources, against `@loadbare/app` 0.7.3, while designing
+> conditional rendering.  The sources are listed under each section.
+
+Loadbare binds HTML to data by attributes and lets the platform do the DOM
+work.  That idea has been tried before.  This document records the two
+closest predecessors, where Loadbare agrees with them and where it parts
+ways, and what other frameworks do about conditional rendering.
+
+## The short version
+
+Loadbare is not Model-Driven Views, although MDV is the better-known name.
+MDV's model is a mutable object graph in the browser that the view observes.
+Loadbare has no model in the browser: the view is driven by server responses
+that say what changed.
+
+The closer ancestor is Internet Explorer 4's data binding, from 1997, whose
+vocabulary of record sets, single records and columns maps almost one to one
+onto Loadbare's.
+
+Loadbare can be described as IE4's relational binding vocabulary, on the
+`<template>` element that MDV left behind, with the server as the model.
+Andromeda (2003), where Loadbare began, sits between the two.
+
+## Internet Explorer 4 data binding (1997)
+
+Internet Explorer 4.0 bound HTML to data through attributes, built from four
+parts: a data source object (DSO), data consumers, a binding agent and a
+table repetition agent.  A DSO might take "an Open Database Connectivity
+(ODBC) connection string and an Structured Query Language (SQL) statement,"
+and had to expose its data through OLE DB.
+
+| IE4                                                                         | Loadbare              |
+|-----------------------------------------------------------------------------|-----------------------|
+| `DATASRC` on a table repeats "an entire set of records" ("set binding")     | `lb-list`             |
+| A single-valued consumer takes one value "from the current record"          | `lb-row`              |
+| `DATAFLD` names "a column in the data set"                                  | `lb-cell`             |
+| The repetition agent "uses the table row (tr) in the table body as a template" | `<template lb-key>` |
+| The DSO's SQL statement                                                     | a page's queries      |
+| The binding agent "work[s] completely behind the scenes"                    | the hub               |
+
+It differed from Loadbare in three ways:
+
+- **The data lived in the browser.**  "Since the DSO maintains the data on the
+  client, it also manages how the data is sorted and filtered."
+- **Binding was two-way.**  "When a user updates a databound element on the
+  page, the binding agent notifies the DSO."  Loadbare sends a request and
+  lands the answer.
+- **It was proprietary.**  A DSO was an ActiveX control or applet, and the
+  feature ended with Internet Explorer.
+
+Sources:
+[About Data Binding Architecture](https://learn.microsoft.com/en-us/previous-versions/windows/internet-explorer/ie-developer/platform-apis/ms531384(v=vs.85)),
+[Using the Tabular Data Control](https://www.sitepoint.com/control-internet-explorer/).
+
+## Model-Driven Views (2011–2015)
+
+### What it was
+
+Rafael Weinstein proposed MDV to the W3C WebApps group in April 2011:
+"Myself and a few other chromium folks have been working on a design for a
+formalized separation between View and Model in the browser."  Its README
+calls it "a way to write _dynamic_ HTML _using_ HTML," with the goal of native
+implementation in browsers.
+
+- `{{path.to.value}}` placeholders in text and attribute values, with a
+  custom syntax API for expressions.
+- `<template bind>` for one instance, `<template repeat>` for one instance
+  per array item, `<template if>` to make either conditional, and
+  `<template ref>` to reuse another template's content.
+- Two-way binding on inputs: "If DOM elements which collect user input are
+  bound, they _push_ the collected value into the model."
+- A conditional attribute, `hidden?`: "the attribute will be set to the empty
+  string if the value is reachable and truthy, otherwise the attribute will be
+  removed."
+- Models are plain JavaScript objects, observed through `Object.observe`.
+
+In the TemplateBinding implementation, a template stays in the document and
+its instances are inserted after it, tracked by a terminator node.  When `if`
+turns false, instances are removed and their bindings closed.
+
+### What became of it
+
+The W3C group asked for MDV to be broken into primitives.  In Weinstein's
+account those became DOM Mutation Observers, **the HTML `<template>`
+element**, and `Object.observe`.  `<template>` was specified by Weinstein and
+reported stable in May 2013.  No source found states outright that
+`<template>` was created for MDV, but they share an author, a period and a
+design.
+
+The rest did not survive:
+
+- `Object.observe` was withdrawn from TC39 in November 2015.  It disabled
+  optimization paths in V8, and Polymer found that complex applications made
+  "tens of thousands of O.o calls."
+- Without native observation, MDV had to keep a list of bindings, and a node
+  discarded without being unbound was never garbage collected.
+- The Polymer community debated whether the model or the markup should be the
+  source of truth, and settled on the model.
+- The binding half continues in Apple's Template Instantiation proposal (2017)
+  and Chrome's DOM Parts, which as of 2025 was pending, with no signals from
+  Gecko or WebKit.
+
+Sources:
+[Weinstein, "Model-driven Views"](https://lists.w3.org/Archives/Public/public-webapps/2011AprJun/0309.html),
+[MDV README](https://github.com/toolkitchen/mdv),
+[MDV template.md](https://raw.githubusercontent.com/toolkitchen/mdv/master/docs/template.md),
+[MDV node_bind.md](https://raw.githubusercontent.com/toolkitchen/mdv/master/docs/node_bind.md),
+[TemplateBinding source](https://raw.githubusercontent.com/googlearchive/TemplateBinding/master/src/TemplateBinding.js),
+[Will MDV become a standard?](https://groups.google.com/g/polymer-dev/c/4RSYaKmbtEk/m/uYnY3900wpIJ),
+[MDV or markup as data](https://groups.google.com/g/polymer-dev/c/FJQLrcSKGT0),
+[Polymer issue #154](https://github.com/Polymer/polymer/issues/154),
+[W3C HTML Templates, 2013](https://www.w3.org/TR/2013/WD-html-templates-20130214/),
+[InfoQ: Object.observe withdrawn](https://www.infoq.com/news/2015/11/object-observe-withdrawn/),
+[esdiscuss: An update on Object.observe](https://esdiscuss.org/topic/an-update-on-object-observe),
+[Template Instantiation](https://github.com/WICG/webcomponents/blob/gh-pages/proposals/Template-Instantiation.md),
+[DOM Parts](https://github.com/WICG/webcomponents/blob/gh-pages/proposals/DOM-Parts.md),
+[Intent to Prototype: DOM Parts](https://groups.google.com/a/chromium.org/g/blink-dev/c/wIADRnljZDA).
+
+## Where the three overlap
+
+**All three:**
+
+- Dynamic HTML declared in HTML.
+- Attributes naming data on ordinary elements.
+- The platform, not the application, performs the DOM work, with no virtual
+  DOM.
+
+**Loadbare and MDV:**
+
+- `<template>` as the unit of repetition and of conditions.
+- Built toward web standards, not a proprietary runtime.
+
+**Loadbare and IE4:**
+
+- A relational vocabulary: a record set, a single record, a column per
+  element.
+- The row as the repetition template.
+- SQL behind the data source.
+
+**MDV and IE4, and not Loadbare:**
+
+- The data lives in the browser.
+- Two-way binding.
+- The view keeps itself synchronized with changes to that data.
+
+**MDV only:**
+
+- Runtime `{{}}` placeholders and expressions.
+- Paths into nested object trees.
+- Change observation, and bindings that have to be closed.
+- A false `if` destroys its instances.
+
+**Loadbare only:**
+
+- The server is the source of truth, and the hub holds no data.
+- A response says what changed, as a whole list, a patch or a row, so nothing
+  is observed.
+- Writes are requests (`lb-action` and the CRUD operations) whose answers land
+  back.
+- A request's position is read from the document.
+- A build step: expansion, tree shaking, pages shipped as templates.
+- Navigation and request state carried by the hub.
+
+Two of Loadbare's central decisions reject what ended MDV.  There is no
+client-side model to observe, which is what made `Object.observe` too slow in
+practice.  And data comes only as rows and sets of rows, never as the nested
+object paths MDV bound to.
+
+## Conditional rendering elsewhere
+
+Frameworks handle a false branch in one of two ways.  Either it is hidden
+with CSS and keeps its state, or it is removed and rebuilt from scratch when
+it returns.  A few keep a removed branch alive in framework memory.
+
+| Framework                        | The false branch                                                                 | State kept | Updated while hidden |
+|----------------------------------|-----------------------------------------------------------------------------------|------------|----------------------|
+| MDV `<template if>`              | Instances removed after the template, bindings closed                            | no         | no                   |
+| Alpine `<template x-if>`         | Cloned from the template and inserted after it on show, destroyed and removed on hide | no     | no                   |
+| Knockout `if`                    | Comment nodes mark the place, contents re-rendered completely                     | no         | no                   |
+| Angular `*ngIf`                  | `<ng-template>` rendered as a comment anchor; a view can be detached and reinserted | if detached | no                |
+| Aurelia `if.bind`                | Removed from the DOM, views cached by default and reused                          | yes        | not documented       |
+| Vue `<KeepAlive>`                | Detached from the document but not unmounted                                      | yes        | no                   |
+| Lit `cache()`                    | DOM kept in a `DocumentFragment`, swapped back in                                 | yes        | on swap-in           |
+| Polymer `dom-if`                 | `style.display = 'none'`; `restamp` destroys and re-creates instead               | yes        | yes                  |
+| React `<Activity mode="hidden">` | `display: none`, Effects destroyed                                                | yes        | yes, at lower priority |
+
+Loadbare's `lb-show` moves the live element into a `<template>` that takes
+its place, and landing still reaches it there.  Each
+part has precedent: templates as conditions (MDV, Alpine, Angular), branches
+kept rather than rebuilt (Aurelia, Angular, Vue), and hidden branches kept
+current (Polymer, React).  No source found keeps the branch in a template in
+the document, standing where the element stood, with no framework cache.  The
+hub has nowhere else to keep one.
+
+Loadbare's recommendation before `lb-show`, a stylesheet rule on `lb-value`,
+is the same family as Polymer's `dom-if` and MDV's `hidden?`: the element stays and
+CSS hides it.
+
+Sources:
+[Alpine x-if source](https://raw.githubusercontent.com/alpinejs/alpine/main/packages/alpinejs/src/directives/x-if.js),
+[Alpine x-if](https://alpinejs.dev/directives/if),
+[Knockout virtual elements](https://knockoutjs.com/documentation/custom-bindings-for-virtual-elements.html),
+[Knockout if/with re-rendering](https://www.knockmeout.net/2012/03/knockoutjs-performance-gotcha-1ifwith.html),
+[Angular NgIf](https://angular.dev/api/common/NgIf),
+[Reusing views in Angular](https://angular.love/optimization-techniques-reusing-views/),
+[Aurelia conditional rendering](https://docs.aurelia.io/templates/conditional-rendering),
+[Vue KeepAlive](https://vuejs.org/guide/built-ins/keep-alive.html),
+[Lit directives](https://lit.dev/docs/templates/directives/),
+[Lit cache.ts](https://github.com/lit/lit/blob/lit-html-1.x/src/directives/cache.ts),
+[Polymer dom-if](https://polymer-library.polymer-project.org/2.0/docs/devguide/templates),
+[Polymer display caching](https://github.com/Polymer/polymer/commit/2611285),
+[Polymer issue #2712](https://github.com/Polymer/polymer/issues/2712),
+[React Activity](https://react.dev/reference/react/Activity).

package/docs/reference/custom-elements.md

@@ -223,13 +223,14 @@ as a string literal.
 |------------------|------------|
 | `ATTR_VALUE`     | `lb-value` |
 | `ATTR_CELL`      | `lb-cell`  |
+| `ATTR_SHOW`      | `lb-show`  |
 | `ATTR_LIST`      | `lb-list`  |
 | `ATTR_ROW`       | `lb-row`   |
 | `ATTR_KEY`       | `lb-key`   |
 | `ATTR_KEY_VALUE` | `lb-key-value` |
 | `ATTR_ACTION`    | `lb-action`|
-| `ACTION_ROW_INSERT`, `ACTION_ROW_DELETE`, `ACTION_ROW_UPDATE`, `ACTION_CELL_CHANGE` | the reserved `lb-action` values |
-| `LB_ACTIONS`     | all four of them, in one array |
+| `ACTION_ROW_INSERT`, `ACTION_ROW_DELETE`, `ACTION_ROW_UPDATE` | the reserved `lb-action` values |
+| `LB_ACTIONS`     | all three of them, in one array |
 | `LB_RESERVED_PREFIX` | `lb-`, the prefix every reserved name begins with |
 | `ATTR_ROW_COUNT` | `lb-row-count`|
 | `LB_EVENT_NAME`  | `lb-request` |
@@ -260,6 +261,15 @@ cells a successful insert resets — see
 [TECHREF-1.0](../TECHREF-1.0.md#the-round-trip). Read it as nothing landed,
 and show the widget's default. A blank string is a value that landed.
 
+A widget carrying `lb-show`, or inside an element that does, is moved into a
+template while its column is off and back out when it turns on — see
+[Conditional rendering](./data-binding.md#conditional-rendering). Going in, it
+sees `disconnectedCallback` and then `adoptedCallback`; coming out,
+`adoptedCallback` and then `connectedCallback`. It is the same instance
+throughout, and it still receives `lb-value` while it is away, so write
+`connectedCallback` to run more than once, as a row a list reorders already
+requires.
+
 List `ATTR_VALUE` in `observedAttributes`, or `attributeChangedCallback`
 never fires. The browser calls it for an attribute already present when an
 element upgrades, not only for one that changes afterward, so a widget's
@@ -277,7 +287,7 @@ control's value as its `detail`:
 import { LB_EVENT_NAME } from "@loadbare/app/constants";
 import type { HubRequest } from "@loadbare/app/types";
 
-const detail: HubRequest = { action: "lb-cell-change", value: input.value };
+const detail: HubRequest = { action: "lb-row-update", value: input.value };
 this.dispatchEvent(new CustomEvent(LB_EVENT_NAME, { bubbles: true, detail }));
 ```
 
@@ -286,9 +296,14 @@ event, and does not send a request missing a field its operation requires.
 See [TECHREF-1.0](../TECHREF-1.0.md#requests) for what each operation is
 filled with.
 
-A widget sending `lb-row-insert` or `lb-row-update` doesn't read its own
-controls. It dispatches the bare action from the row, or from anything
-inside it, and the hub gathers `values` from the row the event came from:
+A widget that carries `lb-cell` and sends `lb-row-insert` or `lb-row-update`
+sends that one cell. The hub builds `values` from the cell's name and the
+`value` the widget sent, or reads the control the widget wraps when it sent
+none.
+
+A widget that carries no `lb-cell` doesn't read its own controls. It
+dispatches the bare action from the row, or from anything inside it, and the
+hub gathers `values` from the row the event came from:
 the nearest `<form>`, `<tr>` or live row around the dispatching element,
 itself included, inside its scope. Every readable `lb-cell` in that row is
 gathered, wherever in the row it sits, except the cells of a scope nested in

package/docs/reference/data-binding.md

@@ -41,14 +41,15 @@ asks for are declared on the server; see [page files](./page-files.md).
 
 ## Binding
 
-| Attribute      | Written by  | Names                                     |
-|----------------|-------------|-------------------------------------------|
-| `lb-list`      | a developer | The set of rows a subtree displays        |
-| `lb-row`       | a developer | The one row a subtree displays            |
-| `lb-key`       | a developer | The column that identifies a row          |
-| `lb-cell`      | a developer | The column an element displays            |
-| `lb-key-value` | the hub     | A live row's own key                      |
-| `lb-value`     | the hub     | The value that landed on a cell           |
+| Attribute      | Written by  | Names                                                 |
+|----------------|-------------|-------------------------------------------------------|
+| `lb-list`      | a developer | The set of rows a subtree displays                    |
+| `lb-row`       | a developer | The one row a subtree displays                        |
+| `lb-key`       | a developer | The column that identifies a row                      |
+| `lb-cell`      | a developer | The column an element displays                        |
+| `lb-show`      | a developer | The column that decides whether an element is present |
+| `lb-key-value` | the hub     | A live row's own key                                  |
+| `lb-value`     | the hub     | The value that landed on a cell                       |
 
 A binding is scoped by ancestry. Either scope attribute scopes its DOM
 children, and a nested one of either kind begins a new scope, so an element
@@ -151,9 +152,9 @@ the prefix stripped and the rest camel-cased.
 | `lb-action="lb-row-delete"`               | `rowDelete`  | `list`, `key`                 |
 | `lb-action="lb-row-insert"` on a `<form>` | `rowInsert`  | `list`, `values`              |
 | `lb-action="lb-row-update"` on a `<form>` | `rowUpdate`  | `list`, `key`, `values`       |
-| `lb-action="lb-cell-change"` on a widget  | `cellChange` | `list`, `key`, `cell`, `value`|
+| `lb-action="lb-row-update"` on a widget cell | `rowUpdate` | `list`, `key`, `values` of one cell |
 
-All four operations are list operations. Each needs a key, and a key exists
+All three operations are list operations. Each needs a key, and a key exists
 only on a live row the hub stamped inside a list, so a single-row scope is
 read-only and a declared action is the only thing it can send. An application
 that wants a writable single row declares a list that answers with one row.
@@ -165,15 +166,11 @@ with one an application already uses. That reservation is also the whole of
 the wire discriminant: a value beginning with `lb-` is an operation, and
 anything else is a name the page declared.
 
-The hub sends the first four from a native element on the element's own
-event: a form on submit, anything else on click. An insert or update clicked
-from a button reads the form or row the button is in (see [Forms](#forms)). A
-cell change needs a
-widget to say what a change is, so only a widget sends it: the shipped
-`<lb-input>` does when it carries `lb-action="lb-cell-change"`, and stays
-quiet otherwise — an input inside an `lb-row-insert` or `lb-row-update` form is read
-again by the form on submit, so a widget that sent on its own would write
-the same edit twice.
+The hub sends a request from a native element on the element's own event: a
+form on submit, anything else on click. An insert or update clicked from a
+button reads the form or row the button is in (see [Forms](#forms)). To
+commit one cell as it changes, put `lb-row-update` on a widget cell instead
+(see [Committing one cell](#committing-one-cell)).
 
 Declare every action on the server, and permit every operation on its list. A
 name the page has not declared, and an operation a list does not permit, are
@@ -183,7 +180,7 @@ refused; see
 ### Actions
 
 Write `lb-action` on a button to ask the server to do something that is not
-one of the four CRUD operations:
+one of the three CRUD operations:
 
 ```html
 <button lb-action="mailRoster">Mail the roster</button>
@@ -279,46 +276,123 @@ refuses it. A widget may dispatch either from any element, and the hub
 gathers the same way; see
 [Sending a request](./custom-elements.md#sending-a-request).
 
+### Committing one cell
+
+Put `lb-row-update` on a widget that carries `lb-cell` to save that one cell
+whenever it changes. The shipped `<lb-input>` sends it on `change`:
+
+```html
+<template lb-key="id">
+  <tr>
+    <td><lb-input lb-cell="name" lb-action="lb-row-update"></lb-input></td>
+    <td><lb-input lb-cell="note" lb-action="lb-row-update"></lb-input></td>
+  </tr>
+</template>
+```
+
+An element carrying `lb-cell` is a record of one cell, the way a control has
+a value and a form has values. Its update carries `values` holding that cell
+alone, so an edit in one input never sends the other. It reaches the same
+`rowUpdate` a form does. SQL has one UPDATE whether it sets one column or
+many, and the application writes one handler for both.
+
+The widget decides when the cell has changed. A native `<input>` carrying
+`lb-cell` and `lb-row-update` has no such moment, since a click into it
+would send it, so the hub refuses it and says so.
+
+Leave `lb-action` off a widget inside an `lb-row-insert` or `lb-row-update`
+form. The form reads every `lb-cell` in it on submit, so a widget that also
+sent its own would write the same edit twice.
+
 ## Conditional rendering
 
 Loadbare ships static HTML and hydrates elements that are already in the
 document. There is no `if`, and none is needed: write every possibility into
-the page, and control which of them is showing.
+the page, and let a column decide which of them is present.
 
-Every cell carries the value that landed on it as `lb-value`, so a
-stylesheet can show or hide part of a page from a value the server sent. Bind
-a column the page does not display to a hidden element:
+Write `lb-show` on an element, naming the column that decides it:
 
 ```html
 <template lb-key="id">
   <tr>
     <td lb-cell="name"></td>
-    <td lb-cell="locked" hidden></td>
-    <td><button lb-action="lb-row-delete">Remove</button></td>
+    <td><button lb-action="lb-row-delete" lb-show="removable">Remove</button></td>
   </tr>
 </template>
 ```
 
-```css
-tr:has([lb-cell="locked"][lb-value="true"]) button {
-  display: none;
-}
+```sql
+(ledger_count = 0 AND system_behavior IS NULL) AS removable
 ```
 
-`lb-value` holds the string the query sent, so the query decides the spelling
-the selector matches. A stylesheet can hide a control but cannot disable one,
-and hiding is presentation: the server still refuses what a request may not
-do.
+A value of `null` or `false` takes the element out of the page, and any other
+value puts it back. The hub never reads a string, so `"false"` is a value like
+any other: have the query answer with a boolean or a null. A row that does not
+carry the column leaves the element as it is, so a query that answers with
+whole rows returns the column in every row.
 
-Where showing a case takes more than a selector, a widget receives the value
-in `lb-value` and decides what to show:
+`lb-show` binds the way `lb-cell` does, to the row on its nearest scoped
+ancestor. On an element that is itself a scope, the column belongs to the
+row around it, so this picker takes its choices from `groups` and whether it
+is present from the account row:
 
-```ts
-for (const step of steps) step.hidden = step.dataset.step !== value;
+```html
+<select lb-list="groups" lb-cell="group_id" lb-show="group_choice">
 ```
 
-Ship the case that is showing on arrival unhidden, and hide the rest in the
-HTML.
+An element may show a column and be decided by it, which shows a note only
+when there is one:
+
+```html
+<span lb-cell="note" lb-show="note"></span>
+```
+
+An element that is not present cannot be clicked, but that is presentation:
+the server still refuses what a request may not do.
+
+### Where an absent element is
+
+An element whose column is off is moved into a `<template lb-show>` that
+stands where it stood, and moved back out when the column turns on. The
+developer never writes that template.
+
+- Nothing renders it, whatever a stylesheet says, because a template's content
+  is not its children.
+- It cannot be focused or clicked, assistive technology does not announce it,
+  and a form does not gather it.
+- It is moved, never rebuilt, so a widget keeps its instance and a control
+  keeps what was typed into it.
+- Values keep landing on it, and on every cell and scope inside it, while it
+  is away, so it returns current.
+
+The builder ships every `lb-show` element already inside its template, so
+nothing conditional shows until its row has landed.
+
+A condition never changes the structure of a page. An absent element keeps
+its place among its siblings, so a position selector (`:first-child`,
+`:nth-child`, `:empty`, `+`, `~`) counts its template as a sibling. A selector
+by tag, class or attribute is unaffected. Only a list changes a page's
+structure.
+
+A condition that is only a style is a class on an element that is present or
+not:
+
+```html
+<span lb-show="out_of_balance" class="danger">Out of balance</span>
+```
+
+These are build errors:
+
+- `lb-show` on a row template's root. A row that should not show is left out
+  by the query.
+- `lb-show` with no row around it: outside every scope, on a scope with none
+  around it, or in a list scope outside its row template, where nothing lands.
+- `lb-show` on a `<template>`.
+
+A condition that is not data, such as a collapsed section or an open menu,
+has no column. Use `<details>`, a stylesheet, or a widget. Every cell still
+carries the value that landed on it as `lb-value`, for a widget to read or a
+stylesheet to select on.
 
 ### An empty list
 
@@ -369,6 +443,12 @@ button in a stylesheet, or have a widget watch its own attributes and
 disable itself. An application that styles neither behaves correctly and
 shows nothing.
 
+A native button or form pressed again while it carries `lb-pending` is
+ignored, so a pending one is already disabled and the stylesheet only shows
+it. A widget is not held back, since one that sends on change must send its
+latest value. The hub also sets `aria-busy="true"` for as long as
+`lb-pending` is present.
+
 ## Sending a request from a widget
 
 A widget can build and dispatch a request itself instead of carrying one of

package/docs/reference/page-files.md

@@ -86,7 +86,7 @@ Export `requests` from `<name>.requests.ts`. It holds three keys, each optional:
 |---------------|------------------------------------------------------|
 | `onPageEnter` | Before the page's queries, on entering the page      |
 | `actions`     | What the page may be asked to do, by name            |
-| `crud`        | The four operations a list permits on its rows       |
+| `crud`        | The three operations a list permits on its rows      |
 
 ### onPageEnter
 
@@ -127,17 +127,21 @@ carries `list` or `row`, whichever attribute scoped the element, plus `key`,
 ### crud
 
 Declare CRUD operations under `crud`, keyed by the list they operate on. All
-four are list operations: each needs a key, and a key exists only on a live
+three are list operations: each needs a key, and a key exists only on a live
 row inside a list, so a single-row scope is read-only and a declared action is
 the only thing it can send. Each operation takes the binding its trigger
 supplies:
 
-| Operation     | The page writes                          | `run` receives         |
-|---------------|------------------------------------------|------------------------|
-| `cellChange`  | `<lb-input lb-action="lb-cell-change">`  | `key`, `cell`, `value` |
-| `rowDelete` | `lb-action="lb-row-delete"`                  | `key`                  |
-| `rowInsert` | `<form lb-action="lb-row-insert">`           | `values`               |
-| `rowUpdate` | `<form lb-action="lb-row-update">`           | `key`, `values`        |
+| Operation   | The page writes                                                        | `run` receives  |
+|-------------|------------------------------------------------------------------------|-----------------|
+| `rowDelete` | `lb-action="lb-row-delete"`                                            | `key`           |
+| `rowInsert` | `<form lb-action="lb-row-insert">`                                     | `values`        |
+| `rowUpdate` | `<form lb-action="lb-row-update">` or `<lb-input lb-action="lb-row-update">` | `key`, `values` |
+
+Write `rowUpdate` to set the columns `values` names and leave every other
+column as it is. A form sends the cells it holds, and a widget cell sends
+itself alone. Check the names in `values` against the columns the list lets
+the page edit.
 
 The operation names are reserved: a name beginning with `lb-` cannot be
 declared under `actions` or as a query, and `createHub` refuses a page that
@@ -179,7 +183,7 @@ would. What `run` returns is laid over the refreshed queries:
 | `patch({ drop: [...] })` | These keys are gone; the rest stand         |
 
 Return a patch for a change the operation knows the extent of — one row added,
-one row dropped, one cell edited — and leave `refresh` empty. Re-run the query
+one row dropped, one row edited — and leave `refresh` empty. Re-run the query
 instead when membership or order changed in a way the operation cannot name:
 
 ```ts

package/docs/reference/widgets.md

@@ -27,7 +27,7 @@ for where a listed package sits in the cascade.
 
 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-cell-change` sends `lb-cell-change`; any other name sends that
+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.
 
@@ -42,7 +42,7 @@ of them, so an input that also sent its own would write the same edit twice.
 
 | Attribute | Asks for |
 | ---------- | ----- |
-| `lb-action` | what to send on `change`; `lb-cell-change` for the cell's own edit |
+| `lb-action` | what to send on `change`; `lb-row-update` to save the cell's own edit |
 
 ## `lb-select`
 

package/docs/roadmap.md

@@ -140,7 +140,7 @@ 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
+with `lb-` that names none of the three 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.
 

package/docs/testing.md

@@ -188,12 +188,18 @@ What the hub is tested for here:
   its scope, whatever shares the button's cell: one ghost row among its
   neighbours, a whole live row, a form nested in a row, a button's form
   owner; and refuses a `<div>` holding cells, pointing to `<form>`
+- an insert or update from an element carrying `lb-cell` sends that cell
+  alone, from the value a widget sent or else its control; refuses a value
+  with no `lb-cell` to name its column; and refuses a click on a native
+  element that is a cell
 - gathering skips the cells of a nested scope, so a picker in a row sends
   its own cell and nothing about its options
 - 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
+  of the three, 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
+- `aria-busy` comes and goes with `lb-pending`; a native button or form
+  performed again while pending sends nothing, and a widget still sends
 - 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