@wix/himalaya-cli 0.969.0 → 0.970.0

package/dist/cli.mjs

@@ -18715,7 +18715,6 @@ function shouldRevealError(args) {
 var EMAIL_RE, URL_HOST_RE, INTEGER_RE, NUMBER_RE;
 var init_validation = __esm({
   "../../core/ts/src/validation.ts"() {
-    "use strict";
     EMAIL_RE = /^[A-Za-z0-9._%+-]+@[A-Za-z0-9-]+(\.[A-Za-z0-9-]+)*\.[A-Za-z]{2,}$/;
     URL_HOST_RE = /^[A-Za-z0-9-]+(\.[A-Za-z0-9-]+)*(:[0-9]+)?$/;
     INTEGER_RE = /^[+-]?[0-9]+$/;
@@ -22140,7 +22139,6 @@ function validateWorkerSubtree(raw, slotId, policy, actionCatalog) {
 var WORKER_SUBTREE_CEILINGS, ID_PART, ACTION_ID;
 var init_worker_subtree = __esm({
   "../../core/ts/src/worker-subtree.ts"() {
-    "use strict";
     init_worker_subtree_safe_types_generated();
     WORKER_SUBTREE_CEILINGS = Object.freeze({
       maxEncodedBytes: 65536,

package/guides/wix-business-context.md

@@ -137,6 +137,16 @@ The plane has no headless browser (`look.unavailable: no_browser_on_plane`). Own
 
 `--apply` writes `appearance.homeLayout` + `navigation.navKind` plus identity/colors. It never silently overwrites committed Amit1 `apps/himi-branded-lite/provisioning.json`.
 
+When the analysis recognized at least one vertical, `--apply` also patches the shell's baked home
+(`dev/index.ts`) to what the site actually runs. The Explore grid keeps only the site's
+destinations (adding a card the template baked none for, and leaving off a vertical the template
+ships no screen for); home modules that no installed vertical can fill are dropped; and a site
+without `store` loses the home's Shop calls to action, including the one nested in the
+`retail-store` store-first layout. The store screens themselves are untouched — only the home
+stops linking to them. The apply notes name every removed call to action and every installed
+vertical left off Explore, so an intentional omission is distinguishable from a failed patch. An
+analysis with no recognized vertical leaves the home exactly as shipped.
+
 It also writes **`cmsCollections`** — the customer's own CMS collections, always present and possibly `[]`. The overlay used to carry no such key, and an absent key inherits the shell's, so an applied app advertised and **queried** the shell's demo collection: another tenant's data model under the customer's brand. `[]` is therefore a value, not an absence — it clears the shell's list and the CMS screen shows its own empty state.
 
 Only a collection a shipped app can read **as a visitor** is carried, because `readCms` lists with an **owner** token and the app has no such session. An `ADMIN` read is dropped (no session the app can hold will ever satisfy it), and so is a **member-gated** one — not because the app cannot read it, but because the CMS worker caches fetched rows in the unencrypted `cms_items` store, which outlives the member's session and would be served to the next visitor on the device ([cms-collections.md](cms-collections.md)). A Wix app's own collection (`ownerAppId`) is dropped too; its vertical already renders it. So are the four other ways a collection misses the app, because they need different remedies and are indistinguishable in the artifact: **no owner token** (nothing was looked at), the listing **failing** (any status but 404 — re-authenticate, widen the Wix Data grant, or retry a 429; a 404 means the app is not on the site, which is simply "no collections"), the listing **cap** of 24 counted against the server's `pagingMetadata.total` (the rest were never read), and an **id that cannot be carried unchanged** (surrounded by whitespace, carrying a control character, or over 256 chars — normalizing it would name a different collection in a manifest that still loads). A site that simply has none says nothing — that is the ordinary state, and `--apply` leads its note with warnings.

package/guides/wix-site-to-himi-app.md

@@ -167,11 +167,14 @@ book says which happened on the `cms collections:` line (`(skipped: no owner tok
 The `clientId`-is-the-binding rule above is about the **app's** runtime site binding, not this.
 
 `--apply` writes `provisioning.json` + token **values**, and patches the branded-lite
-home `onAppear` params (`ownerDefaultLayout`, `brandAccent`, `verticals`) in
-`dev/index.ts`. It does **not** rewrite `config.ts` tabBar — you still set 2–4
-Hebrew/RTL tabs to the site's jobs. If home still renders the English Shop/Book/Explore
-hub after `--apply`, the onAppear patch missed (no `dev/index.ts`, or a custom home
-screen) — set `ownerDefaultLayout` by hand.
+home in `dev/index.ts`: its `onAppear` params (`ownerDefaultLayout`, `brandAccent`,
+`verticals`) and, when the analysis recognized any vertical, the Explore grid, the home
+modules and — on a site without `store` — the Shop calls to action, naming what it
+removed in its notes (`himi docs wix-business-context`). It does **not** rewrite
+`config.ts` tabBar — you still set 2–4 Hebrew/RTL tabs to the site's jobs. If home still
+renders the English Shop/Book/Explore hub after `--apply`, the home patch missed (no
+`dev/index.ts`, a custom home screen, or an analysis with no recognized vertical) — set
+`ownerDefaultLayout` and the home content by hand.
 
 **Look:** merge `--wst-*` into `tokens.json` **values only** (`himi docs tokens`), and only into
 the **light** arm — a scraped website colour is never a dark-mode colour, so let the app's own

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@wix/himalaya-cli",
-  "version": "0.969.0",
+  "version": "0.970.0",
   "type": "module",
   "description": "himi — the Himalaya authoring CLI. Build a Tier-5 content package on your own machine, push it to the production serve as a draft, preview it on web + Himi Player, and read worker logs back — the remote dev loop. Wraps @himalaya/serve-cli for transport.",
   "keywords": [
@@ -64,5 +64,5 @@
       "artifactId": "himalaya-cli"
     }
   },
-  "falconPackageHash": "5fbb2ba85ad9db892370efbcc59a8ef6629609514feb06522e4ea1f2"
+  "falconPackageHash": "09b972a7f7d83ae250b4039472411e77995eaddf0767c4c09bc73558"
 }