@wix/himalaya-cli 0.1338.0 → 0.1339.0

package/dist/cli.mjs

@@ -16630,7 +16630,6 @@ function resolveIdiom(tokens2, ctx = {}) {
 var IDIOM_CONTEXTS, UNSAFE_KEYS;
 var init_idiom = __esm({
   "../../core/ts/src/idiom.ts"() {
-    "use strict";
     IDIOM_CONTEXTS = {
       ios: { native: ["ios"] },
       android: { native: ["material"] },

package/guides/web-page-native-sdk.md

@@ -39,6 +39,12 @@ Your page can only use capabilities the **app owner** turned on for your site. I
   `capabilities`, allowing **every** method the capability's page lists — except
   `presigned_upload.putFile`, which reads a device file and is allowed only when `files` is enabled
   too. So enabling a capability is enough; the owner does not list methods.
+- **What a Brandy app cannot enable:** `app_info`, `calls`, `godot`, `himi_apps`, `live_activity`,
+  `local_database`, `release_control`, `system_intents`, `ui` and `wix_platform` — most need wiring
+  a website app's shell does not have, and `calls` waits on a third-party sign-off for its WebRTC
+  engine, so plan your page without them. `base44` works only when the
+  app also has a Base44 binding. Every other capability in the reference can be enabled; other Himi
+  apps (not Brandy) may offer these too.
 - Enabling a capability changes the app's native permissions, so the owner ships a **new app
   build** with it before your page can call it. Until then the call times out.
 
@@ -394,7 +400,7 @@ Codes other than the first three come from the capability itself; its reference
     // What the app answers when the page asks which capabilities it may call.
     "himalaya.capabilities": { v: 1, capabilities: { health: ["availability", "query", "requestPermission"], haptic: ["play"] } },
     "health.availability": { available: true },
-    "health.requestPermission": undefined,
+    "health.requestPermission": { granted: ["steps"] },
     "health.query": { samples: [{ value: 4200 }] },
     "haptic.play": undefined,
   };
@@ -417,11 +423,20 @@ Codes other than the first three come from the capability itself; its reference
 Each uses the client from Step 1. The exact types are on each capability's page (see *Reference*).
 
 ```ts
-import { call, himalaya } from "./lib/himalaya";
-
-// Share a link through the phone's share sheet (from a tap). The sheet waits for the user: allow two minutes.
-// Outside the app, fall back to the browser's own share (or copy the link).
-const { completed } = await call<{ completed: boolean }>("share", "share", [{ text: "Join me on Friday", url: "https://example.com/e/42" }], 120_000);
+import { call, himalaya, isEnabled } from "./lib/himalaya";
+
+// Share a link (from a tap): the phone's share sheet inside the app, the browser's own share outside
+// it, and a copied link where neither exists. The sheet waits for the user: allow two minutes.
+const link = { text: "Join me on Friday", url: "https://example.com/e/42" };
+if (await isEnabled("share", "share")) {
+  await call<{ completed: boolean }>("share", "share", [link], 120_000); // completed: false when cancelled
+} else if (navigator.share) {
+  await navigator.share(link).catch(() => {}); // rejects with AbortError when the user closes the sheet
+} else {
+  // The clipboard can be missing or refused (e.g. on plain http): then show the link to copy by hand.
+  const copied = await navigator.clipboard?.writeText(link.url).then(() => true, () => false);
+  if (!copied) window.prompt("Copy this link", link.url);
+}
 
 // Where am I? Ask first, then read once. getCurrent answers null when no fix arrives in time.
 const status = await call("location", "requestPermission", [], 120_000);

package/guides/webview-page-sdk.md

@@ -87,8 +87,8 @@ binary. One app-specific worker imports exactly the app’s selected subset.
 
 ## Brandy
 
-Name the capabilities; Brandy supplies the companion worker. Health has a hand-written proof
-worker:
+Name the capabilities; Brandy supplies the companion worker, so neither the page author nor the
+app owner writes one. Health's is ready-made:
 
 ```json
 {
@@ -116,13 +116,15 @@ and allowlists every method a page can call on them (the methods each `web-sdk/<
 }
 ```
 
-Preparing the customer build (`npm run prepare:customer`) writes and builds it; for local
-previews, run `npm run web-sdk:companion` first. To expose fewer methods, write your own
-companion and name it in `bundle` — a named bundle is used as is.
+The app's customer build writes and builds it. (Inside the Himi repository that is
+`npm run prepare:customer -w @apps/himi-brandy`; for a local preview,
+`npm run web-sdk:companion -w @apps/himi-brandy` first.) To expose
+fewer methods, write your own companion and name it in `bundle` — a named bundle is used as is.
 
 Brandy accepts capabilities `himi dist` can add to an extensible shell. Capabilities requiring
-app-specific boot wiring remain refused until that shell supplies the wiring. Base44 is accepted
-only when the same Brandy contract contains a Base44 binding.
+app-specific boot wiring remain refused until that shell supplies the wiring — the list is in
+[the web page guide](https://apps.wix.com/_api/himi-serve/docs/web-page-native-sdk.md#before-you-start-what-the-app-owner-must-enable).
+Base44 is accepted only when the same Brandy contract contains a Base44 binding.
 
 ## Security and current transport boundary
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@wix/himalaya-cli",
-  "version": "0.1338.0",
+  "version": "0.1339.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": "6c47db9919054dae107b64d10581ed667ba8e7daaf3cea349e1ed889"
+  "falconPackageHash": "bcfe44cf5aea10286d209c5f29feefad31023f7e7984e176976925d3"
 }