@wix/himalaya-cli 0.1032.0 → 0.1033.0

package/guides/getting-started.md

@@ -111,8 +111,12 @@ authenticated owner preview. The interactive `himi preview` URLs exist for a **d
 web host and call it owner-private, and do not let a template worker boot there until its startup
 network paths are authorized and preflighted.
 
-**Adopt, don't just rename, a template.** `himi init --template` seeds `SPEC.md` and
-`MOBILE-UX.md`; replace their boilerplate with the actual customer, data/auth assumptions,
+**Adopt, don't just rename, a template.** The approved `SPEC.md` and `MOBILE-UX.md` are the
+plan, and the plan wins over anything `himi init` seeds. `init` seeds placeholder copies of
+both and can overwrite plan files already in the package root, so keep a copy of the approved
+plan until `init` has run. After `init`, open both files:
+if either holds `init`'s boilerplate rather than the approved plan, put the approved plan back in
+its place — never the reverse — and finish it with the actual customer, data/auth assumptions,
 placeholder copy, flow/state matrix, and compact/phone/expanded + device evidence before calling
 the app ready. Keep scenario switches out of customer UI. A labelled preview fallback is acceptable
 only when the host cannot perform the task and it cannot write customer data.

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

@@ -208,9 +208,17 @@ images stay as `static.wixstatic.com` URLs in descriptors — do not vendor
 himi validate
 himi render <home-screen> --live --png    # live visitor data; no VPN
 himi test --content . --json              # wrong-reducer class; no test files
-himi push && himi promote                 # VPN + `himi login --dpx --target bo`
+himi login --browser --target wix         # your own Wix account; no VPN
+himi push                                 # a DRAFT by default; prints the exact promote command
+himi promote --app <app> --release <id> --target wix   # the one push printed; name the target
 ```
 
+Self-serve is the default: `himi login --browser --target wix` signs in with the customer's own
+Wix account and stores a scoped token, so `push` / `promote` need no VPN and no pasted secret
+(`--wix` reuses the machine's Wix CLI credential, for a container with no browser). Wix
+employees can sign in with `himi login --dpx` instead and then use `--target bo`, the in-house
+alternative that does need the corporate network.
+
 Published `@wix/himalaya-cli@0.207.0` has `validate`/`render` but **no** `himi test`
 (or `himi site`). Use a newer CLI, or the in-repo CLI from a Himalaya checkout
 (`node --import tsx tools/himi-cli/src/cli.ts`, cwd = the checkout so `tsx` resolves).

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@wix/himalaya-cli",
-  "version": "0.1032.0",
+  "version": "0.1033.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": [
@@ -65,5 +65,5 @@
       "artifactId": "himalaya-cli"
     }
   },
-  "falconPackageHash": "5af127baf2b3845fd3e463154eecf88bb68a58849427ab3778d5627a"
+  "falconPackageHash": "7837bf39e796e96ea058ad8a53b90966687ce65908583051a94208a3"
 }