@wix/himalaya-cli 0.1155.0 → 0.1157.0

package/guides/getting-started.md

@@ -324,8 +324,9 @@ Keys are transmitted to the authenticated backend for Branded/Ping custody, not
 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.
+Backend readiness does not prove notification delivery. A successful setup turns push on in
+`config.ts` (the Ping family included; notification routes are derived at every build); it does
+not build a binary, register a device or send a notification.
 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

package/guides/himi-skill.md

@@ -353,8 +353,9 @@ Keys are transmitted to the authenticated backend for Branded/Ping custody, not
 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.
+Backend readiness does not prove notification delivery. A successful setup turns push on in
+`config.ts` (the Ping family included; notification routes are derived at every build); it does
+not build a binary, register a device or send a notification.
 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

package/guides/push-cli-onboarding.md

@@ -45,7 +45,8 @@ himi notify setup --content ./liftgear --target wix \
 The APNs environment must match the signed app. The Android package must match its
 Firebase client configuration; it need not equal the iOS bundle ID. Existing public
 bindings come from `provisioning.json`; flags override them. Keep the build configuration
-aligned with the selections. This command does not rewrite `config.ts` or build a binary.
+aligned with the selections. A successful setup turns push on in `config.ts` (see
+[Native push configuration](#native-push-configuration)); the command never builds a binary.
 
 To also request Apple signing resources, add `--apple-signing`, `--asc-key-file`,
 `--asc-key-id`, and `--asc-issuer-id`. The App Store Connect key is separate from the
@@ -82,13 +83,26 @@ 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; 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; the app's
-`config.ts` does the first two (see [Native push configuration](#native-push-configuration)).
+[Send a test notification](#send-a-test-notification). Setup turns push on in the app's
+`config.ts` and picks the Ping family there (see
+[Native push configuration](#native-push-configuration)); it does not send notifications or
+verify phone delivery.
 
 ## Native push configuration
 
-The app's own `config.ts` turns push on; `himi notify setup` never edits it.
+Once the setup is accepted (`ready`, or still `provisioning`), `himi notify setup` turns push on in
+the app's own `config.ts`, once. Until it is on, the command does not report success.
+It adds only what is missing and leaves what you wrote alone:
+
+- a `push` block with no `routes`;
+- `"push"` in `capabilities`;
+- `siteId` in a `WixConsumerAuthProvider({ … })` login that has none.
+
+It saves the original to `.himi/notify-setup-backup/`, checks the edit with
+`himi validate --strict`, and puts the original back if the edit introduced an error. What it
+cannot add safely, such as a login that is not a Wix member login or a `push` block of your own,
+it prints as an instruction instead. `--dry-run` shows the planned edit without writing it, and
+a second run changes nothing. The result:
 
 ```ts
 auth: WixConsumerAuthProvider({
@@ -99,15 +113,12 @@ auth: WixConsumerAuthProvider({
   bootAsVisitor: true,
 }),
 capabilities: ["push" /* , … */],
+// Routes are derived at build time from provisioning.json and your screens; see himi validate.
 push: {
   registrar: "wix-ping",
   pingAppName: "WixBrandedWebApp",
   requestPermissionOnLaunch: true,
   payloadAdapter: "wix-ping",
-  routes: [
-    { match: "my-account/:site/stores/orders/:orderId",
-      link: "<scheme>://screen/<order-screen>?id={orderId}" },
-  ],
 },
 ```
 
@@ -119,13 +130,72 @@ push: {
   Keep `siteId` in `auth` on the site `himi notify setup` configured. A changed `siteId` or
   `clientId` ships with `himi push` like the rest of the config, and the app picks it up on
   its next launch; until then iOS stops registering rather than register the old site.
-- `routes` turn the Wix links inside notifications into the app's screens, one route per
-  link shape. A notification whose link matches no route opens the app without navigating.
-  `himi validate` warns when a route names a screen the app does not declare.
+  `himi validate` reports `push-auth-site` when the login is not a member login on that site.
 - The `push` block ships with `himi push`; changing it needs no new binary. The binary still
   has to carry the push entitlement: the `branded-lite` shell requests it, and the signing
   profile must grant `aps-environment` (see the QA build notes below).
 
+### Notification routes
+
+Routes turn the Wix links inside notifications into the app's screens. When the `push` block
+has no `routes` and `provisioning.json` lists the site's verticals (`himi site analyze --apply`
+writes them), every build (`himi run`, `himi validate` and `himi push`) derives the routes from
+the app's linkable screens: `navigation.linkableScreens`, or every screen when it lists none.
+
+Routes are never written into `config.ts`, so adding or renaming a screen needs only the next
+build. A notification gets a route only when its screen is certain: the screen `push.screens`
+names, or else the destination's canonical screen id. Template apps already use those ids. The
+site's verticals decide which destinations `himi validate` expects a screen for.
+
+| Destination | Site vertical | Canonical screen | Opens |
+|---|---|---|---|
+| `store.order` | `store` | `himi_order` | the order |
+| `bookings.session` | `bookings` | `himi_bookings` | the member's bookings |
+| `groups.post` | `groups` | `himi_group` | the group |
+| `forum.thread` | `forum` | `himi_forum_post` | the post |
+| `forum.create` | `forum` | `himi_create_post` | the new-post screen |
+| `blog.post` | `blog` | `himi_blog_post` | the post |
+| `members.profile` | `members` | `himi_member` | the member |
+| `events.event` | `events` | `himi_event` | the event |
+| `galleries.shared` | `galleries` | `himi_galleries` | the gallery list |
+| `galleries.album` | `galleries` | `himi_photo_album` | the album |
+| `notifications.list` | `notifications` | `himi_notifications` | the notifications list |
+
+For screens with other ids, name them in `push.screens`. It is for authoring only and is never
+served:
+
+```ts
+push: {
+  // …
+  screens: {
+    "store.order": "my_order",
+    "bookings.session": "my_bookings",
+    "blog.post": { screenId: "article", paramKey: "slug" },
+  },
+},
+```
+
+A screen that opens one item gets its id in the param named `id` when its linkable screen
+declares one, otherwise in its only declared param key. When it declares several, name the one it
+reads with `paramKey`. The key has to be one of the screen's `paramKeys`: a shell passes a screen
+only the params its linkable screen declares.
+
+`himi validate` lists, without failing even under `--strict`, each destination the site has that
+no screen takes, with the fix, and the verticals Wix sends no member notification links for.
+
+To write the table yourself, declare `routes`. A declared table, even an empty one, is used as
+is:
+
+```ts
+routes: [
+  { match: "my-account/:site/stores/orders/:orderId",
+    link: "<scheme>://screen/<order-screen>?id={orderId}" },
+],
+```
+
+A notification whose link matches no route opens the app without navigating. `himi validate`
+warns when a declared route names a screen the app does not declare.
+
 **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:

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

@@ -217,6 +217,11 @@ images stay as `static.wixstatic.com` URLs in descriptors — do not vendor
   literals (`HIMALAYA.md` copy rule).
 - **Auth** — `wix-consumer`; boot visitor unless a job needs members.
   `himi docs wix-login-integration`. Members are **site members**.
+- **Notifications** — give each vertical's detail screen its canonical id (`himi_order`,
+  `himi_event`, `himi_forum_post`, …) or name it in `push.screens`, and list it in
+  `navigation.linkableScreens` with the param it reads. After `himi notify setup`, every build
+  derives the notification routes from `provisioning.json` and those screens; `himi validate`
+  lists the ones still unrouted. `himi docs push-cli-onboarding`.
 
 ### 5. Prove it, then ship
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@wix/himalaya-cli",
-  "version": "0.1155.0",
+  "version": "0.1157.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": "fdcb8ee43c58cbb6299d582962eed54297bb7c2152984221e59fccd4"
+  "falconPackageHash": "3855653c89440e946466c0cb88bbc773e9933df0411400c4fbd70c04"
 }