@wix/himalaya-cli 0.1507.0 → 0.1509.0

package/guides/capabilities.md

@@ -123,6 +123,35 @@ capabilityEnvelope: ["push", "camera"],
   `Rive` render through a native module, so the app must declare the capability that links
   it. See [Components that need a capability](#components-that-need-a-capability).
 
+### App services: `app_services`
+
+`app_services` is a **bridge** capability, like `wix_api` and `stream`: it has no `capability.*`
+verbs and no native footprint. A screen worker that calls `app.read` / `app.dispatch` from
+`@himalaya/state` reaches the app's own services across two dedicated worker bridges, and the
+screen that runs that bundle must declare it:
+
+```jsonc
+"logicBundle": { "url": "…/v1/bundles/jobs_home", "declaredCapabilities": ["app_services"] }
+```
+
+- **The screen declaration is enough.** The screen's declaration is what puts `app_services` into
+  the release's host requirements, so the app need not list it in `config.ts` `capabilities`, and
+  `himi validate` does not ask it to. A host binary that serves app services must list it in its
+  own config. An HHP app declares it in `config.ts` instead, because HHP copies that list onto
+  every screen; listing it there is never flagged.
+- **Checked from the built bundle.** `himi validate` sees the bridge names
+  (`__himalaya_app_read`, `__himalaya_app_dispatch`) in a built screen bundle, and so does a plain
+  `dispatch("app.<service>.<action>")` with a literal id, which is gated the same way. A bundle doing
+  either that no screen running it declares `app_services` for gets the same undeclared-capability
+  finding as any other call. The app bundle that *defines* the services, and an `app.*` action id written in
+  a descriptor, are not screen-worker calls and are never flagged.
+- **Not in any shell yet.** No shipped binary — Himi Player included — serves the app-service
+  bridges yet, so `himi capabilities app_services` lists no shell that serves it, and a
+  `himi dist` build cannot add it (a bridge capability belongs to the shell that hosts it).
+  Using app services also needs an app whose minimum binary version ships them. `himi validate`
+  reports that gate for a screen that declares `app_services` or calls `app.read` / `app.dispatch`.
+  A plain `dispatch("app.…")` reaches it through the declaration the finding above asks for.
+
 ### Local database and tenant switches
 
 On native hosts `local_database` is also scoped by the host's active tenant. On a multi-tenant host such as Himi Player, a worker is stamped with the tenant that was active when its boot started. The

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@wix/himalaya-cli",
-  "version": "0.1507.0",
+  "version": "0.1509.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": "9dc5e59ce68dd5d91e8e4618f90faf1cbb7ddb11ef0532104b244413"
+  "falconPackageHash": "e93a43678d27c6109e94db0df1cbc5d530447037d1ba12bc431c73cc"
 }