@wix/himalaya-cli 0.1098.0 → 0.1099.0

package/dist/cli.mjs

@@ -125,6 +125,7 @@ function resolveTarget(opts = {}) {
   }
   const base = { ...fromBuiltin, ...fromFile };
   return {
+    previewRoute: env.HIMI_SERVE_PREVIEW_ROUTE ?? base.previewRoute,
     serve: opts.serveUrl ?? env.HIMI_SERVE_URL ?? base.serve ?? "",
     telemetry: opts.telemetryUrl ?? env.HIMI_TELEMETRY_URL ?? base.telemetry ?? "",
     control: opts.controlUrl ?? env.HIMI_CONTROL_URL ?? base.control ?? "",
@@ -19012,11 +19013,16 @@ var init_himi_package = __esm({
 // ../../packages/serve/src/claude-plugin.ts
 var claude_plugin_exports = {};
 __export(claude_plugin_exports, {
+  CONNECTOR_PLUGIN_DESCRIPTION: () => CONNECTOR_PLUGIN_DESCRIPTION,
+  CONNECTOR_PLUGIN_NAME: () => CONNECTOR_PLUGIN_NAME,
   HIMI_MARKETPLACE_NAME: () => HIMI_MARKETPLACE_NAME,
   HIMI_MCP_SERVER: () => HIMI_MCP_SERVER,
   HIMI_NPM_PACKAGE: () => HIMI_NPM_PACKAGE,
   HIMI_PLUGIN_DESCRIPTION: () => HIMI_PLUGIN_DESCRIPTION,
   HIMI_PLUGIN_NAME: () => HIMI_PLUGIN_NAME,
+  connectorMarketplaceEntry: () => connectorMarketplaceEntry,
+  connectorPluginFiles: () => connectorPluginFiles,
+  connectorPluginManifest: () => connectorPluginManifest,
   himiMarketplace: () => himiMarketplace,
   himiPluginFiles: () => himiPluginFiles,
   himiPluginManifest: () => himiPluginManifest,
@@ -19054,6 +19060,31 @@ function himiMarketplace(archiveUrl, sha2565) {
     ]
   };
 }
+function connectorPluginManifest() {
+  return {
+    name: CONNECTOR_PLUGIN_NAME,
+    displayName: "Wix Native App Builder",
+    description: CONNECTOR_PLUGIN_DESCRIPTION,
+    author: { name: "Wix" },
+    keywords: ["wix", "mobile", "ios", "android", "app-builder", "himi", "connector"]
+  };
+}
+function connectorPluginFiles(mcpUrl, skillMd) {
+  const json6 = (o) => `${JSON.stringify(o, null, 2)}
+`;
+  return [
+    { path: ".claude-plugin/plugin.json", text: json6(connectorPluginManifest()) },
+    { path: ".mcp.json", text: json6({ mcpServers: { [CONNECTOR_PLUGIN_NAME]: { type: "http", url: mcpUrl } } }) },
+    { path: `skills/${CONNECTOR_PLUGIN_NAME}/SKILL.md`, text: skillMd }
+  ];
+}
+function connectorMarketplaceEntry(archiveUrl, sha2565) {
+  return {
+    name: CONNECTOR_PLUGIN_NAME,
+    description: CONNECTOR_PLUGIN_DESCRIPTION,
+    source: { source: "archive", url: archiveUrl, ...sha2565 ? { sha256: sha2565 } : {} }
+  };
+}
 function storeZip(files) {
   const enc = new TextEncoder();
   const entries = files.map((f) => ({ name: enc.encode(f.path), data: enc.encode(f.text) }));
@@ -19115,7 +19146,7 @@ function storeZip(files) {
   }
   return out2;
 }
-var HIMI_PLUGIN_NAME, HIMI_MARKETPLACE_NAME, HIMI_NPM_PACKAGE, HIMI_MCP_SERVER, HIMI_PLUGIN_DESCRIPTION;
+var HIMI_PLUGIN_NAME, HIMI_MARKETPLACE_NAME, HIMI_NPM_PACKAGE, HIMI_MCP_SERVER, HIMI_PLUGIN_DESCRIPTION, CONNECTOR_PLUGIN_NAME, CONNECTOR_PLUGIN_DESCRIPTION;
 var init_claude_plugin = __esm({
   "../../packages/serve/src/claude-plugin.ts"() {
     init_himi_package();
@@ -19124,6 +19155,8 @@ var init_claude_plugin = __esm({
     HIMI_NPM_PACKAGE = "@wix/himalaya-cli";
     HIMI_MCP_SERVER = { command: "npx", args: ["-y", HIMI_NPM_PACKAGE, "mcp"] };
     HIMI_PLUGIN_DESCRIPTION = "Build native iOS + Android apps with Wix: the himi skill plus the himi MCP tools \u2014 validate, test, render, a live preview in your IDE, and draft publishing to Himi Player.";
+    CONNECTOR_PLUGIN_NAME = "wix-native-app-builder";
+    CONNECTOR_PLUGIN_DESCRIPTION = "Build native iOS + Android apps with Wix from a conversation: the Wix Native App Builder connector plus its skill. Publishes private drafts you preview in chat or on your phone with Himi Player.";
   }
 });
 
@@ -24589,7 +24622,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]+$/;
@@ -28210,7 +28242,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,
@@ -67572,6 +67603,10 @@ var ServeCliClient = class {
   }
   async request(plane, method, path2, opts = {}) {
     const headers2 = { ...opts.headers };
+    if (this.target.previewRoute) {
+      if (!/^[a-zA-Z0-9][a-zA-Z0-9._-]{0,127}$/.test(this.target.previewRoute)) throw new Error("invalid_dist_preview_route");
+      headers2["x-wix-route-serve"] = this.target.previewRoute;
+    }
     if (opts.body !== void 0) headers2["content-type"] = "application/json";
     const carriesCredential = Object.keys(headers2).some((h2) => CREDENTIAL_HEADERS.has(h2.toLowerCase()));
     const res = await this.fetchImpl(this.baseFor(plane) + path2, {
@@ -67874,8 +67909,19 @@ var ServeCliClient = class {
   }
   // ---- himi dist (QA binary builds brokered onto the Job Service Mac pool) ----
   /** Request a QA build (POST /v1/admin/dist). Returns one job per requested platform. */
-  distCreate(body) {
-    return this.request("control", "POST", "/v1/admin/dist", { body, headers: this.ctrlHeaders() });
+  assertWixAuthorizationTarget() {
+    const url = new URL(this.baseFor("control"));
+    const host = url.hostname.toLowerCase();
+    const local = ["127.0.0.1", "localhost", "[::1]"].includes(host) && ["http:", "https:"].includes(url.protocol);
+    const wix = url.protocol === "https:" && (host === "wix.com" || host.endsWith(".wix.com"));
+    if (!local && !wix) throw new Error("customer_signing_untrusted_control_origin");
+  }
+  distCreate(body, options = {}) {
+    if (options.wixAuthorization) this.assertWixAuthorizationTarget();
+    return this.request("control", "POST", "/v1/admin/dist", {
+      body,
+      headers: { ...this.ctrlHeaders(), ...options.wixAuthorization ? { authorization: options.wixAuthorization } : {} }
+    });
   }
   /** One job's record, refreshed from Job Service while it is still in flight. */
   distStatus(jobId) {
@@ -70055,8 +70101,8 @@ var USAGE = `himi \u2014 the Himalaya authoring CLI (remote dev loop)
                                            owner-lite | brandy | player | demo-app). --signing defaults to
                                            wix-managed: the Wix Apple account mints a per-app
                                            identity for the build, so you provision nothing.
-                                           --signing byo (your own Apple account) is reserved and
-                                           501s. --android-signing picks the KEYSTORE for an APK (a
+                                           --signing byo --site <id> reuses your existing customer
+                                           ad-hoc profile and certificate for iOS. --android-signing picks the KEYSTORE for an APK (a
                                            separate axis from --signing, which is the Apple account):
                                            qa-keystore (default, the repo's committed key \u2014 same on
                                            every pool machine, so a build installs over the last one),
@@ -70341,7 +70387,7 @@ var COMMANDS = [
   { name: "patch", summary: 'change ONE item of a published app \u2014 a screen descriptor, a Tier-5 bundle, tokens, or the app-config baseline \u2014 from a RAW FILE, with no content package and no build. The low-level door: it does not lint your package, because there is no package here; `himi push --only <selector>` is the same edit with the full build + lint gate and is what to reach for when the package is in hand. Derives a new release from the app\'s current LIVE release, or from `--from-release <id>`. An explicit `--draft` or `--live` is REQUIRED \u2014 a patch has no default blast radius \u2014 and `--notes` is required with `--live` on a screen or app-config patch, because off-repo `gitSha` is "dev" and the ledger notes are then the only durable record of bytes that correspond to no commit. A branch does not merge: activating one derived from an older release reverts every item the patch does not move, so that case is refused until `--accept-regressions`. A bundle patch must repoint a screen (`--for-screen`) or the bytes land under a manifest key nothing reads. It cannot ADD a screen (screens are git-only, RFC 0012), never claims a slug \u2014 the app must already be published \u2014 and carries no attestation, source archive, assets, icon or minBinaryVersion, each named in the output.', required: "screen <id> --file <descriptor.json> [--bundle <sha256|none>] | bundle --file <bundle.js> (--for-screen <id>[,<id>] | --no-rebind) | tokens --file <tokens.json> | app-config --file <app-config.json> ; (--draft|--live) --app <a> [--from-release <id>] [--accept-regressions] [--label <n>] [--notes <t>] [--force] [--target <t>] (--control-token)" },
   { name: "flags", summary: "read and change the app's OPERATIONAL flags (RFC 0013) \u2014 `list` prints what the DEVICE door serves, `set <key> --definition` creates or replaces one, `ramp <key>` moves its rollout share or kills it, `rm <key>` deletes it and echoes the definition back so the removal is reversible. Every write is followed by a read of the same door the device uses, and the answer is reported as `servedNow`: flags are stored in the app's git-committed flags.json, so a control plane with no checkout accepts a write it will never serve.", required: "list|set|ramp|rm [<key>] [--definition <json|@file>] [--percent 0-100] [--enabled true|false] [--app <a>] (--control-token)" },
   { name: "visibility", summary: "read (no value) or set whether the public registry (/v1/apps + the Himi Player picker) LISTS the app. `public` lists it for everyone; `unlisted` hides it from listings while direct reads by app id \u2014 deep links, previews \u2014 keep working. App from --app or the content dir. Setting it needs no republish.", required: "[public|unlisted] [--app <a>] [--content <dir>] (--control-token)" },
-  { name: "dist", summary: "build an INSTALLABLE QA binary (signed IPA / APK) on the Wix Job Service Mac pool and return an install link \u2014 the serve plane brokers the job, the pool builds it. WAITS for the build by default (~4 min) and prints the install link; `--no-wait` returns a jobId immediately instead. Omitting `--release` builds whatever is LIVE for the app. A named draft is refused unless `--allow-draft` makes that exceptional build explicit. `status <jobId>` / `watch <jobId>` / `list --app <a>` / `cancel <jobId>` inspect and stop builds (`watch` reports up front whether the job mints its own signing identity or borrows one, so a doomed iOS build is cancellable in seconds rather than after the archive). Off-repo, name a target \u2014 `--target wix` for a self-serve Wix login or `--target bo` for the internal employee path (the in-repo default is a local dev plane that isn't reachable off-repo); self-serve callers may build their OWN apps under a tighter budget (2 in flight / 5 per 24h), while a manage-only owner-role credential is refused. `--shell` picks the native host to sign into (branded-lite | owner-lite | brandy | player | demo-app); `brandy` is the site shell \u2014 the customer's own website as native-framed tabs. `--signing` defaults to `wix-managed` \u2014 the Wix Apple account mints a per-app signing identity for the build, so the caller provisions no Apple credentials of their own; `--signing byo` (sign with your own Apple account) is reserved and 501s. `--android-signing` is the Android counterpart and a SEPARATE axis (a keystore, not an Apple account): `qa-keystore` (default \u2014 the repo's committed QA key, identical on every pool machine, so a build installs over the previous one), `wix-keystore` (the Wix key the pool machine carries; the build FAILS naming the paths searched if it carries none, rather than quietly signing with something else), or `debug` (the old per-machine key \u2014 QA must uninstall any previous build first). NOT the normal way to ship: screens, Tier-5 bundles, tokens and app-config all go over the air with `himi push` in seconds \u2014 a binary trip is only needed for a NATIVE delta (a new SDUI component, a new declared capability/entitlement, a new bundle id, or a minBinaryVersion floor bump). Refuses to build an app whose launcher icon is missing, a placeholder, or one a store would reject \u2014 the one thing a binary carries that no later OTA push can fix; `--force` builds anyway", required: "[--app <a>] [--platform ios,android] [--release <id>] [--allow-draft] [--target <t>] [--shell branded-lite|owner-lite|brandy|player|demo-app] [--signing wix-managed|byo] [--android-signing qa-keystore|wix-keystore|debug] [--borrow-ios-id <bundleId>] [--no-wait] [--force] | status <jobId> [--target <t>] | watch <jobId> [--target <t>] [--interval <ms>] | list --app <a> [--target <t>] | cancel <jobId> [--target <t>]" },
+  { name: "dist", summary: "build an INSTALLABLE QA binary (signed IPA / APK) on the Wix Job Service Mac pool and return an install link \u2014 the serve plane brokers the job, the pool builds it. WAITS for the build by default (~4 min) and prints the install link; `--no-wait` returns a jobId immediately instead. Omitting `--release` builds whatever is LIVE for the app. A named draft is refused unless `--allow-draft` makes that exceptional build explicit. `status <jobId>` / `watch <jobId>` / `list --app <a>` / `cancel <jobId>` inspect and stop builds (`watch` reports up front whether the job mints its own signing identity or borrows one, so a doomed iOS build is cancellable in seconds rather than after the archive). Off-repo, name a target \u2014 `--target wix` for a self-serve Wix login or `--target bo` for the internal employee path (the in-repo default is a local dev plane that isn't reachable off-repo); self-serve callers may build their OWN apps under a tighter budget (2 in flight / 5 per 24h), while a manage-only owner-role credential is refused. `--shell` picks the native host to sign into (branded-lite | owner-lite | brandy | player | demo-app); `brandy` is the site shell \u2014 the customer's own website as native-framed tabs. `--signing` defaults to `wix-managed` \u2014 the Wix Apple account mints a per-app signing identity for the build, so the caller provisions no Apple credentials of their own; `--signing byo --site <id>` reuses an existing customer ad-hoc profile and certificate for iOS; requires an owned site and a completed personal signing binding. `--android-signing` is the Android counterpart and a SEPARATE axis (a keystore, not an Apple account): `qa-keystore` (default \u2014 the repo's committed QA key, identical on every pool machine, so a build installs over the previous one), `wix-keystore` (the Wix key the pool machine carries; the build FAILS naming the paths searched if it carries none, rather than quietly signing with something else), or `debug` (the old per-machine key \u2014 QA must uninstall any previous build first). NOT the normal way to ship: screens, Tier-5 bundles, tokens and app-config all go over the air with `himi push` in seconds \u2014 a binary trip is only needed for a NATIVE delta (a new SDUI component, a new declared capability/entitlement, a new bundle id, or a minBinaryVersion floor bump). Refuses to build an app whose launcher icon is missing, a placeholder, or one a store would reject \u2014 the one thing a binary carries that no later OTA push can fix; `--force` builds anyway", required: "[--app <a>] [--platform ios,android] [--release <id>] [--allow-draft] [--target <t>] [--shell branded-lite|owner-lite|brandy|player|demo-app] [--signing wix-managed|byo] [--site <id>] [--android-signing qa-keystore|wix-keystore|debug] [--borrow-ios-id <bundleId>] [--no-wait] [--force] | status <jobId> [--target <t>] | watch <jobId> [--target <t>] [--interval <ms>] | list --app <a> [--target <t>] | cancel <jobId> [--target <t>]" },
   { name: "testflight", summary: 'build, sign and upload an app to TestFlight (internal testers \u2014 no Beta App Review), then WAIT until App Store Connect finishes processing it. Sugar for `store upload --track testflight`. Prompts first: a build number is consumed permanently on a real Apple account and cannot be reused \u2014 `--yes` for CI, `--dry-run` to see the plan without touching anything. The wait is the real check, not a nicety: fastlane prints "Successfully uploaded" for a binary App Store Connect then rejects in processing, and a rejected binary leaves NO build record at all (the reason is emailed). Public App Store review is deliberately NOT automatable here \u2014 `--track appstore` is refused; use /submit-ios-app when you mean to go public', required: "<app> [--track testflight|internal] [--profile <name>] [--yes] [--dry-run] [--skip-build] [--no-wait] [--json]" },
   { name: "store", summary: "the App Store Connect group behind `testflight`. `preflight <app>` checks readiness offline (icon, entitlements, encryption flag, version, store.config ids, listing + review record); `upload <app>` is what `testflight` runs; `status <app>` reads live build + processing state. `--profile` selects WHICH App Store Connect account: an app built for a Wix customer ships under the CUSTOMER's Apple team (Apple guideline 4.2.6 forbids an app-generation service submitting on a client's behalf), declared per-app as ios.credentialProfile in store.config.yaml and resolved from ~/.himalaya/store-credentials/<name>.json \u2014 the .p8 itself never enters the repo", required: "preflight <app> [--profile <n>] | upload <app> [--track <t>] [--profile <n>] [--yes] [--dry-run] | status <app> [--profile <n>]" },
   { name: "guide", summary: "print the Himalaya overview + headless dev loop + available topics (offline)", required: "[--json]" },
@@ -76499,7 +76545,7 @@ ${label2}`);
               if (!flags.json) {
                 io.log(`  app ${rec.app} \xB7 ${rec.platform} \xB7 shell ${rec.shell ?? "?"} \xB7 ${String(rec.gitCommitSha ?? "").slice(0, 12)}`);
                 io.log(
-                  rec.platform !== "ios" ? "  signing: n/a (android signs with its own keystore)" : minted ? "  signing: MINTED \u2014 the job fetches its own identity; it will build under the app's own bundle id" : borrowed ? `  signing: BORROWED ${borrowed} \u2014 the binary carries another app's identifier and REPLACES it on the device` : "  signing: none dispatched \u2014 the pool must find a profile itself, which fails when it has none.\n           Minting is ON by default, so this means the serve plane either has HIMI_DIST_APPLE_SIGNING set to 0/false/off/no, or predates the minting route."
+                  rec.platform !== "ios" ? "  signing: n/a (android signs with its own keystore)" : rec.signing === "byo" ? "  signing: CUSTOMER \u2014 pinned personal team and ad-hoc profile; registered devices only" : minted ? "  signing: MINTED \u2014 the job fetches its own identity; it will build under the app's own bundle id" : borrowed ? `  signing: BORROWED ${borrowed} \u2014 the binary carries another app's identifier and REPLACES it on the device` : "  signing: none dispatched \u2014 the pool must find a profile itself, which fails when it has none.\n           Minting is ON by default, so this means the serve plane either has HIMI_DIST_APPLE_SIGNING set to 0/false/off/no, or predates the minting route."
                 );
                 if (rec.buildUrl) io.log(`  log ${rec.buildUrl}`);
               }
@@ -76579,6 +76625,19 @@ ${label2}`);
         }
         const { captchaContentInput: captchaContentInput2 } = await Promise.resolve().then(() => (init_captcha2(), captcha_exports));
         const captchaSiteId = str7(flags.site) ?? captchaContentInput2(contentDir(flags)).siteId;
+        let wixAuthorization;
+        if (str7(flags.signing)?.trim().toLowerCase() === "byo") {
+          try {
+            c.assertWixAuthorizationTarget();
+            wixAuthorization = await accountToken();
+          } catch {
+            print({
+              error: "customer_signing_authorization_unavailable",
+              hint: "BYO requires a Wix control URL (or loopback) and an existing Wix CLI login. Run `wix login`, then retry."
+            });
+            return 1;
+          }
+        }
         let r;
         try {
           r = await c.distCreate({
@@ -76597,13 +76656,14 @@ ${label2}`);
             ...str7(flags["borrow-ios-id"]) ? { borrowIosBundleId: str7(flags["borrow-ios-id"]) } : {},
             ...str7(flags.destination) ? { destination: str7(flags.destination) } : {},
             ...str7(flags.signing) ? { signing: str7(flags.signing) } : {},
+            ...str7(flags.site) ? { site: str7(flags.site) } : {},
             // WHICH KEYSTORE signs the APK. A separate axis from --signing (that one is the Apple
             // account), so a `--platform ios,android` build can say "Wix-managed on iOS, the QA
             // keystore on Android" — the normal combination — with one command.
             // flags["android-signing"], NOT flags.androidSigning: parseFlags does no kebab→camel
             // conversion, so the camel form reads undefined and the flag is a silent no-op.
             ...str7(flags["android-signing"]) ? { androidSigning: str7(flags["android-signing"]) } : {}
-          });
+          }, { wixAuthorization });
         } catch (e) {
           return distUnreachable(e);
         }
@@ -76612,6 +76672,7 @@ ${label2}`);
           return 1;
         }
         const jobs = r.json?.jobs ?? [];
+        const failures = r.json?.failures ?? [];
         for (const line of shellShaDivergenceWarnings(jobs)) (flags.json === true ? io.error : io.log)(line);
         const noWait = flags["no-wait"] === true || flags.wait === false;
         if (noWait) {
@@ -76620,8 +76681,9 @@ ${label2}`);
             const t = str7(flags.target);
             const targetArg = t ? ` --target ${t}` : "";
             for (const j of jobs) io.log(`  ${j.platform}  ${j.jobId}  \u2192 himi dist status ${j.jobId}${targetArg}`);
+            for (const f of failures) io.error(`  ${f.platform}  ${f.error}: ${f.message}`);
           }
-          return 0;
+          return failures.length ? 1 : 0;
         }
         const intervalMs = Number(str7(flags.interval)) || 2e4;
         const timeoutMs = Number(str7(flags.timeout)) || 45 * 6e4;
@@ -76636,7 +76698,8 @@ ${label2}`);
               error: "dist_wait_timeout",
               waitedMs: timeoutMs,
               pending: [...pending.keys()],
-              finished: flags.json === true ? done : done.map(humanDistJob)
+              finished: flags.json === true ? done : done.map(humanDistJob),
+              ...failures.length ? { failures } : {}
             });
             return 1;
           }
@@ -76655,8 +76718,8 @@ ${label2}`);
             }
           }
         }
-        const allOk = done.every((d) => d.status === "SUCCESS");
-        print({ ok: allOk, jobs: flags.json === true ? done : done.map(humanDistJob) });
+        const allOk = failures.length === 0 && done.every((d) => d.status === "SUCCESS");
+        print({ ok: allOk, jobs: flags.json === true ? done : done.map(humanDistJob), ...failures.length ? { failures } : {} });
         await printDistQrsForJobs(done);
         return allOk ? 0 : 1;
       }

package/guides/getting-started.md

@@ -285,10 +285,10 @@ project settings or output. Enter Later to defer and continue building.
 `notify status` is read-only and needs no key files; `--refresh` checks providers live.
 Backend readiness does not prove notification delivery. This setup does not rewrite native
 configuration, select a Ping family, build a binary, register a device or send a notification.
-Continue building and publishing app content. Customer iOS push testing through `himi dist`
-is blocked until the hosted build service supports customer signing keys; the current Wix-managed QA
-binary cannot test the customer's saved push configuration. After an uncertain setup response, inspect status before
-retrying; the CLI does not automatically repeat provisioning.
+Continue building and publishing app content. For a customer push test, use the
+`himi dist --signing byo` flow below with existing signing assets and matching native configuration.
+The default Wix-managed binary does not match the customer's Apple identity. After an uncertain
+setup response, inspect status before retrying; the CLI does not automatically repeat provisioning.
 
 Full inputs, script flags and status meanings: `himi docs push-cli-onboarding`
 (https://apps.wix.com/_api/himi-serve/docs/push-cli-onboarding.md). The guide is bundled with the public npm package
@@ -321,11 +321,28 @@ bundle id per job — there is no profile to pre-provision and nothing to borrow
 <bundleId>` still exists as an escape hatch (the binary then installs under *that* id, which is
 fine for QA and wrong for anything else), but it is rarely what you want.
 For customer push credentials, the binary's Apple team, bundle ID and APNs environment must
-match the saved delivery configuration. The current self-serve `himi dist` path uses Wix's
-Apple team and a `com.wix.himi.<app>` bundle ID, so its QA binary cannot test customer iOS
-push. `--signing byo` is not supported. Testing through `himi dist` must wait for the hosted build service
-to support customer signing keys. Notification setup can verify backend configuration now,
-but does not make a matching customer-signed build available.
+match the saved delivery configuration. Use the app owner's account for both logins and
+select the deployed customer target explicitly:
+
+```sh
+himi login --browser --target wix
+wix login
+himi dist --app <app> --release <release-id> --site <owned-site-id> \
+  --platform ios,android --signing byo --android-signing qa-keystore --wait --target wix
+```
+
+The deployed backend and reachable runner source must support BYO. iOS reuses the customer's
+existing distribution certificate and ad-hoc profile, which must include the test iPhone and
+production APNs entitlement; the build does not create or revoke Apple assets. The remote runner
+imports the identity into its agent keychain and removes the imported identity and profile copies
+afterward, preserving that keychain.
+
+For Android, this customer flow currently supports the `branded-lite` shell and retrieves the
+site's package-matched Firebase `google-services.json`. `--android-signing qa-keystore` signs
+the APK with Himi's stable QA key, not a customer Play signing key. Firebase configuration enables
+push registration; it does not sign the APK. Native Ping wiring, member/device registration,
+and a targeted delivery/tap test are still required after installation. A ready backend or a
+successful build alone does not prove push delivery.
 
 **Android signing needs nothing either.** `--android-signing` defaults to `qa-keystore` — the
 repo's committed QA key, identical on every pool machine, so a new build installs *over* the last

package/guides/himi-skill.md

@@ -314,10 +314,10 @@ project settings or output. Enter Later to defer and continue building.
 `notify status` is read-only and needs no key files; `--refresh` checks providers live.
 Backend readiness does not prove notification delivery. This setup does not rewrite native
 configuration, select a Ping family, build a binary, register a device or send a notification.
-Continue building and publishing app content. Customer iOS push testing through `himi dist`
-is blocked until the hosted build service supports customer signing keys; the current Wix-managed QA
-binary cannot test the customer's saved push configuration. After an uncertain setup response, inspect status before
-retrying; the CLI does not automatically repeat provisioning.
+Continue building and publishing app content. For a customer push test, use the
+`himi dist --signing byo` flow below with existing signing assets and matching native configuration.
+The default Wix-managed binary does not match the customer's Apple identity. After an uncertain
+setup response, inspect status before retrying; the CLI does not automatically repeat provisioning.
 
 Full inputs, script flags and status meanings: `himi docs push-cli-onboarding`
 (https://apps.wix.com/_api/himi-serve/docs/push-cli-onboarding.md). The guide is bundled with the public npm package
@@ -350,11 +350,28 @@ bundle id per job — there is no profile to pre-provision and nothing to borrow
 <bundleId>` still exists as an escape hatch (the binary then installs under *that* id, which is
 fine for QA and wrong for anything else), but it is rarely what you want.
 For customer push credentials, the binary's Apple team, bundle ID and APNs environment must
-match the saved delivery configuration. The current self-serve `himi dist` path uses Wix's
-Apple team and a `com.wix.himi.<app>` bundle ID, so its QA binary cannot test customer iOS
-push. `--signing byo` is not supported. Testing through `himi dist` must wait for the hosted build service
-to support customer signing keys. Notification setup can verify backend configuration now,
-but does not make a matching customer-signed build available.
+match the saved delivery configuration. Use the app owner's account for both logins and
+select the deployed customer target explicitly:
+
+```sh
+himi login --browser --target wix
+wix login
+himi dist --app <app> --release <release-id> --site <owned-site-id> \
+  --platform ios,android --signing byo --android-signing qa-keystore --wait --target wix
+```
+
+The deployed backend and reachable runner source must support BYO. iOS reuses the customer's
+existing distribution certificate and ad-hoc profile, which must include the test iPhone and
+production APNs entitlement; the build does not create or revoke Apple assets. The remote runner
+imports the identity into its agent keychain and removes the imported identity and profile copies
+afterward, preserving that keychain.
+
+For Android, this customer flow currently supports the `branded-lite` shell and retrieves the
+site's package-matched Firebase `google-services.json`. `--android-signing qa-keystore` signs
+the APK with Himi's stable QA key, not a customer Play signing key. Firebase configuration enables
+push registration; it does not sign the APK. Native Ping wiring, member/device registration,
+and a targeted delivery/tap test are still required after installation. A ready backend or a
+successful build alone does not prove push delivery.
 
 **Android signing needs nothing either.** `--android-signing` defaults to `qa-keystore` — the
 repo's committed QA key, identical on every pool machine, so a new build installs *over* the last

package/guides/push-cli-onboarding.md

@@ -84,11 +84,27 @@ native distribution. Native push configuration, member authentication, device-to
 registration and a delivery/tap test are still required. This command does not enable
 native capabilities, choose a Ping family, send notifications or verify phone delivery.
 
-**Customer iOS push testing through `himi dist` is not available yet.** The current
-Wix-managed QA build uses Wix's Apple team and a `com.wix.himi.<app>` bundle ID, which
-do not match the customer's saved push configuration. `--signing byo` is unsupported.
-Testing through `himi dist` must wait for the hosted build service to support customer signing keys.
-Backend setup and verification can proceed now; they do not prove device delivery.
+**Customer push QA builds use `himi dist --signing byo`.** After publishing an approved
+release, use a backend and reachable runner source that support the customer-signing flow.
+Use the app owner's account for both logins and explicitly select the deployed customer target:
+
+```sh
+himi login --browser --target wix
+wix login
+himi dist --app <app> --release <release-id> --site <owned-site-id> \
+  --platform ios,android --signing byo --android-signing qa-keystore --wait --target wix
+```
+
+iOS reuses the customer's existing distribution certificate and ad-hoc profile. The profile
+must include the test iPhone and production APNs entitlement; Apple team, bundle ID and APNs
+environment must match the saved push configuration. The build does not create or revoke Apple
+assets. The default Wix-managed binary uses a different Apple identity.
+
+Android currently requires the `branded-lite` shell and the site's package-matched Firebase
+`google-services.json`. The APK is signed with Himi's stable QA keystore; Firebase does not sign it,
+and this flow does not retrieve a customer Play signing key. Native push wiring, member/device
+registration and a targeted delivery/tap test remain required. Backend readiness and a successful
+build do not prove device delivery. See [QA builds](qa-builds.md) for prerequisites and diagnostics.
 
 `himi notify send|tokens|doctor` keep their existing local admin-server behavior; they
 are separate from the backend `setup|status` commands.

package/guides/qa-builds.md

@@ -143,13 +143,49 @@ The chosen policy is written to the job record (`signing`), so `himi dist status
 answer "whose certificate is on this binary" without re-deriving it from serve config that may
 have changed since.
 
-**`--signing byo`** — sign with the caller's *own* Apple account — is reserved and returns
-`501 dist_signing_unsupported`, and no job is dispatched. It is not a missing branch: honouring it
-means accepting the caller's Apple key and forwarding it to the pool, and job parameters ride in
-the `command` string the pool echoes into its build log. It needs a secret channel that is not the
-log first. `/v1/dist/signing` independently refuses any job whose record asks for a non-Wix policy
-(`403 signing_policy_mismatch`), so building `byo` cannot accidentally start handing out Wix key
-material — the same belt-and-braces `resolveBorrowedIosId` applies to borrowed ids.
+**`--signing byo`** uses an owned Wix site and its existing personal Apple distribution certificate
+and ad-hoc profile. Himi checks site ownership, the app's recorded native ID, profile
+type, certificate match, expiry, registered devices and production APNs entitlement before dispatch.
+It selects an existing compatible ad-hoc profile; the build does not create or revoke Apple assets.
+The runner fetches the certificate and profile using both its job token and a short-lived Buildkite
+identity token; the job token alone cannot authorize the download.
+
+On the Job Service `nodeCommandOptions` runner, Himi imports the customer's signing identity into
+the agent's **existing keychain**, using the agent-provided `KEYCHAIN_PASSWORD`. It checks identity
+discovery and noninteractive signing before archiving, then verifies the finished IPA. Cleanup
+deletes the imported customer identity (certificate and private key), the profile copies installed
+by this job, and its temporary files. It preserves the agent's keychain; it does not revoke the
+certificate or delete the original profile in Apple/Branded. A matching identity already in the
+keychain is refused before import so cleanup cannot delete a pre-existing identity.
+
+Outside that runner mode, Himi creates a temporary keychain and deletes it during cleanup. A
+missing password or keychain in agent-keychain mode fails the build instead of silently switching
+modes. Private key material does not enter job parameters or the public job record. The runner
+source SHA must advertise support for this protocol and be reachable from the pool before BYO
+dispatch is accepted. See [runner authentication](apple-signing-provisioning.md#customer-qa-runner-authentication-protocol-2).
+
+For an owned app using push, `himi notify setup --content <dir> --site <site-id>` provisions the
+backend and `himi notify status --content <dir> --site <site-id> --refresh` checks its current
+Branded/Ping configuration. These commands require both a Himi control
+credential and Wix account authorization. A `ready` setup record is a backend checkpoint, not proof
+that a binary installed, registered a member, received a notification or opened its destination.
+After publishing an approved release, use the app owner's account for both logins and explicitly
+select the deployed customer target for the paired QA build:
+
+```sh
+himi login --browser --target wix
+wix login
+himi dist --app <app> --release <release-id> --site <owned-site-id> \
+  --platform ios,android --signing byo --android-signing qa-keystore --wait --target wix
+```
+
+The Android customer-config path currently supports the `branded-lite` shell. It reads that site's
+`BrandedApp.buildConfig.android.googleServicesJson` and refuses an unsupported shell, a missing file,
+or a wrong-package Firebase client. It builds with the customer file and signs with the
+stable QA keystore. Each platform has its own job status and artifact link. If one platform cannot
+dispatch or build, the CLI returns a nonzero result while preserving the other platform's completed
+job and link. A successful artifact upload proves only that the recorded binary was built and stored;
+device installation, Ping registration, delivery and destination routing require separate checks.
 
 **`himi dist` waits by default** and prints the install link; `--no-wait` gives you a job id back
 immediately plus a Buildkite URL for the live log. Waiting is the right shape for ONE build;

package/guides/skill.md

@@ -93,8 +93,10 @@ credentials for their app, not a shared test account.
 Use `himi notify status --content ./my-app --target wix --refresh --json` to report live
 backend checks. A ready backend does not prove notification delivery to a phone: native push
 configuration, a signed build, member/device registration and a delivery/tap test still follow.
-Customer iOS push cannot be tested with the current Wix-managed `himi dist` QA binary.
-Testing through `himi dist` must wait for the hosted build service to support customer signing keys.
+For a customer push test, use `himi dist --signing byo` with the customer's existing Apple
+signing assets and matching app configuration. The default Wix-managed binary uses a different
+Apple identity. Read `himi docs qa-builds` for the paired iOS/Android command and prerequisites;
+the backend and build runner must support this customer-signing flow.
 Read `himi docs push-cli-onboarding` (also https://apps.wix.com/_api/himi-serve/docs/push-cli-onboarding.md) before
 setup for the required logins, credential fields and failure handling. The guide is bundled with the public npm package
 and is also served at the public URL above. No repository access is required.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@wix/himalaya-cli",
-  "version": "0.1098.0",
+  "version": "0.1099.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": [
@@ -67,5 +67,5 @@
       "artifactId": "himalaya-cli"
     }
   },
-  "falconPackageHash": "ef97bab45cc454401e25d3e4215f88dd0989fee4eff61ee47e6e23a0"
+  "falconPackageHash": "abd3482789935a7c1024e42bc726a232ef26e4612586b570d0b0fda7"
 }