uniweb 0.66.0 → 0.67.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "uniweb",
-  "version": "0.66.0",
+  "version": "0.67.0",
   "description": "Create structured Vite + React sites with content/code separation",
   "type": "module",
   "bin": {
@@ -41,17 +41,17 @@
     "js-yaml": "^4.1.0",
     "prompts": "^2.4.2",
     "tar": "^7.0.0",
-    "@uniweb/kit": "^0.19.4",
-    "@uniweb/runtime": "^0.27.4",
     "@uniweb/content-writer": "^0.3.4",
-    "@uniweb/schemas": "^0.5.0",
     "@uniweb/core": "^0.29.8",
+    "@uniweb/kit": "^0.19.4",
+    "@uniweb/schemas": "^0.6.0",
+    "@uniweb/runtime": "^0.27.4",
     "@uniweb/semantic-parser": "^1.4.1"
   },
   "peerDependencies": {
+    "@uniweb/build": "^0.61.0",
     "@uniweb/content-reader": "^1.2.5",
-    "@uniweb/semantic-parser": "^1.4.1",
-    "@uniweb/build": "^0.60.0"
+    "@uniweb/semantic-parser": "^1.4.1"
   },
   "peerDependenciesMeta": {
     "@uniweb/build": {

package/partials/agents.md

@@ -1870,7 +1870,7 @@ fetch:
 
 **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`, `useWholeRecord`. They share the framework's cache and dispatcher with declarative fetches; same-key requests dedupe automatically.
 
-**Validate before shipping.** `uniweb validate` checks file-based data against your declared schemas — missing required fields, type/enum/format mismatches, nested fields. A violation fails it (`--lax` only reports); it checks every record file in `records/`, and `push` / `publish` refuse the same findings before sending anything. Distinct from `uniweb doctor` (project structure): `validate` checks your *data* against the schemas you *declared*. External queries (`url:`), `ref`/`options`, and rich `sections`-form inputs are reported deferred.
+**Validate before shipping.** `uniweb validate` checks file-based data against your declared schemas — missing required fields, type/enum/format mismatches, nested fields. A violation fails it (`--lax` only reports); it checks every record file in `records/`, and `push` / `publish` refuse the same findings before sending anything. Distinct from `uniweb doctor` (project structure): `validate` checks your *data* against the schemas you *declared*. External queries (`url:`) are reported as deferred — their data isn't in the project; the value of a `ref`/`options` field is not checked against the entity it names.
 
 ### Fetching from other sources (`fetcher:`)
 
@@ -2609,7 +2609,7 @@ Foundations have their own free path too: `uniweb add ci --target foundation` pu
 
 Either side can publish. Nothing about this changes how you build: the same foundation and the same site run under `uniweb dev`, `uniweb export`, or a CI deploy with no account at all.
 
-**Publishing vs registering.** Foundations on Uniweb Cloud live in the catalog as `@org/name@version` — `name` from the foundation's `main.js`. When a foundation powers a single site, **don't run `uniweb register` yourself** — `uniweb publish` from the site directory releases the local foundation to the catalog (when its code changed) and goes live in one step. A registered version is immutable, so when the foundation's code changed under a version already registered, `push` and `publish` release the change under the next version and write it into the foundation's `package.json` — commit that file (`--no-release` sends the content without the code). They stop when the registry holds a version newer than yours, released from another copy: pull that change first, or pass `--bump` to release yours above it. Register deliberately only when the foundation is a product meant for multiple sites; consuming sites then pin `foundation: '@org/name@1.2.3'`. **The catalog is private and access-segregated, not a public package registry** — people see only the foundations licensed to sites they own or edit. The *site* carries the license, and it rides along with site ownership when a developer hands a site to a client. Don't describe publishing as making a foundation publicly discoverable. Schemas can also be registered on their own from a schemas-only package (`@uniweb/schemas`, any `@org/schemas`, or a bare folder of `schemas/*.{yml,json,js}`) — that's how `@std` schemas are published. Auth via `uniweb login` (`uniweb login --backend <url> --token <bearer>` without a terminal) or `UNIWEB_TOKEN`; preview with `--dry-run`.
+**Publishing vs registering.** Foundations on Uniweb Cloud live in the catalog as `@org/name@version` — `name` from the foundation's `main.js`. When a foundation powers a single site, **don't run `uniweb register` yourself** — `uniweb publish` from the site directory releases the local foundation to the catalog (when its code changed) and goes live in one step. A registered version is immutable, so when the foundation's code changed under a version already registered, `push` and `publish` release the change under the next version and write it into the foundation's `package.json` — commit that file (`--no-release` sends the content without the code). The version it picks is always the next patch: for a change that is not backwards compatible, set a higher minor or major version in the foundation's `package.json` yourself before you push. They stop when the registry holds a version newer than yours, released from another copy: pull that change first, or pass `--bump` to release yours above it. Register deliberately only when the foundation is a product meant for multiple sites; consuming sites then pin `foundation: '@org/name@1.2.3'`. **The catalog is private and access-segregated, not a public package registry** — people see only the foundations licensed to sites they own or edit. The *site* carries the license, and it rides along with site ownership when a developer hands a site to a client. Don't describe publishing as making a foundation publicly discoverable. Schemas can also be registered on their own from a schemas-only package (`@uniweb/schemas`, any `@org/schemas`, or a bare folder of `schemas/*.{yml,json,js}`) — that's how `@std` schemas are published. Auth via `uniweb login` (`uniweb login --backend <url> --token <bearer>` without a terminal) or `UNIWEB_TOKEN`; preview with `--dry-run`.
 
 ### Staying current
 

package/src/backend/foundation-bring-along.js

@@ -20,9 +20,10 @@
  * above the registered one, written into the package's `package.json` first. ⛔ This
  * reverses the version-bump release gate of 2026-06-23, whose reasoning — a deliberate,
  * npm-style release — fits a foundation other sites use as a product; those sites pin
- * a catalog ref and never reach this code. (A library's own demo site, which names it
- * by path, does — whether such a foundation should declare its releases deliberate is
- * open.)
+ * a catalog ref and never reach this code. Its author's demo site, which names it by
+ * path, does — and gets the same default, by ruling [Diego, 2026-09-24]. The release is
+ * always the next patch, so a change that is not backwards compatible needs a higher
+ * version set in `package.json` by hand.
  *
  * ⛔ **A NEWER registered version still stops it.** It was released from another copy
  * of the project, whose code this one may not have, and releasing above it would make

package/src/commands/validate.js

@@ -12,9 +12,10 @@
  * ⭐ A violation fails it (exit 1); `--lax` reports without failing. It warned by
  * default until 2026-09-24, with `--strict` to fail — a gate that passes is one
  * nobody reads, and `push` / `publish` now refuse the same findings. The live render
- * path stays tolerant. Dynamic (remote) inputs and entity references can't be
- * resolved without a running backend, so they're reported as deferred, never
- * silently skipped.
+ * path stays tolerant. Remote (`url:`) inputs are not in the project, so they're
+ * reported as deferred, never silently skipped. The value of an entity reference is
+ * not checked against the entity it names. ⛔ This said references were "reported as
+ * deferred" until 2026-09-24; no check ever reported them.
  */
 
 import { existsSync, readFileSync } from 'node:fs'
@@ -171,7 +172,7 @@ function printSiteHuman(result) {
   }
 
   if (deferred.length > 0) {
-    log(`  ${colors.dim}↪ deferred (not statically checkable):${colors.reset}`)
+    log(`  ${colors.dim}↪ deferred (not checked):${colors.reset}`)
     for (const d of deferred) {
       const extra = d.url
         ? ` ${colors.dim}(${d.url})${colors.reset}`

package/src/framework-index.json

@@ -1,6 +1,6 @@
 {
   "schemaVersion": 1,
-  "generatedAt": "2026-09-24T15:29:04.711Z",
+  "generatedAt": "2026-09-24T19:00:27.393Z",
   "packages": {
     "@uniweb/api": {
       "version": "0.6.1",
@@ -10,7 +10,7 @@
       ]
     },
     "@uniweb/build": {
-      "version": "0.60.0",
+      "version": "0.61.0",
       "path": "framework/build",
       "deps": [
         "@uniweb/content-reader",
@@ -96,7 +96,7 @@
       "deps": []
     },
     "@uniweb/schemas": {
-      "version": "0.5.0",
+      "version": "0.6.0",
       "path": "framework/schemas",
       "deps": []
     },
@@ -126,7 +126,7 @@
       "deps": []
     },
     "@uniweb/unipress": {
-      "version": "0.10.3",
+      "version": "0.10.4",
       "path": "framework/unipress",
       "deps": [
         "@uniweb/build",

package/src/index.js

@@ -1697,9 +1697,9 @@ project against framework conventions.
 
 Every record file is checked against the schema its folder names, whether or
 not a section reads it. A violation fails the run; \`push\` and \`publish\` refuse
-the same findings. The live render path stays tolerant. Dynamic (\`url:\`)
-inputs and entity references can't be resolved without a running backend, so
-they're reported as deferred, never silently skipped.
+the same findings. The live render path stays tolerant. Remote (\`url:\`)
+inputs are not in the project, so they're reported as deferred, never silently
+skipped. A reference field's value is not checked against the entity it names.
 
 ${colors.bright}Options:${colors.reset}
   --lax              Report violations without failing (exit 0)