uniweb 0.48.6 → 0.50.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "uniweb",
-  "version": "0.48.6",
+  "version": "0.50.0",
   "description": "Create structured Vite + React sites with content/code separation",
   "type": "module",
   "bin": {
@@ -41,13 +41,13 @@
     "js-yaml": "^4.1.0",
     "prompts": "^2.4.2",
     "tar": "^7.0.0",
-    "@uniweb/core": "^0.24.4",
-    "@uniweb/kit": "^0.18.2",
+    "@uniweb/core": "^0.25.1",
+    "@uniweb/kit": "^0.18.3",
     "@uniweb/semantic-parser": "^1.4.0",
-    "@uniweb/runtime": "^0.19.5"
+    "@uniweb/runtime": "^0.20.1"
   },
   "peerDependencies": {
-    "@uniweb/build": "^0.44.5",
+    "@uniweb/build": "^0.46.0",
     "@uniweb/content-reader": "^1.2.4",
     "@uniweb/semantic-parser": "^1.4.0"
   },

package/partials/agents.md

@@ -857,7 +857,7 @@ A bare string is a path under `entities/`, naming one file or matching many.
     - 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.
+A query reads one branch with `scope: archive` — the folder and everything inside it (the older `where: { path: { under: … } }` is refused by the build). 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:
 
@@ -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,9 +897,11 @@ 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 `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. 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.
 
-**Records with URLs of their own shape — `[...path]/`.** A folder named exactly `[...path]` (one fixed spelling) captures the rest of the URL: `/blog/my-post` and `/blog/rust/2025/my-post` both reach it. The capture yields three standard variables — `:path` (the whole capture), `:dir` (everything before the last segment), `:slug` (the last segment, the record's handle) — and the record is still delivered by `slug`, so the section reads `content.data.recent[0]` as before. A record's URL is its folder placement plus its slug (`- folder: rust/2025` in `records.yml` → `/blog/rust/2025/my-post`). A query may bind a part — `scope: :dir` exposes the folder branch, `where: { tag: :dir }` keeps it private — and an unbound variable drops its clause, so one saved query serves the list page and the detail page. Reference: `reference/dynamic-routes.md`.
+**Records with URLs of their own shape — `[...path]/`.** A folder named exactly `[...path]` (one fixed spelling) captures the rest of the URL: `/blog/my-post` and `/blog/rust/2025/my-post` both reach it. The capture yields three standard variables — `:path` (the whole capture), `:dir` (everything before the last segment), `:slug` (the last segment, the record's handle) — and the record is still delivered by its handle, so the section reads `content.data.recent[0]` as before. The same three variables exist under every parametric page: under `[slug]`, `:slug` and `:path` are the segment and `:dir` is empty. A record's URL is its folder placement plus its slug (`- folder: rust/2025` in `records.yml` → `/blog/rust/2025/my-post`). A query may bind a part — `scope: :dir` exposes the folder branch, `where: { tag: :dir }` keeps it private — and an unbound or empty variable drops its clause, so one saved query serves the list page and the parametric page, on a static site and a hosted one alike. Without `scope: :dir` the directory is decoration: the record is found by its handle wherever it sits. Reference: `reference/dynamic-routes.md`.
 
 **Two options for bigger sets:**
 
@@ -975,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.
 
@@ -1606,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.
 
@@ -1771,9 +1773,9 @@ 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 template 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.
+**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.
 
 ```jsx
 function Article({ content, block }) {
@@ -1829,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-10T23:52:15.147Z",
+  "generatedAt": "2026-09-11T23:04:50.071Z",
   "packages": {
     "@uniweb/api": {
-      "version": "0.3.1",
+      "version": "0.3.2",
       "path": "framework/api",
       "deps": [
         "@uniweb/core"
       ]
     },
     "@uniweb/build": {
-      "version": "0.44.5",
+      "version": "0.46.0",
       "path": "framework/build",
       "deps": [
         "@uniweb/content-reader",
@@ -34,7 +34,7 @@
       "deps": []
     },
     "@uniweb/core": {
-      "version": "0.24.4",
+      "version": "0.25.1",
       "path": "framework/core",
       "deps": [
         "@uniweb/semantic-parser",
@@ -47,14 +47,14 @@
       "deps": []
     },
     "@uniweb/icons": {
-      "version": "0.4.15",
+      "version": "0.4.16",
       "path": "framework/icons",
       "deps": [
         "@uniweb/core"
       ]
     },
     "@uniweb/kit": {
-      "version": "0.18.2",
+      "version": "0.18.3",
       "path": "framework/kit",
       "deps": [
         "@uniweb/core",
@@ -74,7 +74,7 @@
       "deps": []
     },
     "@uniweb/projections": {
-      "version": "0.6.0",
+      "version": "0.6.1",
       "path": "framework/projections",
       "deps": [
         "@uniweb/content-writer",
@@ -82,7 +82,7 @@
       ]
     },
     "@uniweb/runtime": {
-      "version": "0.19.5",
+      "version": "0.20.1",
       "path": "framework/runtime",
       "deps": [
         "@uniweb/core",
@@ -120,7 +120,7 @@
       "deps": []
     },
     "@uniweb/unipress": {
-      "version": "0.9.12",
+      "version": "0.9.13",
       "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 ────────────────────────────────────────────────────────────────