@loadbare/app 0.7.4 → 0.8.1

package/docs/TECHREF-1.0.md

@@ -529,8 +529,7 @@ name, the same test that decides how a value lands — see
 | -------------- | ------------------------------------------------- |
 | lb-row-insert  | a `<form>`, or a button in a `<tr>`, in a list    |
 | lb-row-delete  | anything inside a live row                        |
-| lb-row-update  | a `<form>`, or a button in a live row             |
-| lb-cell-change | a widget wrapping one control                     |
+| lb-row-update  | a `<form>`, a button in a live row, or a widget cell |
 | anything else  | must be a named routine in the page's server code |
 
 The wire format is not visible to the user, but uses the same lb-*
@@ -545,7 +544,6 @@ carries.
 | `action`         | Filled from scope              | Required               |
 | ---------------- | ------------------------------ | ---------------------- |
 | a declared name  | `list` or `row`, `key`, `cell` | nothing                |
-| `lb-cell-change` | `list`, `key`, `cell`          | all three, and `value` |
 | `lb-row-insert`  | `list`                         | `list`, and `values`   |
 | `lb-row-delete`  | `list`, `key`                  | both                   |
 | `lb-row-update`  | `list`, `key`                  | both, and `values`     |
@@ -556,7 +554,13 @@ way a control belongs to the form around it.  `list` or `row` comes from the
 nearest ancestor scope, `key` from the nearest live row inside that scope,
 and `cell` from the dispatching element's own `lb-cell`.
 A request missing a required field is not sent.  The hub never fills
-`value`.  An `lb-row-insert` or `lb-row-update` gathers the row it belongs
+`value`.  An `lb-row-insert` or `lb-row-update` from an element carrying
+`lb-cell` is a record of one cell, the way a control has a value and a form
+has values: `values` holds that cell alone, taken from the `value` the widget
+sent or else read from the control it is or wraps, and `value` is not sent
+beside it.  A widget that sends a `value` from an element carrying no
+`lb-cell` is refused, since nothing names the column.  Any other
+`lb-row-insert` or `lb-row-update` gathers the row it belongs
 to: `values` holds every `lb-cell` with a control to read in the nearest
 `<form>`, `<tr>` or live row around the dispatching element, itself
 included, inside its scope.  The cells are found the way a row lands, so a
@@ -569,10 +573,11 @@ own form; a live row counts because it is the row the key names.  The scope
 itself is never the row, since its cells belong to other rows.  A request
 from an element in no form or row is not sent, and the hub reports that its
 cells belong in a `<form>`.  A request that already carries `values` keeps
-them, and one whose row has no cell to read is not sent.  A click inside a
-native element that carries either operation and
-holds cells itself is not sent, since clicking into one of its controls
-would send the row: put the action on a form or on a button.
+them, and one whose row has no cell to read is not sent.  A click on a
+native element that carries either operation and is a cell or
+holds cells is not sent, since clicking into one of its controls
+would send the row: put the action on a form, on a button, or on a widget
+that decides when its cell has changed.
 
 A widget dispatches the action and, where it wraps a control, that control's
 value.
@@ -581,7 +586,7 @@ value.
 { action: "lb-row-insert",  list: "rosterList", values: {...} }
 { action: "lb-row-delete",  list: "rosterList", key: "42" }
 { action: "lb-row-update",  list: "rosterList", key: "42", values: {...} }
-{ action: "lb-cell-change", list: "rosterList", key: "42", cell: "name", value: "Ann" }
+{ action: "lb-row-update",  list: "rosterList", key: "42", values: { name: "Ann" } }
 { action: "selectTab",      row: "prefs", cell: "active_tab", value: "two" }
 ```
 
@@ -912,7 +917,7 @@ It has three optional keys.
 | Key           | Keyed by              | Answers                                            |
 | ------------- | --------------------- | -------------------------------------------------- |
 | `actions`     | The `lb-action` value | Anything the page chooses to declare               |
-| `crud`        | A query name          | The four reserved `lb-action` values               |
+| `crud`        | A query name          | The three reserved `lb-action` values              |
 | `onPageEnter` | Nothing               | Runs once on entering the page, before its queries |
 
 
@@ -963,16 +968,19 @@ export const requests: Requests = {
 
 Each key under a `crud` entry is a reserved `lb-action` value with its prefix
 stripped and the rest camel-cased, so the attribute, the wire and this key
-are one vocabulary.  All four operate on a list, because each needs a key and
+are one vocabulary.  All three operate on a list, because each needs a key and
 a key exists only on a live row.
 
 | `lb-action`      | Key under `crud` | `where` carries        |
 | ---------------- | ---------------- | ---------------------- |
-| `lb-cell-change` | `cellChange`     | `key`, `cell`, `value` |
 | `lb-row-delete`  | `rowDelete`      | `key`                  |
 | `lb-row-insert`  | `rowInsert`      | `values`               |
 | `lb-row-update`  | `rowUpdate`      | `key`, `values`        |
 
+A `rowUpdate` sets the columns `values` names and leaves the rest as they
+are, as an SQL `UPDATE` does.  A form sends the cells it holds and a widget
+cell sends itself, so one handler answers both.
+
 ## Widgets
 
 ---- UNEDITED ----
@@ -1124,7 +1132,7 @@ application writes the ones this table names and invents none of its own,
 because a name Loadbare has not defined today it may define tomorrow.
 
 The prefix reaches past HTML.  A query name cannot begin with `lb-` either,
-which is what keeps the four operations apart from an application's own
+which is what keeps the three operations apart from an application's own
 actions on the wire — see [Page Queries](#page-queries).
 
 Each attribute is defined in one section, and this table says which.

package/docs/analysis-closed-set.md

@@ -71,17 +71,23 @@ closed.
 | 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 supplied by a widget     | 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    |
 
-### Proposed: fold `lb-cell-change` into `lb-row-update`
+### Done: `lb-cell-change` folded into `lb-row-update`
 
-A cell change is an update whose `values` holds one entry, and the hub
-already keeps `values` a widget supplies.  SQL has one UPDATE whether it sets
-one column or many.  On the server, `cellChange` and `rowUpdate` merge into
-one `update(key, values)`, where a column absent from `values` is left as it
-is.
+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
 
@@ -177,8 +183,9 @@ overwrites that in 0.7.3, so the rule introduces nothing new.
 
 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 widget-supplied
-   `values`, and the server's `cellChange` and `rowUpdate` merge.
+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.
 

package/docs/comparison.md

@@ -411,25 +411,26 @@ Data types are an open blocker in TECHREF-1.0.
 ### Loadbare/app
 
 `lb-action` names what an interaction asks for.  A value beginning with `lb-`
-is one of four reserved operations; any other value is an action the page
+is one of three reserved operations; any other value is an action the page
 declares.
 
 | `lb-action`      | Written on                                  | Carries                         | Server key under `crud` |
 |------------------|---------------------------------------------|---------------------------------|-------------------------|
 | `lb-row-insert`  | A `<form>`, or a button in a `<tr>`, in a list | `list`, `values`             | `rowInsert`             |
-| `lb-row-update`  | A `<form>` or a button in a live row        | `list`, `key`, `values`         | `rowUpdate`             |
+| `lb-row-update`  | A `<form>`, a button in a live row, or a widget cell | `list`, `key`, `values` | `rowUpdate`             |
 | `lb-row-delete`  | Anything inside a live row                  | `list`, `key`                   | `rowDelete`             |
-| `lb-cell-change` | A widget wrapping one control               | `list`, `key`, `cell`, `value`  | `cellChange`            |
 | Any other name   | Any element                                 | Scope in effect, and a widget's `value` | Under `actions`  |
 
 - Position comes from the document.  `list` or `row` comes from the nearest
   ancestor scope, `key` from the nearest live row, `cell` from the element's
   own `lb-cell`.  The author writes the action and not the position.
 - Values are gathered from the nearest `<form>`, `<tr>` or live row around
-  the element, the way a button submits its form owner.
+  the element, the way a button submits its form owner.  A widget carrying
+  `lb-cell` sends its own cell alone, so one `rowUpdate` answers a form and a
+  per-field edit.
 - A native element sends on click, a form on submit.  A widget sends its own.
 - A declared action carries no argument list.
-- A single-row scope is read-only for the four operations, because each needs
+- A single-row scope is read-only for the three operations, because each needs
   a key and a key exists only on a live row in a list.
 
 On the server, each entry has `run` and `refresh`.  `run` does the work and
@@ -728,7 +729,7 @@ TECHREF-1.0 lists every name Loadbare/app owns in one cross-reference.
 | Owned                               | Count | Names                                                         |
 |-------------------------------------|-------|---------------------------------------------------------------|
 | `lb-*` HTML attributes              | 16    | `lb-list`, `lb-row`, `lb-cell`, `lb-show`, `lb-key`, `lb-key-value`, `lb-value`, `lb-action`, `lb-nav-link`, `lb-pending`, `lb-error`, `lb-row-count`, `lb-unknown-page`, `lb-slot`, `lb-template`, `lb-page` |
-| Reserved `lb-action` values         | 4     | `lb-row-insert`, `lb-row-update`, `lb-row-delete`, `lb-cell-change` |
+| Reserved `lb-action` values         | 3     | `lb-row-insert`, `lb-row-update`, `lb-row-delete`             |
 | `lb*` methods on custom elements    | 2     | `lbPlaceRow`, `lbRowsLanded`                                  |
 | Attribute namespace for expansion   | 1     | `exp-*`                                                       |
 | Reserved tags                       | 1     | `<lb-hub>`                                                    |

package/docs/reference/custom-elements.md

@@ -229,8 +229,8 @@ as a string literal.
 | `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` |
@@ -287,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 }));
 ```
 
@@ -296,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

@@ -152,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.
@@ -166,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
@@ -184,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>
@@ -280,6 +276,34 @@ 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

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

@@ -19,15 +19,15 @@ npm install @loadbare/widgets
 export default ["@loadbare/widgets"];
 ```
 
-See [Using Widget Libraries](../tutorials/090-using-widget-libraries.md) for
-what listing a package does, and [The Builder](./builder.md#where-the-builder-looks)
+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`
 
 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,10 +188,14 @@ 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

package/docs/theory.md

@@ -460,7 +460,7 @@ that "knows what to do", assembling a request driven purely from
 attributes. 
 
 This requirement is satisfied with a single new attribute, `lb-action`.
-Four values are reserved, and any other value is interpreted as the
+Three values are reserved, and any other value is interpreted as the
 name of a routine on the server.
 
 A request is an action and a position.  The author writes the action,

package/docs/tutorials/080-widget-requests.md

@@ -37,7 +37,7 @@ class NoteInput extends HTMLElement {
       this.dispatchEvent(
         new CustomEvent(LB_EVENT_NAME, {
           bubbles: true,
-          detail: { action: "lb-cell-change", value: input.value },
+          detail: { action: "lb-row-update", value: input.value },
         }),
       );
     });
@@ -49,9 +49,9 @@ customElements.define("note-input", NoteInput);
 
 A widget with both a `.html` and a `.browser.ts` file shares one tag name; the
 build finds each half independently. On change, it dispatches a
-`lb-cell-change` carrying the input's value. The hub adds the list, the key
-of the row it is in and its own `lb-cell`, the same way it does for a
-`lb-row-update` form.
+`lb-row-update` carrying the input's value. The hub adds the list and the key
+of the row it is in, and turns the value into a `values` map holding only
+the widget's own `lb-cell`.
 
 ## Using it
 
@@ -72,30 +72,11 @@ every change, so there's nothing left to batch.
 
 ## Answering it server-side
 
-```ts
-// src/pages/about.requests.ts
-import { patch } from "@loadbare/app/server";
-
-export const requests = {
-  // ...onPageEnter and actions unchanged...
-  crud: {
-    notes: {
-      // ...rowInsert, rowDelete, rowUpdate unchanged...
-      cellChange: {
-        run: async (ctx, { key, value }) => {
-          const note = await ctx.db.updateNote(key, value);
-          return { notes: patch({ rows: [note] }) };
-        },
-        refresh: [],
-      },
-    },
-  },
-};
-```
-
-`cellChange` reuses `updateNote` from [Updating a List Item](./076-updating-a-list-item.md)
-— the database doesn't care whether the edit came from a form's values
-map or one widget's value.
+There is nothing to add. The request is the same `lb-row-update` the form
+sent in [Updating a List Item](./076-updating-a-list-item.md), with `values`
+holding only `text`, so the `rowUpdate` written there answers it unchanged.
+A `rowUpdate` sets the columns `values` names and leaves the rest alone, as
+an SQL `UPDATE` does, so one handler serves a form and a widget alike.
 
 ## Run it
 

package/package.json

@@ -1,18 +1,21 @@
 {
   "name": "@loadbare/app",
   "description": "High performance web app framework for server-bound applications",
-  "version": "0.7.4",
+  "version": "0.8.1",
   "type": "module",
   "files": [
     "dist",
     "docs",
+    "skills/loadbare-app/SKILL.md",
+    "skills/loadbare-app/references",
     "README.md"
   ],
   "publishConfig": {
     "access": "public"
   },
   "bin": {
-    "loadbare-app-build": "dist/build/cli.js"
+    "loadbare-app-build": "dist/build/cli.js",
+    "loadbare-app": "dist/build/skills-cli.js"
   },
   "exports": {
     ".": "./dist/hub/lb-hub.browser.js",
@@ -31,8 +34,9 @@
     "release:major": "node ../../scripts/bump-release.mjs major",
     "prebuild": "node --eval \"fs.rmSync('dist',{recursive:true,force:true})\" --input-type=module",
     "build:server": "tsc --project tsconfig.build.json",
-    "build": "npm run build:server",
-    "postbuild": "node --eval \"fs.chmodSync('dist/build/cli.js', 0o755)\" --input-type=module && node ../../scripts/check-dist-imports.mjs",
+    "build:skills": "node scripts/build-skills.mjs",
+    "build": "npm run build:server && npm run build:skills",
+    "postbuild": "node --eval \"for (const f of ['dist/build/cli.js','dist/build/skills-cli.js']) fs.chmodSync(f, 0o755)\" --input-type=module && node ../../scripts/check-dist-imports.mjs",
     "test": "tsx --test \"tests/**/*.test.ts\"",
     "typecheck": "tsc --noEmit",
     "format": "prettier --write .",