@wix/himalaya-cli 0.997.0 → 0.998.0

package/guides/headless-loop.md

@@ -198,6 +198,16 @@ with `himi ux record --content . --platform ios|android --status passed|failed|u
 actually drove; an unavailable platform drove nothing, so it takes no checks and needs its reason
 recorded, not guessed.
 
+**Record last, right before you push.** A UX record is bound to the exact release content it was
+taken against, and `himi push` refuses a draft whose record describes different content — so
+any edit after recording (a screen, a token, a worker) means recording again. And that only works
+if the build is reproducible: **a worker's initial state must be deterministic.** The build boots
+each worker and hashes its initial state into the release, so a `defineService` state computed
+from `Date.now()`, `new Date()` or `Math.random()` makes every build of unchanged source a
+different release, and no record can ever match the push. `himi validate` warns about it
+(`initial-state`, naming the worker and service); fix it by computing those values in an action
+— for example one the screen's `onAppear` dispatches — instead of in the initial state.
+
 Report v2 sharpens all of it: a worker throw carries `in tier5-src/<screen>/index.ts:<line>`
 (mapped through the bundle's sourcemap — fix it without grepping), the ledger lists worker
 functions **no axis ever executed** with their source lines (usually the error branch you

package/guides/mobile-ux.md

@@ -137,6 +137,15 @@ driving a native shell, record the result—not an assumption—with `himi ux re
 is required for `passed`/`failed` and names what you actually drove; an unavailable platform drove
 nothing, so it takes no checks and needs a `--reason` instead.
 
+Record last, immediately before `himi push`. The record is bound to the exact release content it
+was taken against, and the push refuses a draft whose record describes different content, so any
+edit after recording means recording again. That only works when the build is reproducible, so
+**a worker's boot-time initial state must be deterministic**: the build hashes each worker's
+initial state into the release, and a `defineService` state computed from `Date.now()`,
+`new Date()` or `Math.random()` makes every build of unchanged source a different release that no
+record can match. `himi validate` names such a worker as an `initial-state` warning. Compute those
+values in an action (for example one the screen's `onAppear` dispatches) instead.
+
 `himi render --width`/`--device` writes into the same `.himi/ux-audit.json`, appending the width it
 rendered. That is what the width marker below reads first, so rendering the screen at two widths is
 itself the evidence — see the strict audit contract.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@wix/himalaya-cli",
-  "version": "0.997.0",
+  "version": "0.998.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": "1da0e386b23642ce946cc95fbb56bb7988c6100b680fe7dbaf954a99"
+  "falconPackageHash": "5ebc9c2a8de3fd169d9b17811f10f0d83ae07430d18ea0c242214539"
 }