uniweb 0.49.0 → 0.51.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "uniweb",
-  "version": "0.49.0",
+  "version": "0.51.0",
   "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.25.0",
-    "@uniweb/kit": "^0.18.3",
+    "@uniweb/core": "^0.26.1",
+    "@uniweb/kit": "^0.18.4",
     "@uniweb/semantic-parser": "^1.4.0",
-    "@uniweb/runtime": "^0.20.0"
+    "@uniweb/runtime": "^0.20.3"
   },
   "peerDependencies": {
-    "@uniweb/build": "^0.45.0",
     "@uniweb/content-reader": "^1.2.4",
-    "@uniweb/semantic-parser": "^1.4.0"
+    "@uniweb/semantic-parser": "^1.4.0",
+    "@uniweb/build": "^0.47.0"
   },
   "peerDependenciesMeta": {
     "@uniweb/build": {

package/partials/agents.md

@@ -697,7 +697,7 @@ What can actually *read* it depends on where you deploy, because reading it need
 
 The artifacts **your build emits** to describe the public site never name them — `llms.txt`, the per-page `.md` projections, and the search index all describe pages a visitor reads, and a knowledge page's prose was written for the assistant instead. Two settings **outrank** `knowledge:`, so a contradiction resolves toward the narrower reach: `agents.exclude` in `site.yml`, and any `_`-prefixed route segment. *(A host that derives these artifacts itself, rather than serving the ones your build produced, applies its own rules — ask your host what it does with `knowledge:` before relying on it there.)*
 
-Don't confuse it with the visibility flags: `hidden: true` is a **draft** (not published at all), `hideIn` only controls **nav placement** (still reachable by URL), and `knowledge: true` is a **different audience** (never rendered for anyone).
+Don't confuse it with the visibility flags: `hidden: true` is a **draft** (not published at all), `hideIn` only controls **nav placement** (still reachable by URL), and `knowledge: true` is a **different audience** (never rendered for anyone). ⛔ `hidden: true` on `pages/404/` means a **draft 404** — it is not published and the site falls back to the generic `404.html`; an authored 404 needs no flag, since it is never listed in navigation anyway.
 
 **A site can be nothing but knowledge — that is a real and useful shape.** A site is a set of routes; it does not have to have HTML pages. Mark the root `knowledge: true` and every page inherits it, so the site renders nothing at all and exists to *be* an agent: a `/_agent/chat` URL that a web app, a mobile app, or someone else's backend sends requests to.
 
@@ -874,12 +874,12 @@ team:
 
 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). A list — `data: [team, articles]` — declares several, each arriving under its own `content.data` key:
+**Show a query on a page** with `query:` in `page.yml` or a section's frontmatter (the whole result), or `fetch:` for anything more — a `limit`, a `where`. A list — `query: [team, articles]` — declares several, each arriving under its own `content.data` key. `query:` takes names only; `data:`, its old name, is now an error.
 
 ```yaml
 # pages/blog/page.yml          |   # a section on the homepage
 title: Blog                    |   ---
-data: recent                   |   type: ArticleTeaser
+query: recent                  |   type: ArticleTeaser
                                |   fetch: { query: recent, limit: 3 }
                                |   ---
 ```
@@ -888,7 +888,7 @@ data: recent                   |   type: ArticleTeaser
 
 ```
 pages/blog/
-├── page.yml          # title: Blog / data: recent
+├── page.yml          # title: Blog / query: recent
 ├── list.md
 └── [slug]/
     ├── page.yml
@@ -897,7 +897,7 @@ pages/blog/
 
 `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.
 
-**Which query the URL narrows — the page's route query:** the `[slug]` page's own `data:`, else its parent page's (the usual shape, above), else `site.yml`'s; if none declares one, the query its sections all declare. The first query of that level wins. Every section the route query reaches gets the one record; a section declaring a *different* query of its own gets that query as declared. The folder name says what the URL segment matches: `[slug]` the record's handle (`$name`, which compiled records carry — equal to their `slug`), `[uuid]` its `$uuid`, any other `[name]` the record's own field of that name. A folder inside `[slug]/` (`[slug]/cv/` → `/blog/:slug/cv`) is a parametric page too, reading the record when `[slug]/page.yml` declares the query. `[dir]` and `[path]` are refused as folder names, and so is any folder inside `[...path]/`.
+**Which query the URL narrows — the page's route query:** the `[slug]` page's own `query:`, else its parent page's (the usual shape, above), else `site.yml`'s; if none declares one, the query its sections all declare. The first query of that level wins. Every section the route query reaches gets the one record; a section declaring a *different* query of its own gets that query as declared. The folder name says what the URL segment matches: `[slug]` the record's handle (`$name`, which compiled records carry — equal to their `slug`), `[uuid]` its `$uuid`, any other `[name]` the record's own field of that name — and when that field holds several values, **any member** matches (the record's own link is its first value). Routing by a field that is not unique picks one record and which one is not guaranteed; the build warns. A folder inside `[slug]/` (`[slug]/cv/` → `/blog/:slug/cv`) is a parametric page too, reading the record when `[slug]/page.yml` declares the query. `[dir]` and `[path]` are refused as folder names, and so is any folder inside `[...path]/`.
 
 > **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.
 
@@ -977,7 +977,7 @@ function MyComponent({ content, params, block }) {
 }
 ```
 
-Frontmatter becomes `params`, minus the keys the framework consumes outright: `type`, `preset`, `input`, `props`, `fetch`, `data`, `id`. `props:` is the one that isn't dropped but merged *into* params.
+Frontmatter becomes `params`, minus the keys the framework consumes outright: `type`, `preset`, `input`, `props`, `query`, `fetch`, `id` (a `data:` key is refused — it was `query:`'s old name). `props:` is the one that isn't dropped but merged *into* params.
 
 **Framework fields you'd expect to be stripped are not.** `background`, `theme`, `source`, `where`, and `vars` are acted on by the runtime *and* passed through — so `params.theme` is readable when a component needs logic beyond CSS tokens (a light vs. dark logo, say). Components ignore the keys they don't use, the same way they ignore unused `content.data` keys.
 
@@ -1608,7 +1608,7 @@ export default function Grid({ block, params }) {
 
 Each child is a regular section with its own type, params, and content — and you're in the middle: wrap each child, filter by type, reorder, add container classes. The author decides *what* goes in the grid; your component decides *how* it renders. Tomorrow the author can swap a child for a different section type with no code change, and your components stay reusable wherever child sections are accepted.
 
-**Data and child blocks:** page-level `data:` is available to all blocks including children, and each child resolves data independently through the page → site hierarchy. If a child needs data, declare it in the child's `meta.js` or its frontmatter (`data: articles`).
+**Data and child blocks:** page-level `query:` (or `fetch:`) is available to all blocks including children, and each child resolves data independently through the page → site hierarchy. If a child needs data no ancestor declares, give it its own in its frontmatter (`query: articles`, or `fetch:`). Its `meta.js` `data:` declares the shape it reads, never where the data comes from — it fetches nothing.
 
 **SSG:** insets, `<ChildBlocks>`, and `<Visual>` all render correctly during prerender. Inset components using React hooks internally trigger prerender warnings — expected and harmless; the page renders correctly client-side.
 
@@ -1773,7 +1773,7 @@ Content-less containers appear as group nodes (`hasContent: false`) — use `nav
 
 ### Data
 
-A component on a page with a `data:` or `fetch:` declaration automatically receives that data in `content.data.{key}` — no opt-in in `meta.js`.
+A component on a page with a `query:` or `fetch:` declaration automatically receives that data in `content.data.{key}` — no opt-in in `meta.js`.
 
 **Bound collections always arrive as arrays.** On a list page, `content.data.articles` is the full collection. On a parametric page (`[slug]/`), the matched record is delivered under the *same* key as a single-element array — the detail section reads `content.data.articles[0]`. When nothing matches, the key is `[]`. The runtime never coerces to a single object and never synthesizes a singular key.
 
@@ -1831,7 +1831,7 @@ A backend with its own base URL, headers, wire or query language is a **transpor
 # site.yml
 fetcher:
   transports:
-    articles: acme                   # a foundation-registered transport handles `data: articles`
+    articles: acme                   # a foundation-registered transport handles `query: articles`
     events: default                  # explicitly route back to the default fetcher
   acme:                              # binding config that transport reads
     apiKey: pk_public_123

package/src/commands/publish.js

@@ -772,12 +772,12 @@ export async function publish(args = []) {
   // released version on the wire is required when site.yml uses an unversioned
   // local ref; injectInfo overrides info.foundation. A registry/URL ref → fnd.ref
   // is null → the site.yml ref is forwarded verbatim (already pinned).
-  // ⛔ DO NOT STAMP `info.data` HERE. The name is TAKEN: `uwx/site.js` already
-  // emits `info.data` from `site.yml`'s top-level `data:`/`fetch:` block, and
-  // `injectInfo` WINS the merge (`sync-package.js`: `{...siteDoc.info,
-  // ...injectInfo}`), so stamping a file map here silently replaces the author's
-  // fetch config on the wire. Both are `type: json`, so the store validator
-  // accepts either and nothing errors at any layer.
+  // ⛔ DO NOT STAMP A FILE MAP INTO `info` HERE. `injectInfo` WINS the merge
+  // (`sync-package.js`: `{...siteDoc.info, ...injectInfo}`), so any name stamped
+  // here silently replaces what the author's document carries under it, and the
+  // store validator accepts it — nothing errors at any layer. This was written
+  // about `info.data`, which carried the site's `fetch:` block until 2026-09-09;
+  // that moved to `settings.fetch`, and the warning holds for any name.
   //
   // A file map needs a name nothing else claims (`static_data` / `data_files`
   // were proposed) AND a consumer that reads it — neither settled. See

package/src/framework-index.json

@@ -1,16 +1,16 @@
 {
   "schemaVersion": 1,
-  "generatedAt": "2026-09-11T18:41:11.718Z",
+  "generatedAt": "2026-09-12T17:05:58.363Z",
   "packages": {
     "@uniweb/api": {
-      "version": "0.3.2",
+      "version": "0.3.3",
       "path": "framework/api",
       "deps": [
         "@uniweb/core"
       ]
     },
     "@uniweb/build": {
-      "version": "0.45.0",
+      "version": "0.47.0",
       "path": "framework/build",
       "deps": [
         "@uniweb/content-reader",
@@ -34,7 +34,7 @@
       "deps": []
     },
     "@uniweb/core": {
-      "version": "0.25.0",
+      "version": "0.26.1",
       "path": "framework/core",
       "deps": [
         "@uniweb/semantic-parser",
@@ -47,14 +47,14 @@
       "deps": []
     },
     "@uniweb/icons": {
-      "version": "0.4.16",
+      "version": "0.4.17",
       "path": "framework/icons",
       "deps": [
         "@uniweb/core"
       ]
     },
     "@uniweb/kit": {
-      "version": "0.18.3",
+      "version": "0.18.4",
       "path": "framework/kit",
       "deps": [
         "@uniweb/core",
@@ -74,7 +74,7 @@
       "deps": []
     },
     "@uniweb/projections": {
-      "version": "0.6.1",
+      "version": "0.6.2",
       "path": "framework/projections",
       "deps": [
         "@uniweb/content-writer",
@@ -82,7 +82,7 @@
       ]
     },
     "@uniweb/runtime": {
-      "version": "0.20.0",
+      "version": "0.20.3",
       "path": "framework/runtime",
       "deps": [
         "@uniweb/core",
@@ -110,7 +110,7 @@
       "deps": []
     },
     "@uniweb/templates": {
-      "version": "0.12.5",
+      "version": "0.13.0",
       "path": "framework/templates",
       "deps": []
     },
@@ -120,7 +120,7 @@
       "deps": []
     },
     "@uniweb/unipress": {
-      "version": "0.9.12",
+      "version": "0.9.14",
       "path": "framework/unipress",
       "deps": [
         "@uniweb/build",

package/templates/site/site.yml.hbs

@@ -49,8 +49,8 @@ index: home
 #                              sort: date desc
 #                              limit: 10
 #
-# Pages and sections then name a query: `data: recent`, or
-# `fetch: { query: recent }`.
+# Pages and sections then name a query: `query: recent`, or
+# `fetch: { query: recent, limit: 3 }` for anything more.
 #
 # You can also keep queries here instead of in queries.yml:
 #
@@ -61,7 +61,7 @@ index: home
 #
 # fetch:
 #   - url: https://api.example.com/team  # Remote JSON
-#     schema: team                       # Access as content.data.team
+#     as: team                           # Access as content.data.team
 #   - path: /data/config.json            # Local file from public/
 
 # ─── Extensions ────────────────────────────────────────────────────────────────