@wix/himalaya-cli 0.1447.0 → 0.1448.0

package/guides/designing-himi-screens.md

@@ -176,11 +176,13 @@ responsive master/detail. *Reach for `Card` to cluster, not to wrap every single
 (`columns: 1, columnsMedium: 2`); `Table` for tabular rows; `Carousel`/`Pager` for swipeable panels;
 `Timeline` for chronological events. Compose rows as `ListItem` / `LabeledContent` / `DisclosureGroup`
 cells inside a `Card([VStack(spacing: 0)])`.
-> **Don't make `LazyList` the screen root.** The native `ScreenView` already wraps a screen's content
-> in a scroll view, so a `LazyList` as the (modifier-wrapped) root collapses to **zero height and
-> renders blank**. For a feed/list *screen*, use a plain `vstack` of `Card`s — it scrolls with the
-> screen. Reach for `LazyList` only *nested* inside a bounded-height slot (a fixed-height panel, a
-> horizontal rail) where its own virtualized scroll is what you want.
+> For a feed/list *screen*, prefer a root `VStack` with a direct vertical worker-bound `LazyList`
+> when the screen has the simple root shape supported by the native host; Android flattens that
+> shape into one lazy root so long lists do not compose every row. Other root shapes stay on the
+> eager screen path, as does a root list that sets `pagination`, `stickyHeader` or
+> `rowSwipeActions`. A `LazyList` nested deeper inside the screen's outer scroll is rendered
+> eagerly on Android to avoid nested-scroll measurement failures, even in a fixed-height panel. A
+> worker-bound horizontal `LazyList` is eager on Android too, so keep rails short.
 
 **Text** — `Text` for a single styled string (`maxLines` to truncate); `RichText` for inline mixed
 marks (bold/italic/link within one paragraph); `RichContent` for a Wix Ricos document with blocks,

package/guides/push-cli-onboarding.md

@@ -203,6 +203,37 @@ routes: [
 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.
 
+### Notification action buttons
+
+Declare actionable categories in the app's source `config.ts`. The native shells render one
+button per category action on iOS and Android; the notification payload selects the category.
+This is structural app configuration, not a `himi notify send` flag:
+
+```ts
+push: {
+  categories: [{
+    id: "time.action-required",
+    actions: [
+      { id: "review", title: "Review" },
+      { id: "snooze", title: "Snooze 1h", input: true },
+    ],
+  }],
+  observerAction: "tier5.myNav.onNotification",
+},
+```
+
+The app-level worker action named by `observerAction` receives every notification through the
+existing observer path. Use `readNotificationEvent` from `@himalaya/push` to read its params:
+
+- `notificationAction` is the pressed action id, or `""` for a receipt or ordinary body tap.
+- `notificationText` is the inline reply for an `input: true` action, or `""` otherwise.
+- Action presses have `tapped: "false"`; they are responses to an already-observed notification,
+  not new arrivals. They never navigate. The body tap retains the existing link navigation.
+
+Each action has its own deduplication key, so a foreground receipt does not swallow a later button
+press and pressing the same button twice is reported once. A press received before the worker is
+configured is queued and replayed once the current site's configuration is ready.
+
 **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/recipe-dynamic-list.md

@@ -14,6 +14,15 @@ the app's `.agents/skills/himalaya/examples/` (written by `himi init` and `himi
 card grids). `Carousel` and `Menu` take `itemsPath` the same way. Do **not** hand-roll
 a "VStack of Cards" — that renders only static items and can't bind live data.
 
+For a long list screen, make the vertical `LazyList` a direct child of the root `VStack`
+when the rest of the root uses only the supported simple layout. Android can then flatten
+the root into one `LazyColumn` and compose only visible rows. This applies only to a plain
+list: a `LazyList` that sets `pagination`, `stickyHeader` or `rowSwipeActions` keeps the
+screen's own scroll on Android and composes every row. A list nested deeper inside the
+screen's outer scroll also stays eager, and a fixed-height panel inside that scroll does not
+change that on Android. A worker-bound horizontal list is also eager on Android: it renders
+every row in a plain `Row`, so keep rails short.
+
 **`Grid` is not a `LazyList` with one column.** It shares `itemsPath` and the row
 template, and nothing else: the gesture props in §5 (`onPullToRefresh`, `pagination`)
 and `stickyHeader`/`rowSwipeActions` are declared on `LazyListProps` only. A key `Grid`

package/guides/wix-api-usage.md

@@ -104,6 +104,23 @@ response. The client holds **no** auth or HTTP —
 that's `WixApiCapability` (attaches auth per call, 401→refresh→retry). Import the domain by its canonical
 package `@himalaya/wix-<domain>` (unversioned name; the REST version is in the path — RFC 0043 D2).
 
+### Read an owner-created async job
+
+The first-party `@himalaya/wix-async-jobs` client exposes the current state of an async job through the
+Wix gateway. It is an owner-scoped read and requires `INFRA.ASYNC_JOB_READ`; visitor sessions receive
+403. Poll the returned `job.status` while it is `INITIALIZED` or `PROCESSING`, and stop at `FINISHED`
+or `FAILED`:
+
+```ts
+import { getAsyncJob } from "@himalaya/wix-async-jobs";
+
+const { job } = await getAsyncJob(jobId);
+const status = job?.status;
+```
+
+The client calls `GET /async-jobs/v1/async-jobs/{jobId}`. A missing job is an HTTP 404 with
+`JOB_NOT_FOUND`; do not treat that response as authorization evidence.
+
 > **Catalog V1 vs V3 — use V3 by default.** For a new Stores reader use
 > **`queryStoreProducts`** (POST
 > `/stores/v3/products/query`) and **`getStoreProduct`**, from the same `@himalaya/wix-stores`

package/guides/wix-sdk-overview.md

@@ -43,6 +43,7 @@ Same idea, one canonical entry — don't reach for the others:
 | I want to… | Canonical door | Layer |
 |---|---|---|
 | Read/write a Wix domain (products, bookings, members…) | `@himalaya/wix-<domain>` from a worker | L3 |
+| Read the state of an owner-created async job | `@himalaya/wix-async-jobs` → `getAsyncJob(jobId)` | L3 |
 | Emit a BI beacon | `wix-platform.bi` | L2 |
 | Conduct an experiment / read a flag | `wix-platform.experiments` / `wix-platform.flags` | L2 |
 | Translate a string / read the locale | `wix-platform.i18n` | L2 |

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@wix/himalaya-cli",
-  "version": "0.1447.0",
+  "version": "0.1448.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": [
@@ -71,5 +71,5 @@
       "artifactId": "himalaya-cli"
     }
   },
-  "falconPackageHash": "ec7806275850384530f4bb3f9e2a1ee23e66bf5223389c5dc7a3446a"
+  "falconPackageHash": "ceeeb017afff0753eec531692afa7a5e7ca0bf9e38054ebdf2adf95f"
 }