uniweb 0.33.1 → 0.34.1

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "uniweb",
-  "version": "0.33.1",
+  "version": "0.34.1",
   "description": "Create structured Vite + React sites with content/code separation",
   "type": "module",
   "bin": {
@@ -41,15 +41,15 @@
     "js-yaml": "^4.1.0",
     "prompts": "^2.4.2",
     "tar": "^7.0.0",
-    "@uniweb/core": "^0.13.1",
-    "@uniweb/kit": "^0.14.0",
-    "@uniweb/semantic-parser": "^1.3.1",
-    "@uniweb/runtime": "^0.13.1"
+    "@uniweb/runtime": "^0.13.3",
+    "@uniweb/kit": "^0.15.0",
+    "@uniweb/core": "^0.14.1",
+    "@uniweb/semantic-parser": "^1.3.1"
   },
   "peerDependencies": {
-    "@uniweb/build": "^0.29.1",
     "@uniweb/content-reader": "^1.2.4",
-    "@uniweb/semantic-parser": "^1.3.1"
+    "@uniweb/semantic-parser": "^1.3.1",
+    "@uniweb/build": "^0.30.0"
   },
   "peerDependenciesMeta": {
     "@uniweb/build": {

package/partials/agents.md

@@ -770,24 +770,36 @@ seo:
 
 That emits a `Content-Signal:` line in `robots.txt`. Declare only what you mean — an omitted signal says nothing, which is not the same as saying no.
 
-### Collections and dynamic routes
+### Records, queries and dynamic routes
 
-Most content lives in `pages/` — a fixed composition of sections on a fixed set of pages. **Collections are the other kind: repeating content managed as a set of files**, one item per file, that pages pull from. Blog posts, team members, products, case studies, bibliographies.
+Most content lives in `pages/` — a fixed composition of sections on a fixed set of pages. **The other kind is a set of records: repeating content managed as one file per item**, that pages pull from. Blog posts, team members, products, case studies, bibliographies.
 
-They're delivered through the **same data pipeline as remote APIs**, so from a component's point of view a locally-authored collection and a backend-served one look identical. Whether the records live in files or behind an endpoint is a transport concern (see *Fetching from other sources* in Part 4).
+It is a small database, not a page tree. Three things, deliberately separate:
 
 ```
 site/
 ├── pages/
-├── collections/
-│   ├── articles/
+├── entities/          # your stored things. The folder names their data schema
+│   ├── article/
 │   │   ├── getting-started.md
 │   │   └── design-tips.md
-│   └── team/
+│   └── person/
 │       └── alice.yml
+├── records.yml        # what is PUBLISHED
+├── queries.yml        # how content is REACHED
 └── site.yml
 ```
 
+**`entities/{schema}/` — the pool.** The folder names the data schema and nothing else:
+
+| on disk | schema |
+|---|---|
+| `entities/article/…` | `@/article` — your foundation's own |
+| `entities/std/person/…` | `@std/person` — the shared standard set |
+| `entities/acme/project/…` | `@acme/project` — an org's |
+
+Keep those folders flat: `entities/article/design-tips.md` works; `entities/article/2025/design-tips.md` is read as the `2025` schema of an `article` org, which is not what you meant. Organise in `records.yml` instead.
+
 **Four formats, one shape.** All of these produce the same records at runtime:
 
 | Format | Best for | Notes |
@@ -799,62 +811,85 @@ site/
 
 **One record per file, or many.** A single mapping at the top of a file makes one record and the filename stem becomes its `slug`. A top-level array (YAML/JSON) or a multi-entry `.bib` makes many, each carrying its own `slug`. You can mix both in one folder — an exported `refs.bib` beside a hand-written `extras.yml`.
 
-**Keep collection folders flat.** `collections/articles/design-tips.md` works; `collections/articles/2025/design-tips.md` does not.
-
 Item frontmatter conventionally uses `title`, `date`, `tags`, `image`, `description`, `published`, `author` — plus any fields your content needs (`price`, `role`, `order`). Images can sit beside the item file and be referenced with `./`. `published: false` hides an item without deleting it; items with no `published` field are included.
 
-**Declare each collection in `site.yml`:**
+**`records.yml` — listing an entity is what publishes it.** A file in `entities/` exists; listing it here makes it a record. Anything you leave out is a draft — no flag to set. **The common case is three lines:**
 
 ```yaml
-collections:
-  articles: collections/articles         # simple form — just point at the folder
+- article/*.md
+- person/*.yml
+```
+
+A bare string is a path under `entities/`, naming one file or matching many.
+
+⚠️ **An empty `records.yml` is not the same as having none.** No file means "leave the published set alone". An empty file means "the folder holds nothing", which REMOVES what is published. The CLI asks before it does that.
+
+**Structure is for querying, not for navigation.** Add a `folder:` only when a query needs to ask for a *slice* of the pool rather than all of it — most sites never do:
 
-  team:                                  # extended form
-    path: collections/team               # or `url:` for a remote source
-    sort: order asc                       # `date desc`, `title asc`, …
-    where: { published: { ne: false } }   # a predicate — see authoring/predicates.md
-    limit: 100
+```yaml
+- article/2026-*.md
+- folder: archive
+  label: The Archive
+  records:
+    - article/2025-*.md
+```
+
+A query then slices it with `where: { path: { under: 'archive' } }`. An entity belongs to one folder; if you want a computed subset, that is a query, not a second placement.
+
+**`queries.yml` — how content is reached.** A bare map of name → query. A query names a schema and the published records of that schema are its rows:
+
+```yaml
+recent:
+  schema: '@/article'
+  sort: date desc                        # `date desc`, `title asc`, …
+  limit: 10
+
+team:
+  schema: '@std/person'
+  where: { published: { ne: false } }    # a predicate — see authoring/predicates.md
 ```
 
-**Show a collection on a page** with `data:` in `page.yml` (the whole collection), or `fetch:` in a section's frontmatter (a subset):
+You can keep the same declarations under `queries:` in `site.yml` instead, if you would rather have one file.
+
+**Show a query on a page** with `data:` in `page.yml` (the whole result), or `fetch:` in a section's frontmatter (a subset):
 
 ```yaml
 # pages/blog/page.yml          |   # a section on the homepage
 title: Blog                    |   ---
-data: articles                 |   type: ArticleTeaser
-                               |   fetch: { collection: articles, limit: 3, sort: date desc }
+data: recent                   |   type: ArticleTeaser
+                               |   fetch: { query: recent, limit: 3 }
                                |   ---
 ```
 
-**Give each item its own page with a `[slug]/` folder** under the list page:
+**Give each record its own page with a `[slug]/` folder** under the list page:
 
 ```
 pages/blog/
-├── page.yml          # title: Blog / data: articles
+├── page.yml          # title: Blog / data: recent
 ├── list.md
 └── [slug]/
     ├── page.yml
-    └── article.md    # just `type: Article` — the item arrives automatically
+    └── article.md    # just `type: Article` — the record arrives automatically
 ```
 
-`collections/articles/design-tips.md` becomes `/blog/design-tips`. The section inside `[slug]/` needs no special markdown — the matched record is delivered to it. Generated pages are excluded from navigation menus.
+`entities/article/design-tips.md` becomes `/blog/design-tips`. The section inside `[slug]/` needs no special markdown — the matched record is delivered to it. Generated pages are excluded from navigation menus.
 
-> **The record arrives as a single-element array under the collection key** — `content.data.articles[0]`, not `content.data.article`. The runtime never coerces it to an object and never synthesizes a singular key. See *Data* in Part 4.
+> **The record arrives as a single-element array under the query key** — `content.data.recent[0]`, not `content.data.article`. The runtime never coerces it to an object and never synthesizes a singular key. See *Data* in Part 4.
 
-**Two options for bigger collections:**
+**Two options for bigger sets:**
 
-`deferred: [body]` strips heavy fields from the list payload — cards stay light, while a `[slug]` page still receives the full record automatically and other components fetch on demand via `useEntityDetail`. For a remote collection, add `detailUrl: /api/articles/{slug}` so the framework knows how to fetch one full record; file-based collections emit per-record files at `/data/<name>/<slug>.json` and need no configuration.
+`deferred: [body]` strips heavy fields from the list payload — cards stay light, while a `[slug]` page still receives the full record automatically and other components fetch on demand via `useEntityDetail`. For a remote source, add `detailUrl: /api/articles/{slug}` so the framework knows how to fetch one full record; file-based records emit per-record files at `/data/<name>/<slug>.json` and need no configuration.
 
 `queryable:` declares which fields a reader may filter on, with enough metadata for the foundation to render controls:
 
 ```yaml
-collections:
-  members:
-    path: collections/members
-    queryable:
-      department: { type: enum, label: Department, options: [biology, physics, chemistry] }
-      tenured:    { type: boolean, label: Tenured }
-      start_year: { type: range, label: Start year, min: 1800, max: 2025 }
+# queries.yml
+members:
+  schema: '@std/person'
+  queryable:
+    department: { type: enum, label: Department, options: [biology, physics, chemistry] }
+    tenured:    { type: boolean, label: Tenured }
+    start_year: { type: range, label: Start year, min: 1800, max: 2025 }
 ```
 
 The site declares the *surface*; the foundation reads the metadata, renders matching controls (dropdown, toggle, slider), and composes the predicate when the reader picks values.
@@ -1745,13 +1780,13 @@ A foundation can route a scope to a plain folder of schema files instead of a pa
 ```yaml
 # pages/blog/page.yml
 fetch:
-  collection: articles
+  query: recent
   where: { published: true, tags: featured }
   sort: date desc
   limit: 3
 ```
 
-**Lean lists with `deferred:`.** Collections with heavy fields (article bodies, large nested arrays) can declare `deferred: [body]` in `site.yml`. The cascade payload omits those fields; per-record full files are emitted at `/data/<name>/<slug>.json` (file-based collections) or fetched from an author-declared `detailUrl:` (API-backed). On dynamic-route pages the focused record's full data is delivered automatically; elsewhere components fetch on demand via `useEntityDetail`. The hook is safe to call on any collection: when there is no separate detail source it returns the record you passed in, because nothing was stripped from it.
+**Lean lists with `deferred:`.** A query over records with heavy fields (article bodies, large nested arrays) can declare `deferred: [body]`. The cascade payload omits those fields; per-record full files are emitted at `/data/<name>/<slug>.json` (file-based records) or fetched from an author-declared `detailUrl:` (API-backed). On dynamic-route pages the focused record's full data is delivered automatically; elsewhere components fetch on demand via `useEntityDetail`. The hook is safe to call on any query: when there is no separate detail source it returns the record you passed in, because nothing was stripped from it.
 
 **Component-side fetching.** When a component genuinely needs to fetch on its own (a search box, "load more", a lazy popover), use the kit hooks — `useFetched`, `useCacheEntry`, `useEntityDetail`. They share the framework's cache and dispatcher with declarative fetches; same-key requests dedupe automatically.
 
@@ -1766,7 +1801,7 @@ A site isn't limited to file-based collections. The `fetcher:` block in `site.ym
 fetcher:
   baseUrl: https://api.example.com
   headers: { X-Tenant: acme }
-  envelope: { collection: data.items, item: data.article, error: errors.0.message }
+  envelope: { list: data.items, item: data.article, error: errors.0.message }
 
   supports: [where, limit, sort]     # which operators the source evaluates natively
 
@@ -2383,12 +2418,12 @@ Running `extract` before a build is the usual first mistake — it reads the com
 
 ```
 locales/freeform/es/pages/about/hero.md        # by page route
-locales/freeform/es/collections/articles/x.md  # collections work too
+locales/freeform/es/entities/article/x.md      # records work too
 ```
 
 These are **body only — no frontmatter**; params and config still come from the source section. `uniweb i18n init-freeform es pages/about hero` creates one pre-filled and records a source hash, so `uniweb i18n status --freeform` can tell you when the original moved on (`update-hash` to acknowledge). `move`, `rename`, and `prune --freeform` keep them aligned when pages get reorganized.
 
-**Collections translate in the same `extract` run**, into their own manifest at `locales/collections/manifest.json`.
+**Records translate in the same `extract` run**, into their own manifest at `locales/records/manifest.json` — keyed by the RECORD, so a record translated once is found by every query that returns it.
 
 **Component side.** Nothing to do: `content.title` arrives in the active language. The one thing a foundation builds is a switcher.
 

package/src/backend/client.js

@@ -105,34 +105,39 @@ export function resolveBackendOrigin(flag, { siteScope, siteBackend } = {}) {
 }
 
 /**
- * The fallback capability doc when `GET /dev/config` is absent or unreachable
- * (an older backend, or no backend at all). Keeps the client non-breaking: the
- * bases mirror a self-serve dev backend.
+ * The fallback capability doc for when `GET /dev/config` was not asked for (no
+ * credential in hand) or did not answer. Keeps the client non-breaking.
+ *
+ * ⭐ **It is EMPTY, and that is the accurate shape.** The CLI reads exactly one leaf of
+ * that document — `delivery.siteSubscriptionRequired` — and its absence is meaningful:
+ * unknown reads falsy, and the caller stays silent rather than claiming a deployment
+ * does or does not charge. Every other key that used to sit here had no reader.
+ *
+ * ⛔ **Do not restore a key "for completeness".** A default for a field nothing reads is
+ * a reader waiting to happen, and it is how this file came to describe a client that
+ * discovered its backend's gateway base, asset base and login path — none of which was
+ * ever true. The removals, and why each was not merely unused but wrong:
+ *
+ *   `gatewayBase`  sat here UNREAD until 2026-07-29. A serve location is read from the
+ *                  response that carries it (an upload plan's `serve_base`, an asset
+ *                  entry's `serve_url`, a payload's `config.base`) — never from a
+ *                  handshake, which cannot know a per-response answer.
+ *   `assetBase`    until 2026-08-17: one production host, hardcoded, applied to every
+ *                  deployment the CLI can be pointed at. Read only to compose an asset
+ *                  URL the plan already returns verbatim. Reader and composer both gone.
+ *   `runtime`      until 2026-08-22. A backend does not hold runtimes — a version comes
+ *                  from a CDN — so there is no installed set to report. What a site gets
+ *                  follows from its foundation's floor (`info.runtime`, at register).
+ *   `auth`         `loginPath` was never read: the login path is a constant in
+ *                  `utils/registry-auth.js`, and the ORIGIN comes from the resolution
+ *                  ladder, so the CLI is never told where to log in — it is born knowing.
+ *   `delivery`     `deploy` and `broker` had no reader. `publish` had one, but it could
+ *                  never refuse: the backend sent a literal true for every deployment,
+ *                  so the gate read a constant. Removed on both sides 2026-08-30.
+ *   `assets`       `supported` had no reader; the asset lane reports its own capability
+ *                  through the upload plan it returns.
  */
-export const DISCOVERY_DEFAULTS = {
-  // ⛔ No serve-root default, and no `assetBase`. Serve locations are read from
-  // discovery or from a per-response field (an upload plan's `serve_base`, an
-  // asset entry's `serve_url`); nothing here reconstructs one, so a default is a
-  // route name with no consumer. (A `gatewayBase` entry lived here unread until
-  // 2026-07-29.)
-  //
-  // `assetBase: 'https://assets.uniweb.app/'` sat here until 2026-08-17 — one
-  // production host, hardcoded, applied to EVERY deployment the CLI can be
-  // pointed at. It was only ever read to compose an asset URL, which the plan
-  // already returns as `serve_url`; both the reader and the composer are gone.
-  //
-  // No `runtime` entry, and there must not be one. A backend does not hold
-  // runtimes: a version is acquired from a CDN — the official mirror, the
-  // distribution channel, or a local server — so there is no installed set for
-  // it to report and nothing here to default. `runtime.installed` lived here
-  // until 2026-08-22, alongside a `uniweb runtime register` verb that pushed
-  // builds to a backend; both are gone. The runtime a site gets follows from
-  // its foundation's floor (`info.runtime`, stated at register), not from
-  // anything the CLI asks a backend about.
-  auth: { loginPath: '/dev/auth/login', required: true },
-  delivery: { deploy: true, publish: true, broker: 'self-serve' },
-  assets: { supported: false }
-}
+export const DISCOVERY_DEFAULTS = {}
 
 export class BackendClient {
   /**
@@ -250,18 +255,78 @@ export class BackendClient {
   // ── Discovery ─────────────────────────────────────────────────────────────────
 
   /**
-   * GET /dev/config — the anonymous capability/handshake document. The one route
-   * that answers before login (`auth: false`). Lazy + cached for the client's
-   * lifetime; a missing route or any transport/parse error falls back to
-   * DISCOVERY_DEFAULTS (non-breaking — an older backend still works). Lets the
-   * CLI hardcode nothing about a backend but its origin and discover the rest:
-   * `auth`, `delivery` (deploy/publish? broker), `assets` (lane built yet?).
+   * The session bearer IF one can be had without asking — an explicit `--token`, an
+   * env var, or a stored unexpired session. Never prompts, never logs in, returns null
+   * instead. `token()` is the one that may block; this is for calls that want to be
+   * authenticated when possible but must not *cause* an authentication.
+   * @returns {Promise<string|null>}
+   */
+  async _tokenIfAvailable() {
+    if (this._token) return this._token
+    // ⛔ The injected resolver must be honoured here too, not just in `token()`.
+    // `pull` and `clone` pass one (`deps.getToken`), so skipping it would treat a caller
+    // that supplies its own auth as unauthenticated — and, worse, fall through to the
+    // machine's stored session, quietly using a DIFFERENT credential than the caller
+    // asked for. A throwing resolver is "no token", never a failed command.
+    if (this._getToken) {
+      try {
+        return (await this._getToken()) || null
+      } catch {
+        return null
+      }
+    }
+    try {
+      const stored = await readRegistryAuth()
+      if (stored?.token && !isExpired(stored)) return stored.token
+    } catch {
+      /* advisory — a missing or unreadable session is simply "no token" */
+    }
+    return null
+  }
+
+  /**
+   * GET /dev/config — the capability/handshake document. Lazy + cached for the client's
+   * lifetime; a missing route, a 401, or any transport/parse error falls back to
+   * DISCOVERY_DEFAULTS, so this can never be the reason a command fails.
+   *
+   * ⭐ **Authenticated, or not sent at all.** `/dev/*` is the CLI's lane and the CLI is
+   * an authenticated client, so this attaches the bearer when it has one and **makes no
+   * request when it does not** — which keeps that true by construction rather than by
+   * ordering luck, and makes the route moving behind auth a no-op here.
+   *
+   * ⚠️ It uses `_tokenIfAvailable()` and never `token()`, deliberately: **discovery must
+   * never be the thing that triggers a login.** A capability probe that opens a password
+   * prompt would be a worse defect than the anonymous call it replaced.
+   *
+   * ⛔ **Most of this document is deliberately not read.** `gatewayBase` and `assetBase`
+   * were dropped because a serve location is read from the response that carries it
+   * (`serve_base`, `serve_url`, `config.base`), never from a handshake; `auth.loginPath`
+   * is not read either — the login path is a hardcoded constant
+   * (`utils/registry-auth.js`). What is actually consumed is ONE leaf —
+   * `delivery.siteSubscriptionRequired` — and nothing else. Do not add a reader for the
+   * rest: each one would be a second place a backend's layout is pinned.
+   *
    * @returns {Promise<object>}
    */
   async discover() {
     if (this._discovery) return this._discovery
+    const bearer = await this._tokenIfAvailable()
+
+    // ⛔ NO CREDENTIAL ⇒ NO REQUEST. This is the rule made structural rather than
+    // incidental: apart from the login routes themselves, the CLI does not touch
+    // `/dev/*` without a bearer. The defaults are the honest answer here — we do not
+    // know this backend's capabilities and are not entitled to ask yet — and every
+    // caller already treats them as non-breaking, so nothing downstream changes.
+    if (!bearer) {
+      this._discovery = { ...DISCOVERY_DEFAULTS }
+      return this._discovery
+    }
+
     try {
-      const res = await this.request('/dev/config', { auth: false })
+      const res = await this.request('/dev/config', {
+        auth: false,
+        headers: { Authorization: `Bearer ${bearer}` }
+      })
       this._discovery = res.ok ? await res.json() : { ...DISCOVERY_DEFAULTS }
     } catch {
       this._discovery = { ...DISCOVERY_DEFAULTS }
@@ -519,7 +584,29 @@ export class BackendClient {
    * shipped backend-side — collab backend-framework-b220):
    *   { published: boolean, last_pushed_at?: string, last_published_at?: string, draft_dirty?: boolean }
    * `draft_dirty` = never-published, or the synced draft changed since the last
-   * publish ("pushed but not published"). The path is VERB-FIRST (`status/{uuid}`)
+   * publish ("pushed but not published").
+   *
+   * ⭐ **The backend also serves a LIVE-SITE record here, and nothing in this CLI reads
+   * it yet** (shipped 2026-08-29; documented here so it is not lost twice):
+   *
+   *   last_published_url · last_published_foundation · last_published_extensions
+   *   last_published_runtime · last_published_runtime_floor · last_published_runtime_resolution
+   *
+   * Three things about it that a reader will otherwise get wrong:
+   *
+   * ⛔ `runtime_resolution` is `resolved` or `pinned:<reason>` (`operator` / `unknown_floor` /
+   *    `no_foundations`). **A pin is a first-class answer, not a failure** — most sites are pinned
+   *    at any moment, and an "old" runtime still satisfies the site's floor. Never surface
+   *    `pinned:*` as an error state.
+   * ⛔ `extensions` is there because a site's code surface is the primary foundation **plus N
+   *    extensions**; reading the primary alone describes a site nobody has.
+   * ⛔ `last_*` is deliberate on every one. `unpublish` LEAVES the URL populated (the static site
+   *    may still be reachable), so beside `published: bool` a bare `published_url` would read as a
+   *    liveness claim and be wrong exactly when it matters. And **nothing back-fills** — a site
+   *    published before this reports them absent, which means "published before we recorded it",
+   *    never "has no foundation".
+   *
+   * The path is VERB-FIRST (`status/{uuid}`)
    * to match the lane (`publish/{uuid}`, `content/push/{uuid}`, `folder/pull/{uuid}`),
    * not the `{uuid}/status` the shipping-verbs §8 sketch assumed. null on
    * 404 (unknown/not-yours) / 401 / any failure — `status --remote` degrades to local.

package/src/backend/site-sync.js

@@ -27,7 +27,7 @@ import {
   computeUnitHashes,
   collectUnitUuids,
   collectFolderItemUuids,
-  collectCollectionUuids,
+  collectQueryUuids,
   readAssetMap
 } from '@uniweb/build/uwx'
 
@@ -242,7 +242,7 @@ export function clearRemoteSyncState(siteDir, siteUuid = null) {
   const prior = readSyncCacheFile(siteDir)
   const dropped = [
     'itemUuids',
-    'collectionUuids',
+    'queryUuids',
     'hashes',
     'baseVersions',
     'unitBases',
@@ -252,7 +252,7 @@ export function clearRemoteSyncState(siteDir, siteUuid = null) {
     itemUuids: {},
     // Remote-derived exactly like itemUuids — it holds the OLD site's collection
     // ids, and surviving the drop it would offer them for the new site's sections.
-    collectionUuids: {},
+    queryUuids: {},
     hashes: {},
     baseVersions: {},
     unitBases: {},
@@ -492,12 +492,12 @@ export function readFolderItemUuids(siteDir) {
  * its own join key. ⛔ Not `$id`: it holds the same string but is a payload-local
  * handle the backend skips on parse and never stores.
  */
-export function readCollectionUuids(siteDir) {
-  return readMap(siteDir, 'collectionUuids')
+export function readQueryUuids(siteDir) {
+  return readMap(siteDir, 'queryUuids')
 }
-export function writeCollectionUuids(siteDir, map) {
+export function writeQueryUuids(siteDir, map) {
   if (!map || !Object.keys(map).length) return
-  updateSyncCache(siteDir, { collectionUuids: map })
+  updateSyncCache(siteDir, { queryUuids: map })
 }
 export function writeFolderItemUuids(siteDir, map) {
   if (!map || !Object.keys(map).length) return
@@ -859,28 +859,27 @@ async function recordAndDescribeOwner({ client, siteDir, payload, asOrg, note })
       : `Created the site on the backend, owned personally (recorded $uuid in site.yml).`
   )
 
-  // The billing line needs the JOIN of two independent facts, and either alone
-  // gives a wrong answer:
-  //   hosts_free               — a property of the SCOPE (is this owner exempt?)
-  //   siteSubscriptionRequired — a property of the DEPLOYMENT (does it charge at all?)
-  // Keyed on the scope alone, this fires on every local publish — where nothing
-  // enforces — until the warning is trained away. Keyed on the deployment alone it
-  // fires at exempt owners. An older backend supplies neither, so both read falsy
-  // and nothing is said: silence beats a claim we cannot justify.
-  const hostsFree = payload?.hosts_free === true
-  let enforces = false
-  try {
-    const cfg = await client.discover()
-    enforces = cfg?.delivery?.siteSubscriptionRequired === true
-  } catch {
-    /* discovery is advisory here — never fail a create over a message */
-  }
-  if (hostsFree) {
+  // What the create echoed about this site's OWNER, and nothing beyond it.
+  //
+  // `hosts_free` is a property of the SCOPE — is this owner exempt? — and it is the only
+  // billing fact the CLI holds. This used to JOIN it with `siteSubscriptionRequired`
+  // from the discovery document, a property of the DEPLOYMENT. That leaf left the wire:
+  // every deployment charges, so it read true everywhere and the join was testing a
+  // constant.
+  //
+  // ⛔ AND THE WARNING WENT WITH IT — this is NOT a fallback to keying on the scope
+  // alone, which is the exact thing the join existed to prevent. Whether a given publish
+  // is charged is derived per-site at publish time, on a side the CLI cannot see, so any
+  // prediction made here can only be approximately right and would go stale silently.
+  // The backend's typed 402 (`reason: "no_subscription"`) is exact, per-site, and
+  // arrives when it matters; `backend/payment-handoff.js` already turns it into a
+  // checkout. Deciding whether payment is due is not the CLI's job.
+  //
+  // ⇒ What survives is the reassuring direction only, and only when it was stated:
+  // `false` is an answer we deliberately do not speak to, and missing is not an answer
+  // at all. Do not reintroduce a "you will be charged" line here.
+  if (payload?.hosts_free === true) {
     note?.('This owner is hosted free — publishing will not require a subscription.')
-  } else if (enforces) {
-    note?.(
-      'Publishing this site live will require a hosting subscription on this backend.'
-    )
   }
   return org
 }
@@ -968,12 +967,12 @@ export async function probeUnpushed(siteDir, { sendAll = false } = {}) {
   //
   // ⛔ THE ORG IS NOT OPTIONAL HERE, AND OMITTING IT WAS SILENT. It is what resolves
   // a foundation-relative `@/member` into the `@org/member` the push shipped and
-  // keyed its hashes by. Without it the emit does not fail — `buildCollectionEntities`
+  // keyed its hashes by. Without it the emit does not fail — `buildRecordEntities`
   // WARNS and ships the model unresolved, deliberately, so an org-less export still
   // works — so every record of a `@/`-scoped collection is emitted under a key that
   // can never match its banked one, and reads as changed forever.
   //
-  // ⚠️ It hides in plain sight because `@std/…` collections are unaffected: their
+  // ⚠️ It hides in plain sight because `@std/…` queries are unaffected: their
   // scope is already absolute, so they match. A site mixing both — the marketing
   // fixture has `@std/person` AND `@proximify/member` — shows some records settling
   // and others never settling, which reads like a content problem rather than a
@@ -981,7 +980,7 @@ export async function probeUnpushed(siteDir, { sendAll = false } = {}) {
   // immediately after a successful push; passing the org took it to 1.
   const pkg = await comparisonEmit(siteDir, { priorHashes, sendAll })
   const changed =
-    (pkg.siteContent?.entityCount || 0) + (pkg.collections?.entityCount || 0)
+    (pkg.siteContent?.entityCount || 0) + (pkg.records?.entityCount || 0)
   return { changed, unchanged: pkg.skipped || 0, warnings: pkg.warnings || [] }
 }
 
@@ -1008,13 +1007,13 @@ async function comparisonEmit(siteDir, { priorHashes = {}, sendAll = false } = {
   const applied = readAppliedInjections(siteDir)
   const assetIds = readAssetMap(siteDir)
   const org = readSiteOrg(siteDir)
-  const collectionUuids = readCollectionUuids(siteDir)
+  const queryUuids = readQueryUuids(siteDir)
   return emitSyncPackages(siteDir, {
     resolveModel: makeModelResolver({ client: null, offline: true }),
     priorHashes,
     sendAll,
     ...applied,
-    ...(Object.keys(collectionUuids).length ? { collectionUuids } : {}),
+    ...(Object.keys(queryUuids).length ? { queryUuids } : {}),
     ...(Object.keys(assetIds).length ? { assetIds } : {}),
     ...(org ? { org } : {})
   })
@@ -1069,7 +1068,7 @@ export async function pushSyncPackages({
   asOrg,
   report
 }) {
-  const { siteContent, collections, siteContentUuid, hashes, applied } = pkg
+  const { siteContent, records, siteContentUuid, hashes, applied } = pkg
   const { info, note, error } = report
   const dim = report.dim || ((s) => s)
 
@@ -1272,8 +1271,8 @@ export async function pushSyncPackages({
         // The site's @uniweb/folder is genesis-owned: its structure is fixed on first
         // deploy and not reconciled in place (the v1 rule — see gotcha #20's mode switch).
         note(
-          "This site's collection structure is already established on the backend and can't be changed " +
-            'in place — e.g. adding or removing a schema-backed collection, or switching one between ' +
+          "This site's record structure is already established on the backend and can't be changed " +
+            'in place — e.g. adding or removing a schema-backed query, or switching one between ' +
             'static (data-bundle) and schema-backed delivery. To change it: delete the deployed site and ' +
             'redeploy, or clear `$uuid` in site.yml to deploy a fresh one.'
         )
@@ -1383,8 +1382,8 @@ export async function pushSyncPackages({
       // unique. Without it every push after the first re-sends the whole
       // `collections` section uuid-less and is refused.
       if (siteFinalizedDoc) {
-        const collectionIds = collectCollectionUuids(siteFinalizedDoc)
-        if (Object.keys(collectionIds).length) writeCollectionUuids(siteDir, collectionIds)
+        const recordIds = collectQueryUuids(siteFinalizedDoc)
+        if (Object.keys(recordIds).length) writeQueryUuids(siteDir, recordIds)
       }
       finalizedTotal += finalized.length
     } else {
@@ -1429,16 +1428,16 @@ export async function pushSyncPackages({
   // site-content uuid. On a brand-new site the backend creates the folder on this first
   // push. Records round-trip their own $uuid (back-filled into source files); the folder
   // itself has no uuid (the backend owns it).
-  if (collections) {
+  if (records) {
     if (!boundSiteUuid) {
       error(
-        'Cannot push collections — the site has no uuid yet. Push the site-content lane first.'
+        'Cannot push records — the site has no uuid yet. Push the site-content lane first.'
       )
       return { exitCode: 1, finalizedTotal, wrote }
     }
     const finalized = await pushLane(
-      'collections',
-      () => client.pushFolder(boundSiteUuid, collections.buffer, { asOrg }),
+      'records',
+      () => client.pushFolder(boundSiteUuid, records.buffer, { asOrg }),
       undefined,
       { boundUuid: boundSiteUuid }
     )
@@ -1447,7 +1446,7 @@ export async function pushSyncPackages({
       return { exitCode: 1, finalizedTotal, wrote }
     }
     harvest(finalized)
-    const bf = backfillEntityUuids({ index: collections.index, finalized })
+    const bf = backfillEntityUuids({ index: records.index, finalized })
     for (const w of bf.warnings) note(`! ${w}`)
     for (const d of bf.deferred) note(`↷ ${d.id ?? `#${d.index}`}: ${d.reason}`)
     if (bf.updated.length)