@uniweb/kit 0.19.16 → 0.19.18

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@uniweb/kit",
-  "version": "0.19.16",
+  "version": "0.19.18",
   "description": "Standard component library for Uniweb foundations",
   "type": "module",
   "exports": {
@@ -43,11 +43,11 @@
     "shiki": "^3.0.0",
     "tailwind-merge": "^3.6.0",
     "temml": "^0.13.2",
-    "@uniweb/core": "^0.37.0",
-    "@uniweb/schemas": "^0.11.0",
+    "@uniweb/core": "^0.37.2",
+    "@uniweb/semantic-parser": "^1.5.1",
     "@uniweb/scene": "^0.1.3",
-    "@uniweb/projections": "^0.7.14",
-    "@uniweb/semantic-parser": "^1.5.1"
+    "@uniweb/schemas": "^0.12.0",
+    "@uniweb/projections": "^0.7.14"
   },
   "peerDependencies": {
     "react": "^19.0.0",

package/src/utils/submitTarget.js

@@ -22,13 +22,12 @@ import { resolveService, resolveServiceUrl } from './services.js'
  * offers the path when something is actually there to catch it. Same bytes, and
  * only one of them is correct.
  *
- * ## Simulating a host locally
+ * ## `services:` in site.yml is not the host tier
  *
- * The bundle lane spreads all of site.yml into the payload config, so writing a
- * `services:` block in site.yml exercises the host tier end to end with no
- * framework change. It cannot leak into a real deployment: the sync lane is an
- * explicit allowlist and does not carry `services`, so a synced site's value can
- * only have come from its host.
+ * It is the owner's request to their host, and the build keeps it out of the
+ * payload, so a site's `config.services` can only have come from its host. *(Until
+ * 2026-10-06 a static build copied it there, and it doubled as a way to simulate a
+ * host's offer locally.)*
  */
 
 /**