@wix/himalaya-cli 0.1529.0 → 0.1530.0

package/guides/release-notes.md

@@ -14,6 +14,23 @@ areas, always in the same order, so you can skim for the one you care about.
 
 ---
 
+## 2026-11-01
+
+### Getting started & the CLI
+
+- `himi template screens`, `himi template inspect` and `himi template sweep` now work on a
+  template whose `dev/index.ts` is written by hand, not only on the generated `SCREENS` layout.
+  Before, all three refused every showcase and starter template (`banking-wallet`, `tip-calc`,
+  `weather`, …). `screens` and `inspect` read such a file by loading it the way `himi validate`
+  does, and their output says `"layout": "evaluated"`. `screens --show/--write/--add` and
+  `himi template trim` still need the generated layout. (#4985)
+- `himi template publish` now turns an app's own URL scheme (`himalaya-<app>`, in
+  `navigation.scheme` and in an auth `redirectUri`) into the scaffold's, so `himi init <name>
+  --template <t>` answers `himalaya-<name>` for a template published from a regular app too, as
+  it already did for the generated templates. The showcase and starter templates gave every
+  scaffold their own `himalaya-<t>` before. Apps scaffolded earlier keep the old value in
+  `config.ts` `navigation.scheme`. (#4985)
+
 ## 2026-10-22
 
 ### Getting started & the CLI

package/guides/templates.md

@@ -112,7 +112,7 @@ on the safe side ("may request"). The commands behind it:
 ```sh
 himi template recommend --text "a salon where clients book and buy products"   # rank the catalog (or --verticals / --book)
 himi template inspect                        # recompute the inventory after edits (--dry-run writes nothing)
-himi template screens                        # list dev/index.ts screens without reading the file
+himi template screens                        # list the screens and their workers (a hand-written dev/index.ts is evaluated)
 himi template screens --show himi_saved > saved.txt    # ONE screen's entry
 himi template screens --write himi_saved --from saved.txt   # put it back — re-parsed, refused if it breaks the file
 himi template screens --add himi_sellers --from sellers.txt --parent himi_branded_home   # a NEW screen, registered as linkable
@@ -127,6 +127,16 @@ descriptor it is an Icon id). A one-word literal elsewhere — a service name, a
 action id, a URL — is wiring, and is never rewritten. Every changed file is syntax-checked before
 anything is written.
 
+**Hand-written templates.** `inspect`, `screens` (the list) and `sweep` work on every template. A
+generated template's `dev/index.ts` is one `SCREENS` map, read without running anything. A
+hand-written one — the showcase apps, the starters, most apps published as templates — has no such
+map, so `inspect` and `screens` load `dev/index.ts` the way `himi validate` does, which runs its
+code, and build each screen to read its workers; the output says `"layout": "evaluated"`. `himi init`
+never does that, because a `--remote` template is its publisher's code: its adopt block is skipped
+for these, and `himi template inspect` is the next step. `screens --show/--write/--add` and `trim`
+rewrite the map's source text, so they still need the generated layout; edit a hand-written
+`dev/index.ts` directly.
+
 **Point a `branded-lite` (or vertical overlay) scaffold at your site.** Set
 `WIX_CLIENT_ID` (Headless OAuth client on that site) and `WIX_SITE_URL` before build /
 preview — the `clientId` **is** the site binding (no separate MSID field). Placeholders

package/guides/tier-5-add-a-screen.md

@@ -779,6 +779,10 @@ target is another tab's root screen does not select that tab — it pushes the s
 - An id the app is not showing right now — unknown, hidden by the nav worker, or any id when
   the app has no tab bar or sidebar rail (`single` / `drawer` navigation) — is ignored and
   logged as `nav_verb_dropped`. The user stays where they are.
+- A push identical to the one the router applied less than 500 ms before (same screen, same
+  params) is one push, logged as `nav_push_coalesced`: a worker that answers late answers every
+  tap it was given, and three taps on a busy main thread would otherwise land three screens
+  deep. Any other verb in between starts over, so push, back and the same push again all apply.
 - Asking for the tab the user is already on does nothing. It does **not** pop that tab to its
   root the way a second tap on the tab bar does — unless you ask for it with `reset: true`.
 - `reset: true` pops the selected tab to its root, even when it is the current tab. This is

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@wix/himalaya-cli",
-  "version": "0.1529.0",
+  "version": "0.1530.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": [
@@ -71,5 +71,5 @@
       "artifactId": "himalaya-cli"
     }
   },
-  "falconPackageHash": "28b98bdc9fc68f9be64914a2b88e5593f330b1f1f8e51dc6b49bba20"
+  "falconPackageHash": "f0490b6c81aec1fb5f5ecf75b8397ad986b6ccfe13b57fc83e2441ec"
 }