@wix/himalaya-cli 0.1014.0 → 0.1016.0

package/guides/component-reference.json

@@ -950,7 +950,7 @@
           ]
         }
       ],
-      "propsSource": "export interface RatingProps {\n  value?: number;\n  max?: number;\n  interactive?: boolean;\n  onChange?: Action;\n  color?: TokenName;\n  icon?: IconRef;\n  valuePath?: string;\n}"
+      "propsSource": "export interface RatingProps {\n  value?: number;\n  max?: number;\n  interactive?: boolean;\n  onChange?: Action;\n  color?: TokenName;\n  icon?: IconRef;\n  valuePath?: string;\n  /** Star size. `\"sm\"` is the compact size for dense rows — a star tally sharing a row\n   *  with a tag and a meta line, where the default stars crowd the text into wrapping.\n   *  It draws 16pt cells with a 14pt glyph, 2pt apart, identically on every platform.\n   *  Leave it unset (or `\"md\"`) for the standard size, unchanged from before `size`\n   *  existed. `\"sm\"` is meant for display rows; an interactive rating still works at\n   *  it, but its tap targets shrink with it. */\n  size?: \"sm\" | \"md\";\n}"
     },
     {
       "name": "Chart",

package/guides/component-reference.md

@@ -1473,6 +1473,13 @@ export interface RatingProps {
   color?: TokenName;
   icon?: IconRef;
   valuePath?: string;
+  /** Star size. `"sm"` is the compact size for dense rows — a star tally sharing a row
+   *  with a tag and a meta line, where the default stars crowd the text into wrapping.
+   *  It draws 16pt cells with a 14pt glyph, 2pt apart, identically on every platform.
+   *  Leave it unset (or `"md"`) for the standard size, unchanged from before `size`
+   *  existed. `"sm"` is meant for display rows; an interactive rating still works at
+   *  it, but its tap targets shrink with it. */
+  size?: "sm" | "md";
 }
 ```
 
@@ -2509,12 +2516,21 @@ The verb decides what happens to the navigation stack. Where there is a target s
 | `snackbar` | Show a transient message from `args`: `message` (required) and `tone`. No `screenId`. |
 
 A Close or Done button is a descriptor action: `{ "actionId": "himi.open", "presentation": "dismiss" }`
-(or `"back"`). Two limits to know before you design a flow around them:
-
-- **No action switches tabs.** A `himi.open` whose target is another tab's root screen PUSHES
-  that screen onto the current tab's stack; it does not select the other tab. Only the tab bar
-  and other app chrome select a tab.
-- **A worker can only push.** A worker action that returns `_nav` (`navigate()` from
-  `@himalaya/state`, see `himi docs tier-5-add-a-screen`) opens a linkable screen as a
-  `push`. There is no `_nav` form of `back` or `dismiss`: put those verbs on a descriptor
-  action.
+(or `"back"`).
+
+A worker moves the user by returning `_nav` from an action (`navigate()` from
+`@himalaya/state`, see `himi docs tier-5-add-a-screen`). `_nav` takes exactly one of three forms:
+
+| `_nav` | Effect |
+|---|---|
+| `{ screenId, args?, presentation? }` | Open a linkable screen. `presentation` is `push` (the default), `replace`, `sheet` or `full_screen`, as in the table above. |
+| `{ presentation: "back" }` / `{ presentation: "dismiss" }` | As in the table above. No target. |
+| `{ tab: "<tabId>" }` | Switch to that tab: a `tabBar` item, or a sidebar-rail item on a wide layout. Any open sheet or cover closes first. An id the app is not showing (unknown, hidden, or no tab bar / rail at all) is ignored, and so is the tab the user is already on: its stack is kept, not popped to its root. |
+
+A `_nav` that mixes forms (a `tab` with a `screenId`, `back` with a `screenId`) is ignored.
+
+- **Switching tabs is a worker `_nav`.** A `himi.open` whose target is another tab's root
+  screen does not select that tab: it PUSHES the screen onto the current tab's stack.
+- **A tab switch is not a stack step.** After one, `back` pops the new tab's stack; it does not
+  return to the previous tab. On web the switch is also a browser-history entry, so the
+  browser's own Back button returns to the previous tab.

package/guides/designing-himi-screens.md

@@ -243,9 +243,9 @@ scroll. *Reach for `SegmentedControl` for 2–4 in-content modes; `Tabs`/tab-bar
 contextual actions/detail; `Tooltip`/`Popover` for a small anchored hint. *Reach for `Snackbar`, not
 `AlertDialog`, to confirm a completed action — don't block on success.*
 
-**Status & data-viz** — `Badge`/`Tag`/`Chip` for compact labels; `Rating` for stars; `ProgressBar` for
-determinate progress, `ActivityIndicator` for indeterminate; `Gauge` for a single dial metric. *Use a
-`Badge` for a count, a `Tag` for a category — they aren't interchangeable.*
+**Status & data-viz** — `Badge`/`Tag`/`Chip` for compact labels; `Rating` for stars (`size: "sm"` in a
+dense row); `ProgressBar` for determinate progress, `ActivityIndicator` for indeterminate; `Gauge` for
+a single dial metric. *Use a `Badge` for a count, a `Tag` for a category — they aren't interchangeable.*
 
 **Media** — `Image` (`fillWidth`, `height`, always `contentDescription`); `Video`/`Lottie`/`Rive` for
 motion media; `Map` for location; `Avatar` for a person; `WebView` only when native can't express it.
@@ -289,7 +289,9 @@ build/validate/render cycles because the failure looks like a content bug rather
   `Card` rows, a `weight`ed `Text` can resolve to **zero width** on the web renderer and then wrap
   **one character per line** — the same visual signature as a too-narrow column, so it reads as a
   data problem. The reliable pattern is `fillMaxWidth: true` on the row *and* on the text inside it;
-  reach for `weight` only when two siblings must divide a row in a fixed ratio.
+  reach for `weight` only when two siblings must divide a row in a fixed ratio. When the row also
+  carries a star `Rating` next to a tag and a meta line, the full-size stars are often what squeezes
+  the text: give the `Rating` `size: "sm"` (16pt cells, 2pt apart) before dropping content from the row.
 - **`Alignment` is `leading | center | trailing` — there are no corner values.** There is no
   vertical axis and no `topTrailing`: an `HStack`'s cross-axis start is `leading`, which reads as
   "top". A wishlist heart authored as a top-right overlay therefore lands **center-right**. For a

package/guides/headless-loop.md

@@ -79,15 +79,20 @@ loop already makes the pictures — send them, and journal each one:
 ```sh
 himi render home --png shots/home.png --device iphone                    # the first picture, right after init
 himi studio                                                              # the build board: opens once, keeps itself current
+himi run --watch &                                                       # live preview: repaints the open tab on every save
 himi progress "Starting from branded-lite" --step implement --image shots/home.png
 himi render home --png shots/home-dark.png --device iphone --scheme dark
 himi progress "Your brand, light and dark" --step brand --image shots/home.png --image shots/home-dark.png
 himi progress                                                            # the journal: current step, elapsed, every postcard
+himi studio reel                                                         # at handover: the making-of, one self-contained file
 ```
 
 `himi studio` writes `.himi/studio/index.html` and opens it; from then on every render, test,
 validate, push and progress entry refreshes it, and the page picks that up by itself — no server,
-nothing to re-run (`--no-open` prints its path instead, for SSH). `himi test` writes one PNG per
+nothing to re-run (`--no-open` prints its path instead, for SSH). `himi run --watch` rebuilds on every
+save and sends the open tab only what changed; a save that does not build keeps the last good preview
+on screen and prints `build_failed` with the reason. It stays up until you stop it, so start it in the
+background, and only after the template's startup requests are preflighted (step 4 of the entry skill). `himi test` writes one PNG per
 screen to `.himi/shots/` on every run, so take the new screens from there instead of rendering each
 one again; a bare `--png` on `himi render` writes `.himi/shots/<id>.png`. `himi progress` copies each image into `.himi/history/`
 as it was when you journaled it, so a later render cannot change what the record says the owner saw;

package/guides/sdk-reference.json

@@ -36,14 +36,32 @@
       },
       {
         "name": "NavDirective",
+        "kind": "type",
+        "jsdoc": "/**\n * Navigation directive. An action may return its new state with a transient\n * `_nav` field; the runtime strips it from the stored state (so it never\n * persists or re-fires on the next spread) and surfaces it on the value\n * `__invokeAction` resolves to. The host reads it there and asks the app router\n * to move the user — to a screen ONLY if that screen is a linkable target, the same\n * check a `himi.open` action already gets.\n *\n * Three forms, one per kind of move: open a screen, go back / dismiss, or switch\n * tab. See {@link NavToScreen}, {@link NavBackOrDismiss} and {@link NavToTab}.\n *\n * WHY THIS EXISTS: all three hosts invoked a `tier5.*` action and threw the\n * result away, so a worker could change state but never move the user. A\n * generated (RFC 0046) row tap could therefore only *arm* an authored button —\n * two taps to open one record. The alternative was letting generated trees name\n * a screen, which would break the invariant that the model never names a screen,\n * a component or a token. With `_nav`, the model still only fires an allowlisted\n * `tier5.*` action id; the WORKER maps entity → screenId from its own table.\n */",
+        "decl": "export type NavDirective = NavToScreen | NavBackOrDismiss | NavToTab;"
+      },
+      {
+        "name": "NavToScreen",
+        "kind": "interface",
+        "jsdoc": "/**\n * Open a screen. `presentation` picks how: `push` (the default) onto the current tab's\n * stack, `replace` to show it in place of the current screen, or present it as a\n * `sheet` / `full_screen` modal.\n */",
+        "decl": "export interface NavToScreen {\n  /** Screen to open. Must be linkable, or the host ignores the directive. */\n  screenId: string;\n  /** Nav params for the target (e.g. the record `id`). Strings only. */\n  args?: Record<string, string>;\n  /** How to show it. Absent ⇒ `push`. */\n  presentation?: \"push\" | \"replace\" | \"sheet\" | \"full_screen\";\n  tab?: never;\n}"
+      },
+      {
+        "name": "NavBackOrDismiss",
         "kind": "interface",
-        "jsdoc": "/**\n * Navigation directive. An action may return its new state with a transient\n * `_nav` field; the runtime strips it from the stored state (so it never\n * persists or re-fires on the next spread) and surfaces it on the value\n * `__invokeAction` resolves to. The host reads it there and asks the app router\n * to open the screen — but ONLY if that screen is a linkable target, the same\n * check a `himi.open` action already gets.\n *\n * WHY THIS EXISTS: all three hosts invoked a `tier5.*` action and threw the\n * result away, so a worker could change state but never move the user. A\n * generated (RFC 0046) row tap could therefore only *arm* an authored button —\n * two taps to open one record. The alternative was letting generated trees name\n * a screen, which would break the invariant that the model never names a screen,\n * a component or a token. With `_nav`, the model still only fires an allowlisted\n * `tier5.*` action id; the WORKER maps entity → screenId from its own table.\n */",
-        "decl": "export interface NavDirective {\n  /** Screen to open. Must be linkable, or the host ignores the directive. */\n  screenId: string;\n  /** Nav params for the target (e.g. the record `id`). Strings only. */\n  args?: Record<string, string>;\n}"
+        "jsdoc": "/**\n * Leave the current screen. `back` pops the current stack. On iOS and Android, inside an\n * open sheet or cover it pops the modal's own stack and closes the modal at its root; on\n * web it pops the tab's stack, so close a modal with `dismiss`. `dismiss` closes the open\n * sheet / full-screen cover. Both are no-ops with nothing to leave. No target: the host\n * already knows where \"back\" is.\n */",
+        "decl": "export interface NavBackOrDismiss {\n  presentation: \"back\" | \"dismiss\";\n  screenId?: never;\n  args?: never;\n  tab?: never;\n}"
+      },
+      {
+        "name": "NavToTab",
+        "kind": "interface",
+        "jsdoc": "/**\n * Switch to the top-level destination with this id — a tab-bar item, or a sidebar-rail\n * item on a wide layout. The host closes any open sheet first. An id the app is not\n * showing right now (unknown, or hidden by the nav worker) is ignored, and so is the tab\n * the user is already on (their stack is kept — it is not a re-tap). A tab switch is not a\n * stack operation: a later `back` pops the NEW tab's stack, not the switch.\n */",
+        "decl": "export interface NavToTab {\n  tab: string;\n  screenId?: never;\n  args?: never;\n  presentation?: never;\n}"
       },
       {
         "name": "navigate",
         "kind": "function",
-        "jsdoc": "/**\n * Attach a {@link NavDirective} to a state object an action returns. Sugar for\n * `{ ...state, _nav: { screenId, args } }` that keeps the field name in one place.\n */",
+        "jsdoc": "/**\n * Attach a {@link NavDirective} to a state object an action returns. Sugar for\n * `{ ...state, _nav: target }` that keeps the field name in one place.\n *\n * `target` is exactly ONE of three forms — `{ screenId, args?, presentation? }`,\n * `{ presentation: \"back\" | \"dismiss\" }`, or `{ tab }`. A directive that mixes them\n * (a `tab` with a `screenId`, say) is dropped by every host.\n */",
         "decl": "export function navigate<S extends object>(\n  state: S,\n  target: NavDirective,\n): S & { _nav: NavDirective };"
       },
       {
@@ -16730,7 +16748,19 @@
         "name": "ConversationMessage",
         "kind": "interface",
         "jsdoc": "",
-        "decl": "export interface ConversationMessage {\n  id?: string;\n  content?: string;\n  role?: MessageRole;\n  createdDate?: string;\n  status?: MessageStatus;\n}"
+        "decl": "export interface ConversationMessage {\n  id?: string;\n  content?: string;\n  role?: MessageRole;\n  createdDate?: string;\n  status?: MessageStatus;\n  /** Client tools this assistant turn asks the CALLER to run — see `FunctionCall`. */\n  functionCalls?: FunctionCall[];\n}"
+      },
+      {
+        "name": "FunctionCall",
+        "kind": "interface",
+        "jsdoc": "/** A client-side tool the assistant wants the caller to run before it can go on\n *  — asking the owner for consent, say. It arrives on the `/user-message`\n *  response and the agent then WAITS: nothing more is written until the result\n *  comes back through `sendFunctionCallResults`.\n *\n *  Shape from the chat-service's generated client (`wix.genie.v1` `FunctionCall`\n *  / `FunctionCallResult`), which the native Aria app and the React Native\n *  dashboard assistant both drive; NOT captured from this client's own traffic,\n *  because no hermetic account can make the agent ask for a tool on demand. */",
+        "decl": "export interface FunctionCall {\n  /** Matches the result to the call. Copied back verbatim. */\n  id?: string;\n  /** The function's name. Also copied back. */\n  name?: string;\n  /** A JSON-ENCODED object — a string on the wire, not a nested object. */\n  arguments?: string;\n}"
+      },
+      {
+        "name": "FunctionCallResult",
+        "kind": "interface",
+        "jsdoc": "/** The answer to one `FunctionCall`. Note the wire spells the flag `success`. */",
+        "decl": "export interface FunctionCallResult {\n  id?: string;\n  name?: string;\n  /** Text for the model — the error text when `success` is false. */\n  content?: string;\n  success?: boolean;\n  /** A JSON-ENCODED object carrying the tool's structured answer. */\n  widgetResponse?: string;\n}"
       },
       {
         "name": "AssistantConfig",
@@ -16766,7 +16796,7 @@
         "name": "SendMessageResponse",
         "kind": "interface",
         "jsdoc": "",
-        "decl": "export interface SendMessageResponse {\n  assistantMessages?: ConversationMessage[];\n  conversationMessage?: ConversationMessage;\n  /** The user's own turn AS STORED by the service — present on step 1's reply\n   *  (`conversationUserMessage`), which is where the id actually comes from. */\n  userMessage?: ConversationMessage;\n  /** The id the owner's turn was stored under, carried out by `sendMessage`.\n   *\n   *  The only handle the abort route accepts, and there is no route that looks\n   *  it up afterwards — so a caller that wants to stop the reply has to keep it\n   *  from the send. `sendMessage` resolves with step 2's response, which does\n   *  NOT carry `userMessage`, so this field is the one reliable source; read it\n   *  through `userMessageIdOf` rather than directly. */\n  userMessageId?: string;\n}"
+        "decl": "export interface SendMessageResponse {\n  assistantMessages?: ConversationMessage[];\n  conversationMessage?: ConversationMessage;\n  /** The user's own turn AS STORED by the service — present on step 1's reply\n   *  (`conversationUserMessage`), which is where the id actually comes from. */\n  userMessage?: ConversationMessage;\n  /** The id the owner's turn was stored under, carried out by `sendMessage`.\n   *\n   *  The only handle the abort route accepts, and there is no route that looks\n   *  it up afterwards — so a caller that wants to stop the reply has to keep it\n   *  from the send. `sendMessage` resolves with step 2's response, which does\n   *  NOT carry `userMessage`, so this field is the one reliable source; read it\n   *  through `userMessageIdOf` rather than directly. */\n  userMessageId?: string;\n  /** Client tools the agent is waiting on. Read through `functionCallsOf`: the\n   *  service can also nest them on the first assistant message. */\n  functionCalls?: FunctionCall[];\n}"
       },
       {
         "name": "AbortAssistantMessageGenerationResponse",
@@ -16828,6 +16858,12 @@
         "jsdoc": "/** Step 2 of sending a turn on its own: ask the agent to answer a user message\n *  that `conversationUserMessage` has ALREADY stored.\n *\n *  Exported because it is the only safe retry when step 2 is the half that\n *  failed — see `sendMessage`, which attaches the id to its error for exactly\n *  this call. Carries no content: the turn it names is the content. */",
         "decl": "export function triggerAssistantMessage(\n  conversationId: string,\n  userMessageId: string,\n  opts: SendMessageOptions = {},\n): Promise<SendMessageResponse>;"
       },
+      {
+        "name": "sendFunctionCallResults",
+        "kind": "function",
+        "jsdoc": "/** Answer the client tools a `/user-message` response asked for, and let the\n *  agent carry on.\n *\n *  The SAME route as the trigger, with a different body: no content and no\n *  `userMessageId` — the results ARE the turn. The response has the shape of any\n *  other send, so it can carry the NEXT round of `functionCalls`; a caller loops\n *  until one comes back without any (see `functionCallsOf`).\n *\n *  Nothing here decides what a tool does or whether the owner agreed to it. That\n *  is the caller's, and it is the part that has to be right: a result that says\n *  `userConsent: true` is the owner's signature on whatever the agent does next. */",
+        "decl": "export function sendFunctionCallResults(\n  conversationId: string,\n  results: FunctionCallResult[],\n  opts: SendMessageOptions = {},\n): Promise<SendMessageResponse>;"
+      },
       {
         "name": "abortAssistantMessageGeneration",
         "kind": "function",
@@ -16852,6 +16888,12 @@
         "jsdoc": "/** The id of the user turn a send response stored, or \"\" when the service did\n *  not name one. Empty is a real answer, not a parse failure: it means this turn\n *  cannot be aborted, and a caller must degrade rather than send `undefined` to\n *  the abort route. */",
         "decl": "export function userMessageIdOf(res: SendMessageResponse | null | undefined): string;"
       },
+      {
+        "name": "functionCallsOf",
+        "kind": "function",
+        "jsdoc": "/** The client tools a send response is waiting on, or `[]`.\n *\n *  Under either of the two places the service puts them: nested on the FIRST\n *  assistant message when that carries any, otherwise top-level. That order is\n *  the one both native Aria clients read, and it matters when both are present —\n *  the nested set is the one the agent is actually blocked on. */",
+        "decl": "export function functionCallsOf(res: SendMessageResponse | null | undefined): FunctionCall[];"
+      },
       {
         "name": "conversationIdOf",
         "kind": "function",

package/guides/tier-5-add-a-screen.md

@@ -675,29 +675,56 @@ save: async (s) => {
 
 The runtime strips `_nav` before the state is stored, and the host opens `screenId` exactly as
 a tapped `himi.open` would — including the `args` arriving as `himalaya.input` on the target.
+
+`_nav` takes **exactly one** of three forms:
+
+| `_nav` | What the host does |
+|---|---|
+| `{ screenId, args?, presentation? }` | Opens the screen. `presentation` is `push` (the default), `replace`, `sheet` or `full_screen` — the same verbs a descriptor action uses. |
+| `{ presentation: "back" }` or `{ presentation: "dismiss" }` | `back` pops the current screen; `dismiss` closes the open sheet or full-screen cover. No target. |
+| `{ tab: "<tabId>" }` | Switches to that tab — a `tabBar` item, or a sidebar-rail item on a wide layout. |
+
+```ts
+cancel: (s) => navigate({ ...s, draft: null }, { presentation: "dismiss" }),
+viewOrders: (s) => navigate(s, { tab: "orders" }),
+```
+
 The rules:
 
 - `screenId` must be a **linkable** screen (`navigation.linkableScreens`), or the host
   ignores the directive.
 - `args` values are **strings only**; anything else is dropped rather than coerced.
-- It always **pushes**. There is no `_nav` form of `back`, `dismiss`, `sheet` or `replace`.
+- A directive that mixes forms — a `tab` with a `screenId`, `back` with a `screenId`, `back`
+  with `args` — or names a verb outside its form (`alert`, `snackbar`) is **ignored** and
+  logged as `nav_verb_dropped`.
 
-`_nav` is the worker-side navigation all three hosts route. A worker's
-`dispatch("himi.open", …)` is routed by the web host's nav bridge only; on iOS and Android a
-worker `dispatch` reaches the native action registry, which has no `himi.open` handler.
+Return `_nav` rather than calling `dispatch("himi.open", …)` from a worker. Current runtimes
+route a worker's `himi.open` dispatch on all three hosts, but older iOS and Android binaries
+send it to the native action registry, which has no `himi.open` handler, so it does nothing
+there; `_nav` works on every binary.
 
 #### Back, dismiss, and tabs
 
-Everything that is not a push is a **descriptor** action with a `presentation` verb — a Close
-or Done button is `{ "actionId": "himi.open", "presentation": "dismiss" }` (or `"back"`). The
-component reference tabulates every verb (`himi components --json`, or the Actions section of
+A Close or Done button is a **descriptor** action with a `presentation` verb —
+`{ "actionId": "himi.open", "presentation": "dismiss" }` (or `"back"`). The component reference
+tabulates every verb (`himi components --json`, or the Actions section of
 `himi docs component-reference`): `back` pops the current screen, `dismiss` closes a presented
-sheet or cover.
-
-**No action switches tabs.** A `himi.open` — tapped or from `_nav` — whose target is another
-tab's root screen pushes that screen onto the *current* tab's stack; it does not select the
-other tab. Only the tab bar and other app chrome select a tab, so design a cross-tab jump as a
-push of the detail you want, not as a hop to the other tab's root.
+sheet or cover. From a worker, return the same verbs as `_nav` (above).
+
+**Switching tabs is a worker `_nav`.** Return `_nav: { tab: "<tabId>" }`. A `himi.open` whose
+target is another tab's root screen does not select that tab — it pushes the screen onto the
+*current* tab's stack. How a tab switch behaves:
+
+- Any open sheet or full-screen cover closes first, then the tab is selected, showing
+  whatever that tab's stack last held.
+- An id the app is not showing right now — unknown, hidden by the nav worker, or any id when
+  the app has no tab bar or sidebar rail (`single` / `drawer` navigation) — is ignored and
+  logged as `nav_verb_dropped`. The user stays where they are.
+- Asking for the tab the user is already on does nothing. It does **not** pop that tab to its
+  root the way a second tap on the tab bar does.
+- A tab switch is not a step on a stack: a later `back` pops the **new** tab's stack and does
+  not return to the previous tab. On web the switch is also a browser-history entry, so the
+  browser's own Back button returns to the previous tab; iOS and Android have no equivalent.
 
 ### Enumerable variants with `FragmentSlot` (RFC 0045)
 

package/guides/wix-api-usage.md

@@ -7,6 +7,15 @@ endpoints without a generated client, the **raw `wixApi` chokepoint** (L0). Star
 It's **platform-agnostic**: the worker JS is identical on iOS, Android, macOS, and web — each host installs the
 same `globalThis.himalaya.wixApi.call(method, path, body)` bridge over `WixApiCapability`.
 
+On web the host normally routes the call through a same-origin `/v1/__webwix/call` bridge, which attaches
+the current visitor, member or owner credential. Keep `path`
+**relative** — it resolves against `https://www.wixapis.com` on every surface. The published web app's bridge
+refuses every absolute URL (an account host such as `users.wix.com` is reachable natively, not on web). The
+local development bridge is looser on its visitor/member path: it accepts an absolute `https:` URL on a host
+under `wix.com`, `wixapis.com` or `nownia.com` (subdomains included) and refuses any other host before a
+request is sent — so an absolute URL that works in local preview can still fail once published. This bridge
+is separate from the dev network gateway, which is the broader proxy/mock surface.
+
 <!-- Heading kept free of `@`, `/` and `*`: GitHub's slugger DELETES those, md.mjs collapses each
      run to a hyphen, so punctuation here makes the two anchors disagree and whichever surface the
      author did not test gets a link to nowhere. That already happened — wix-sdk-overview.md cited

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@wix/himalaya-cli",
-  "version": "0.1014.0",
+  "version": "0.1016.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": [
@@ -65,5 +65,5 @@
       "artifactId": "himalaya-cli"
     }
   },
-  "falconPackageHash": "18405dc60f540308524da075bbb12c054da8e06b44e0fcdabaf2e2b0"
+  "falconPackageHash": "8d9c295e5bb131686c4267b1ca8dee02e1722595723466ab792c6e83"
 }