@wix/himalaya-cli 0.1626.0 → 0.1627.0

package/dist/cli.mjs

@@ -29474,6 +29474,7 @@ function resolveIdiom(tokens2, ctx = {}) {
 var IDIOM_CONTEXTS, UNSAFE_KEYS;
 var init_idiom = __esm({
   "../../core/ts/src/idiom.ts"() {
+    "use strict";
     init_define_HHP_CATALOG();
     IDIOM_CONTEXTS = {
       ios: { native: ["ios"] },

package/guides/qa-builds.md

@@ -1260,10 +1260,14 @@ himi dist --app <app> --platform android --aab --wait --target bo
   can make one (`appStoreBuild` in the signing marker), `CheckIfBuildIsAllowed` finds a
   saved bundle id and an eligible plan (so an ineligible site never reaches Apple), then
   `PrepareAppleCertificates` registers the bundle id in the owner's Apple account and answers the
-  certificate, profile and key, and only then `ValidateStoreBuild` locks the bundle id (so a bundle id
-  Apple refuses can still change), and only while it is still the prepared one (`expected_store_id`:
-  a bundle id saved in between is refused and stays changeable). The owner must already have the app
-  in App Store Connect under that bundle id. The files
+  certificate, profile and key, and only then `CreateBuildRecordIfAllowed` locks the bundle id (so a
+  bundle id Apple refuses can still change), and only while it is still the prepared one
+  (`expected_store_id`: a bundle id saved in between is refused and stays changeable). That call also
+  opens Wix's record of the build, as for a bundle: the job id is reported at dispatch, and the build's
+  end once its upload settles (`UPLOADED` is the success, reported with the IPA; an upload `FAILED`
+  for good is the failure, with its `error`; a build that fails or is canceled on the pool is
+  reported so). A built IPA waiting for its upload reports nothing yet. The owner must already have
+  the app in App Store Connect under that bundle id. The files
   and the key are never stored: the pool and the upload each fetch them again, the job keeps only
   their hashes. The upload starts on its own once the pool reports the validated IPA: the pool's
   callback starts it in the background, and so does every list read of the app's builds (the owner

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@wix/himalaya-cli",
-  "version": "0.1626.0",
+  "version": "0.1627.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": [
@@ -72,5 +72,5 @@
       "artifactId": "himalaya-cli"
     }
   },
-  "falconPackageHash": "869790bb3cee9edb5ddd63f3befb4a65c1999a3ba9f388e5ad711509"
+  "falconPackageHash": "3437d7237a03ba353247802e752b58234b9842f8b8d1758e436e262a"
 }