@wix/himalaya-cli 0.1110.0 → 0.1112.0

package/guides/getting-started.md

@@ -293,7 +293,22 @@ setup response, inspect status before retrying; the CLI does not automatically r
 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
 and is also served at that public URL. No repository access is required. This is notification setup; `himi push` publishes
-app content. Existing `notify send|tokens|doctor` commands use the local notification server.
+app content.
+
+Once status is ready and a member's device has registered, send that member a test through Ping
+as Himalaya — no Apple or Firebase keys, same two logins:
+
+```sh
+himi notify send --provider ping --target wix --content ./my-app \
+  --member-email <member login email> --title 'Route check' \
+  --link '<scheme>://screen/<screenId>?id=<itemId>' --dry-run
+```
+
+Drop `--dry-run` to send. The server checks ownership, readiness, the link against the published
+release and the member before sending. Acceptance is not delivery: it can reach several of the
+member's devices, never their other Wix apps. After `send_outcome_unknown`, re-run the same
+command with the printed `--request-id`, so the notification cannot arrive twice. Without `--provider`,
+`notify send|tokens|doctor` use the local notification server.
 
 ## Shipping — over the air by default, a binary only for a native delta
 
@@ -341,8 +356,8 @@ For Android, this customer flow currently supports the `branded-lite` shell and
 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.
+and a targeted delivery/tap test are still required after installation; send that test with
+`himi notify send --provider ping`. 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

@@ -322,7 +322,22 @@ setup response, inspect status before retrying; the CLI does not automatically r
 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
 and is also served at that public URL. No repository access is required. This is notification setup; `himi push` publishes
-app content. Existing `notify send|tokens|doctor` commands use the local notification server.
+app content.
+
+Once status is ready and a member's device has registered, send that member a test through Ping
+as Himalaya — no Apple or Firebase keys, same two logins:
+
+```sh
+himi notify send --provider ping --target wix --content ./my-app \
+  --member-email <member login email> --title 'Route check' \
+  --link '<scheme>://screen/<screenId>?id=<itemId>' --dry-run
+```
+
+Drop `--dry-run` to send. The server checks ownership, readiness, the link against the published
+release and the member before sending. Acceptance is not delivery: it can reach several of the
+member's devices, never their other Wix apps. After `send_outcome_unknown`, re-run the same
+command with the printed `--request-id`, so the notification cannot arrive twice. Without `--provider`,
+`notify send|tokens|doctor` use the local notification server.
 
 ## Shipping — over the air by default, a binary only for a native delta
 
@@ -370,8 +385,8 @@ For Android, this customer flow currently supports the `branded-lite` shell and
 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.
+and a targeted delivery/tap test are still required after installation; send that test with
+`himi notify send --provider ping`. 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

@@ -81,8 +81,9 @@ repeats the provisioning POST automatically. Inspect status before retrying.
 
 After setup, continue normal app development, validation, publish/preview/promote and
 native distribution. Native push configuration, member authentication, device-token
-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.
+registration and a delivery/tap test are still required; for the test, see
+[Send a test notification](#send-a-test-notification). Setup does not enable native
+capabilities, choose a Ping family, send notifications or verify phone 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.
@@ -106,8 +107,61 @@ and this flow does not retrieve a customer Play signing key. Native push wiring,
 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.
+## Send a test notification
+
+Once status is `ready` and a signed-in member's device has registered, send that member one
+notification through Ping. Himi Serve sends it as Himalaya, so you need no Apple or Firebase
+key files and no Wix internal tooling:
+
+```sh
+himi login --browser --target wix
+wix login
+himi notify send --provider ping --target wix --content ./liftgear \
+  --member-email member@example.com --title 'Route check' --body 'Tap to open' \
+  --link 'himalaya-LiftGear://screen/himi_product?id=<itemId>' --dry-run
+himi notify send --provider ping --target wix --content ./liftgear \
+  --member-email member@example.com --title 'Route check' --body 'Tap to open' \
+  --link 'himalaya-LiftGear://screen/himi_product?id=<itemId>'
+```
+
+`--content` supplies the app and site (or pass `--app` and `--site`). Log in to both CLIs as
+the owner of the app and the site. Himi also mints a site token with `wix token --site`; the
+server uses it only to look up the member by login email on that one site.
+
+Before anything is sent, the server checks:
+
+- the owner credentials and app ownership;
+- that the site belongs to the same account;
+- that push setup is `ready` for this app on this site;
+- that the link opens a screen the app's live release ships, using the app's exact scheme and
+  either a linkable `screen/<id>` or a deep-link pattern (a device on a different rollout ring
+  may have a different set of screens);
+- that exactly one approved member has that login email.
+
+`--dry-run` runs every check and sends nothing. The link is forwarded exactly as given, query
+string included. A private screen is allowed; the app's login gate still applies when tapped.
+
+**Acceptance is not delivery.** Ping does not report which devices it reached. The notification
+goes to the member's subscribed devices for this site's Branded-family app, which can be more
+than one device. It does not go to their other Wix apps. Confirm receipt and the tap on the
+device itself.
+
+Every send carries a request ID. If the outcome is unknown (`send_outcome_unknown`, or a lost
+response), the CLI prints the ID and never retries on its own. Re-run the same command with
+`--request-id <id>`: Ping runs one request at most once per site for 24 hours, so a retry
+cannot notify twice. A send without `--request-id`, or with a changed member, title, body or
+link, is a new notification.
+
+| Error | Meaning |
+| --- | --- |
+| `push_not_ready` | Run `himi notify setup` for this app and site first. |
+| `member_not_found` / `member_ambiguous` / `member_not_active` | Use the login email of one approved site member. |
+| `link_not_routable` | The link's scheme or screen is not in the published release. |
+| `forbidden_site` / `site_token_invalid` | Both Wix logins must belong to the site owner. |
+| `rate_limited` | Wait `retry-after` seconds; test sends are limited per owner. |
+
+`himi notify send` without `--provider`, and `notify tokens|doctor`, keep their existing
+local admin-server behavior. They are separate from the hosted commands above.
 
 If ownership cannot be verified, stderr includes a `push_ownership_check_failed` event
 with the failing check (`list_apps` or `app_role`), endpoint path and HTTP status.

package/guides/skill.md

@@ -93,6 +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.
+For the test, `himi notify send --provider ping --target wix --content ./my-app --member-email <login>
+--title <t> --link <scheme>://screen/<id>` has Himi Serve send one notification through Ping
+to that site member, with no provider keys; run it with `--dry-run` first. Ping acceptance is not delivery:
+confirm receipt and the tap on the device.
 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;

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@wix/himalaya-cli",
-  "version": "0.1110.0",
+  "version": "0.1112.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": "3c893ffc5f5c27155566e2ef11edafaa41e7ec615140f4c86732a949"
+  "falconPackageHash": "eddb135db9560051303f23b17115c9f9952f4d120580b7e776f0928d"
 }