@wix/himalaya-cli 0.840.0 → 0.842.0

package/guides/cms-collections.md

@@ -86,7 +86,7 @@ schema for humans and `himi validate`, but does not grant or enable that read.
 
 `himi cms query --all` labels every collection on the site `owned`, `adopted`, or
 `foreign`, so the blast radius is visible before you run anything. (Without `--all`
-it reads only the ids you declare — see [below](#himi-cms-query--read-only).)
+it reads only the ids you declare — see [below](#himi-cms-query-read-only).)
 
 ### `site analyze --apply` adopts, it never claims
 
@@ -287,7 +287,7 @@ himi push --draft                  # ship the content package; does NOT touch th
 declares and points you back here — provisioning a backend as a side effect of
 publishing a release is exactly the surprise this design avoids.
 
-### `himi cms query` — read-only
+### `himi cms query`: read-only
 
 **By default it reads only the ids you declared.** One targeted `GET` per declared
 collection, and the report says so with `siteScanned: false`. You get item counts and

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@wix/himalaya-cli",
-  "version": "0.840.0",
+  "version": "0.842.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": [
@@ -63,5 +63,5 @@
       "artifactId": "himalaya-cli"
     }
   },
-  "falconPackageHash": "3cc7ad5aafc738871bc07293ce79f445509b78f308bb192a30fb8a3a"
+  "falconPackageHash": "b45ead5f2fb4dcd64fd4c31516607200700f0f8e9a1926efb5d6a6e2"
 }

package/templates/beauty-salon-owner/tier5-src/himi-owner-lite-aria/index.ts

@@ -186,5 +186,33 @@ const svc = defineService<AriaChatState, {
   },
 });
 
-svc.load();
+// NO module-scope `svc.load()`, deliberately — the descriptor's `onAppear` is the
+// only entry point, and on Android the self-kick did not merely duplicate it, it
+// DISABLED the screen.
+//
+// `load` opens by creating a conversation, so a self-kick puts a `wixApi.call`
+// inside the bundle's own evaluation — and a bridge call made during
+// `worker.boot(bundle)` stalls on the Android WebView. The host completes it
+// (`bridge_wix_call … ok=true` is logged between `bundle eval done` and
+// `services=[…]`) but the JS promise never settles. `createOnce` then caches that
+// promise as the per-site create latch, so the `onAppear` load — dispatched
+// correctly, and fine on its own — awaits the same dead promise and never returns
+// either. Result on Android: no greeting, no prompt chips, no conversation, and a
+// Send that does nothing, for the life of the screen. Nothing reports it, because
+// a pending dispatch has no timeout: an action that never settles is
+// indistinguishable from one still running (#2518).
+//
+// That stall is a known Android defect, not a new one. `WebViewJSWorker` already
+// prepends per-screen input into the bundle's own evaluate rather than assigning it
+// separately, and says why: "the bundle's first wixApi.call could stall". Aria is
+// simply the first owner-lite screen to call the network at module scope and so the
+// first to meet it head-on. Fixing the stall is a core-runtime change tracked
+// separately; not calling the network before the screen exists is right regardless.
+//
+// The self-kick was never load-bearing. Both hosts queue a `tier5.*` action
+// dispatched before the worker is up — `Tier5WorkerSession.invoke` on Android and
+// `HimalayaScreenHost.dispatch` on iOS — and both say in as many words that the
+// self-kick is what made `onAppear` only LOOK like it worked. It also cost a
+// second conversation-create attempt per open and minted the greeting with
+// fallback copy, since the copy pack only arrives with the onAppear params.
 export { svc };

package/templates/beauty-salon-owner/tier5-src/himi-owner-lite-aria-history/index.ts

@@ -38,5 +38,14 @@ const svc = defineService<AriaHistoryState, {
   },
 });
 
-svc.load();
+// NO module-scope `svc.load()` — same reason as the chat adapter next door, which
+// carries the full explanation. This `load` opens with `getConversations`, so a
+// self-kick makes a bridge call inside the bundle's own evaluation, and such a call
+// stalls on the Android WebView (#2518).
+//
+// It is less damaging here than on the chat screen: this load has no create latch
+// for a dead promise to poison, so the `onAppear` load issues its own request and
+// the list still fills. What the self-kick leaves behind is a dispatch that never
+// settles — `pendingDispatches` has no timeout, so it is held for the life of the
+// worker, on every open. Not worth keeping for a call whose result nothing reads.
 export { svc };

package/templates/community-club-owner/tier5-src/himi-owner-lite-aria/index.ts

@@ -186,5 +186,33 @@ const svc = defineService<AriaChatState, {
   },
 });
 
-svc.load();
+// NO module-scope `svc.load()`, deliberately — the descriptor's `onAppear` is the
+// only entry point, and on Android the self-kick did not merely duplicate it, it
+// DISABLED the screen.
+//
+// `load` opens by creating a conversation, so a self-kick puts a `wixApi.call`
+// inside the bundle's own evaluation — and a bridge call made during
+// `worker.boot(bundle)` stalls on the Android WebView. The host completes it
+// (`bridge_wix_call … ok=true` is logged between `bundle eval done` and
+// `services=[…]`) but the JS promise never settles. `createOnce` then caches that
+// promise as the per-site create latch, so the `onAppear` load — dispatched
+// correctly, and fine on its own — awaits the same dead promise and never returns
+// either. Result on Android: no greeting, no prompt chips, no conversation, and a
+// Send that does nothing, for the life of the screen. Nothing reports it, because
+// a pending dispatch has no timeout: an action that never settles is
+// indistinguishable from one still running (#2518).
+//
+// That stall is a known Android defect, not a new one. `WebViewJSWorker` already
+// prepends per-screen input into the bundle's own evaluate rather than assigning it
+// separately, and says why: "the bundle's first wixApi.call could stall". Aria is
+// simply the first owner-lite screen to call the network at module scope and so the
+// first to meet it head-on. Fixing the stall is a core-runtime change tracked
+// separately; not calling the network before the screen exists is right regardless.
+//
+// The self-kick was never load-bearing. Both hosts queue a `tier5.*` action
+// dispatched before the worker is up — `Tier5WorkerSession.invoke` on Android and
+// `HimalayaScreenHost.dispatch` on iOS — and both say in as many words that the
+// self-kick is what made `onAppear` only LOOK like it worked. It also cost a
+// second conversation-create attempt per open and minted the greeting with
+// fallback copy, since the copy pack only arrives with the onAppear params.
 export { svc };

package/templates/community-club-owner/tier5-src/himi-owner-lite-aria-history/index.ts

@@ -38,5 +38,14 @@ const svc = defineService<AriaHistoryState, {
   },
 });
 
-svc.load();
+// NO module-scope `svc.load()` — same reason as the chat adapter next door, which
+// carries the full explanation. This `load` opens with `getConversations`, so a
+// self-kick makes a bridge call inside the bundle's own evaluation, and such a call
+// stalls on the Android WebView (#2518).
+//
+// It is less damaging here than on the chat screen: this load has no create latch
+// for a dead promise to poison, so the `onAppear` load issues its own request and
+// the list still fills. What the self-kick leaves behind is a dispatch that never
+// settles — `pendingDispatches` has no timeout, so it is held for the life of the
+// worker, on every open. Not worth keeping for a call whose result nothing reads.
 export { svc };

package/templates/events-meetups-owner/tier5-src/himi-owner-lite-aria/index.ts

@@ -186,5 +186,33 @@ const svc = defineService<AriaChatState, {
   },
 });
 
-svc.load();
+// NO module-scope `svc.load()`, deliberately — the descriptor's `onAppear` is the
+// only entry point, and on Android the self-kick did not merely duplicate it, it
+// DISABLED the screen.
+//
+// `load` opens by creating a conversation, so a self-kick puts a `wixApi.call`
+// inside the bundle's own evaluation — and a bridge call made during
+// `worker.boot(bundle)` stalls on the Android WebView. The host completes it
+// (`bridge_wix_call … ok=true` is logged between `bundle eval done` and
+// `services=[…]`) but the JS promise never settles. `createOnce` then caches that
+// promise as the per-site create latch, so the `onAppear` load — dispatched
+// correctly, and fine on its own — awaits the same dead promise and never returns
+// either. Result on Android: no greeting, no prompt chips, no conversation, and a
+// Send that does nothing, for the life of the screen. Nothing reports it, because
+// a pending dispatch has no timeout: an action that never settles is
+// indistinguishable from one still running (#2518).
+//
+// That stall is a known Android defect, not a new one. `WebViewJSWorker` already
+// prepends per-screen input into the bundle's own evaluate rather than assigning it
+// separately, and says why: "the bundle's first wixApi.call could stall". Aria is
+// simply the first owner-lite screen to call the network at module scope and so the
+// first to meet it head-on. Fixing the stall is a core-runtime change tracked
+// separately; not calling the network before the screen exists is right regardless.
+//
+// The self-kick was never load-bearing. Both hosts queue a `tier5.*` action
+// dispatched before the worker is up — `Tier5WorkerSession.invoke` on Android and
+// `HimalayaScreenHost.dispatch` on iOS — and both say in as many words that the
+// self-kick is what made `onAppear` only LOOK like it worked. It also cost a
+// second conversation-create attempt per open and minted the greeting with
+// fallback copy, since the copy pack only arrives with the onAppear params.
 export { svc };

package/templates/events-meetups-owner/tier5-src/himi-owner-lite-aria-history/index.ts

@@ -38,5 +38,14 @@ const svc = defineService<AriaHistoryState, {
   },
 });
 
-svc.load();
+// NO module-scope `svc.load()` — same reason as the chat adapter next door, which
+// carries the full explanation. This `load` opens with `getConversations`, so a
+// self-kick makes a bridge call inside the bundle's own evaluation, and such a call
+// stalls on the Android WebView (#2518).
+//
+// It is less damaging here than on the chat screen: this load has no create latch
+// for a dead promise to poison, so the `onAppear` load issues its own request and
+// the list still fills. What the self-kick leaves behind is a dispatch that never
+// settles — `pendingDispatches` has no timeout, so it is held for the life of the
+// worker, on every open. Not worth keeping for a call whose result nothing reads.
 export { svc };

package/templates/gym-fitness-owner/tier5-src/himi-owner-lite-aria/index.ts

@@ -186,5 +186,33 @@ const svc = defineService<AriaChatState, {
   },
 });
 
-svc.load();
+// NO module-scope `svc.load()`, deliberately — the descriptor's `onAppear` is the
+// only entry point, and on Android the self-kick did not merely duplicate it, it
+// DISABLED the screen.
+//
+// `load` opens by creating a conversation, so a self-kick puts a `wixApi.call`
+// inside the bundle's own evaluation — and a bridge call made during
+// `worker.boot(bundle)` stalls on the Android WebView. The host completes it
+// (`bridge_wix_call … ok=true` is logged between `bundle eval done` and
+// `services=[…]`) but the JS promise never settles. `createOnce` then caches that
+// promise as the per-site create latch, so the `onAppear` load — dispatched
+// correctly, and fine on its own — awaits the same dead promise and never returns
+// either. Result on Android: no greeting, no prompt chips, no conversation, and a
+// Send that does nothing, for the life of the screen. Nothing reports it, because
+// a pending dispatch has no timeout: an action that never settles is
+// indistinguishable from one still running (#2518).
+//
+// That stall is a known Android defect, not a new one. `WebViewJSWorker` already
+// prepends per-screen input into the bundle's own evaluate rather than assigning it
+// separately, and says why: "the bundle's first wixApi.call could stall". Aria is
+// simply the first owner-lite screen to call the network at module scope and so the
+// first to meet it head-on. Fixing the stall is a core-runtime change tracked
+// separately; not calling the network before the screen exists is right regardless.
+//
+// The self-kick was never load-bearing. Both hosts queue a `tier5.*` action
+// dispatched before the worker is up — `Tier5WorkerSession.invoke` on Android and
+// `HimalayaScreenHost.dispatch` on iOS — and both say in as many words that the
+// self-kick is what made `onAppear` only LOOK like it worked. It also cost a
+// second conversation-create attempt per open and minted the greeting with
+// fallback copy, since the copy pack only arrives with the onAppear params.
 export { svc };

package/templates/gym-fitness-owner/tier5-src/himi-owner-lite-aria-history/index.ts

@@ -38,5 +38,14 @@ const svc = defineService<AriaHistoryState, {
   },
 });
 
-svc.load();
+// NO module-scope `svc.load()` — same reason as the chat adapter next door, which
+// carries the full explanation. This `load` opens with `getConversations`, so a
+// self-kick makes a bridge call inside the bundle's own evaluation, and such a call
+// stalls on the Android WebView (#2518).
+//
+// It is less damaging here than on the chat screen: this load has no create latch
+// for a dead promise to poison, so the `onAppear` load issues its own request and
+// the list still fills. What the self-kick leaves behind is a dispatch that never
+// settles — `pendingDispatches` has no timeout, so it is held for the life of the
+// worker, on every open. Not worth keeping for a call whose result nothing reads.
 export { svc };

package/templates/nonprofit-cause-owner/tier5-src/himi-owner-lite-aria/index.ts

@@ -186,5 +186,33 @@ const svc = defineService<AriaChatState, {
   },
 });
 
-svc.load();
+// NO module-scope `svc.load()`, deliberately — the descriptor's `onAppear` is the
+// only entry point, and on Android the self-kick did not merely duplicate it, it
+// DISABLED the screen.
+//
+// `load` opens by creating a conversation, so a self-kick puts a `wixApi.call`
+// inside the bundle's own evaluation — and a bridge call made during
+// `worker.boot(bundle)` stalls on the Android WebView. The host completes it
+// (`bridge_wix_call … ok=true` is logged between `bundle eval done` and
+// `services=[…]`) but the JS promise never settles. `createOnce` then caches that
+// promise as the per-site create latch, so the `onAppear` load — dispatched
+// correctly, and fine on its own — awaits the same dead promise and never returns
+// either. Result on Android: no greeting, no prompt chips, no conversation, and a
+// Send that does nothing, for the life of the screen. Nothing reports it, because
+// a pending dispatch has no timeout: an action that never settles is
+// indistinguishable from one still running (#2518).
+//
+// That stall is a known Android defect, not a new one. `WebViewJSWorker` already
+// prepends per-screen input into the bundle's own evaluate rather than assigning it
+// separately, and says why: "the bundle's first wixApi.call could stall". Aria is
+// simply the first owner-lite screen to call the network at module scope and so the
+// first to meet it head-on. Fixing the stall is a core-runtime change tracked
+// separately; not calling the network before the screen exists is right regardless.
+//
+// The self-kick was never load-bearing. Both hosts queue a `tier5.*` action
+// dispatched before the worker is up — `Tier5WorkerSession.invoke` on Android and
+// `HimalayaScreenHost.dispatch` on iOS — and both say in as many words that the
+// self-kick is what made `onAppear` only LOOK like it worked. It also cost a
+// second conversation-create attempt per open and minted the greeting with
+// fallback copy, since the copy pack only arrives with the onAppear params.
 export { svc };

package/templates/nonprofit-cause-owner/tier5-src/himi-owner-lite-aria-history/index.ts

@@ -38,5 +38,14 @@ const svc = defineService<AriaHistoryState, {
   },
 });
 
-svc.load();
+// NO module-scope `svc.load()` — same reason as the chat adapter next door, which
+// carries the full explanation. This `load` opens with `getConversations`, so a
+// self-kick makes a bridge call inside the bundle's own evaluation, and such a call
+// stalls on the Android WebView (#2518).
+//
+// It is less damaging here than on the chat screen: this load has no create latch
+// for a dead promise to poison, so the `onAppear` load issues its own request and
+// the list still fills. What the self-kick leaves behind is a dispatch that never
+// settles — `pendingDispatches` has no timeout, so it is held for the life of the
+// worker, on every open. Not worth keeping for a call whose result nothing reads.
 export { svc };

package/templates/owner-lite/tier5-src/himi-owner-lite-aria/index.ts

@@ -186,5 +186,33 @@ const svc = defineService<AriaChatState, {
   },
 });
 
-svc.load();
+// NO module-scope `svc.load()`, deliberately — the descriptor's `onAppear` is the
+// only entry point, and on Android the self-kick did not merely duplicate it, it
+// DISABLED the screen.
+//
+// `load` opens by creating a conversation, so a self-kick puts a `wixApi.call`
+// inside the bundle's own evaluation — and a bridge call made during
+// `worker.boot(bundle)` stalls on the Android WebView. The host completes it
+// (`bridge_wix_call … ok=true` is logged between `bundle eval done` and
+// `services=[…]`) but the JS promise never settles. `createOnce` then caches that
+// promise as the per-site create latch, so the `onAppear` load — dispatched
+// correctly, and fine on its own — awaits the same dead promise and never returns
+// either. Result on Android: no greeting, no prompt chips, no conversation, and a
+// Send that does nothing, for the life of the screen. Nothing reports it, because
+// a pending dispatch has no timeout: an action that never settles is
+// indistinguishable from one still running (#2518).
+//
+// That stall is a known Android defect, not a new one. `WebViewJSWorker` already
+// prepends per-screen input into the bundle's own evaluate rather than assigning it
+// separately, and says why: "the bundle's first wixApi.call could stall". Aria is
+// simply the first owner-lite screen to call the network at module scope and so the
+// first to meet it head-on. Fixing the stall is a core-runtime change tracked
+// separately; not calling the network before the screen exists is right regardless.
+//
+// The self-kick was never load-bearing. Both hosts queue a `tier5.*` action
+// dispatched before the worker is up — `Tier5WorkerSession.invoke` on Android and
+// `HimalayaScreenHost.dispatch` on iOS — and both say in as many words that the
+// self-kick is what made `onAppear` only LOOK like it worked. It also cost a
+// second conversation-create attempt per open and minted the greeting with
+// fallback copy, since the copy pack only arrives with the onAppear params.
 export { svc };

package/templates/owner-lite/tier5-src/himi-owner-lite-aria-history/index.ts

@@ -38,5 +38,14 @@ const svc = defineService<AriaHistoryState, {
   },
 });
 
-svc.load();
+// NO module-scope `svc.load()` — same reason as the chat adapter next door, which
+// carries the full explanation. This `load` opens with `getConversations`, so a
+// self-kick makes a bridge call inside the bundle's own evaluation, and such a call
+// stalls on the Android WebView (#2518).
+//
+// It is less damaging here than on the chat screen: this load has no create latch
+// for a dead promise to poison, so the `onAppear` load issues its own request and
+// the list still fills. What the self-kick leaves behind is a dispatch that never
+// settles — `pendingDispatches` has no timeout, so it is held for the life of the
+// worker, on every open. Not worth keeping for a call whose result nothing reads.
 export { svc };

package/templates/podcast-creator-owner/tier5-src/himi-owner-lite-aria/index.ts

@@ -186,5 +186,33 @@ const svc = defineService<AriaChatState, {
   },
 });
 
-svc.load();
+// NO module-scope `svc.load()`, deliberately — the descriptor's `onAppear` is the
+// only entry point, and on Android the self-kick did not merely duplicate it, it
+// DISABLED the screen.
+//
+// `load` opens by creating a conversation, so a self-kick puts a `wixApi.call`
+// inside the bundle's own evaluation — and a bridge call made during
+// `worker.boot(bundle)` stalls on the Android WebView. The host completes it
+// (`bridge_wix_call … ok=true` is logged between `bundle eval done` and
+// `services=[…]`) but the JS promise never settles. `createOnce` then caches that
+// promise as the per-site create latch, so the `onAppear` load — dispatched
+// correctly, and fine on its own — awaits the same dead promise and never returns
+// either. Result on Android: no greeting, no prompt chips, no conversation, and a
+// Send that does nothing, for the life of the screen. Nothing reports it, because
+// a pending dispatch has no timeout: an action that never settles is
+// indistinguishable from one still running (#2518).
+//
+// That stall is a known Android defect, not a new one. `WebViewJSWorker` already
+// prepends per-screen input into the bundle's own evaluate rather than assigning it
+// separately, and says why: "the bundle's first wixApi.call could stall". Aria is
+// simply the first owner-lite screen to call the network at module scope and so the
+// first to meet it head-on. Fixing the stall is a core-runtime change tracked
+// separately; not calling the network before the screen exists is right regardless.
+//
+// The self-kick was never load-bearing. Both hosts queue a `tier5.*` action
+// dispatched before the worker is up — `Tier5WorkerSession.invoke` on Android and
+// `HimalayaScreenHost.dispatch` on iOS — and both say in as many words that the
+// self-kick is what made `onAppear` only LOOK like it worked. It also cost a
+// second conversation-create attempt per open and minted the greeting with
+// fallback copy, since the copy pack only arrives with the onAppear params.
 export { svc };

package/templates/podcast-creator-owner/tier5-src/himi-owner-lite-aria-history/index.ts

@@ -38,5 +38,14 @@ const svc = defineService<AriaHistoryState, {
   },
 });
 
-svc.load();
+// NO module-scope `svc.load()` — same reason as the chat adapter next door, which
+// carries the full explanation. This `load` opens with `getConversations`, so a
+// self-kick makes a bridge call inside the bundle's own evaluation, and such a call
+// stalls on the Android WebView (#2518).
+//
+// It is less damaging here than on the chat screen: this load has no create latch
+// for a dead promise to poison, so the `onAppear` load issues its own request and
+// the list still fills. What the self-kick leaves behind is a dispatch that never
+// settles — `pendingDispatches` has no timeout, so it is held for the life of the
+// worker, on every open. Not worth keeping for a call whose result nothing reads.
 export { svc };

package/templates/portfolio-creative-owner/tier5-src/himi-owner-lite-aria/index.ts

@@ -186,5 +186,33 @@ const svc = defineService<AriaChatState, {
   },
 });
 
-svc.load();
+// NO module-scope `svc.load()`, deliberately — the descriptor's `onAppear` is the
+// only entry point, and on Android the self-kick did not merely duplicate it, it
+// DISABLED the screen.
+//
+// `load` opens by creating a conversation, so a self-kick puts a `wixApi.call`
+// inside the bundle's own evaluation — and a bridge call made during
+// `worker.boot(bundle)` stalls on the Android WebView. The host completes it
+// (`bridge_wix_call … ok=true` is logged between `bundle eval done` and
+// `services=[…]`) but the JS promise never settles. `createOnce` then caches that
+// promise as the per-site create latch, so the `onAppear` load — dispatched
+// correctly, and fine on its own — awaits the same dead promise and never returns
+// either. Result on Android: no greeting, no prompt chips, no conversation, and a
+// Send that does nothing, for the life of the screen. Nothing reports it, because
+// a pending dispatch has no timeout: an action that never settles is
+// indistinguishable from one still running (#2518).
+//
+// That stall is a known Android defect, not a new one. `WebViewJSWorker` already
+// prepends per-screen input into the bundle's own evaluate rather than assigning it
+// separately, and says why: "the bundle's first wixApi.call could stall". Aria is
+// simply the first owner-lite screen to call the network at module scope and so the
+// first to meet it head-on. Fixing the stall is a core-runtime change tracked
+// separately; not calling the network before the screen exists is right regardless.
+//
+// The self-kick was never load-bearing. Both hosts queue a `tier5.*` action
+// dispatched before the worker is up — `Tier5WorkerSession.invoke` on Android and
+// `HimalayaScreenHost.dispatch` on iOS — and both say in as many words that the
+// self-kick is what made `onAppear` only LOOK like it worked. It also cost a
+// second conversation-create attempt per open and minted the greeting with
+// fallback copy, since the copy pack only arrives with the onAppear params.
 export { svc };

package/templates/portfolio-creative-owner/tier5-src/himi-owner-lite-aria-history/index.ts

@@ -38,5 +38,14 @@ const svc = defineService<AriaHistoryState, {
   },
 });
 
-svc.load();
+// NO module-scope `svc.load()` — same reason as the chat adapter next door, which
+// carries the full explanation. This `load` opens with `getConversations`, so a
+// self-kick makes a bridge call inside the bundle's own evaluation, and such a call
+// stalls on the Android WebView (#2518).
+//
+// It is less damaging here than on the chat screen: this load has no create latch
+// for a dead promise to poison, so the `onAppear` load issues its own request and
+// the list still fills. What the self-kick leaves behind is a dispatch that never
+// settles — `pendingDispatches` has no timeout, so it is held for the life of the
+// worker, on every open. Not worth keeping for a call whose result nothing reads.
 export { svc };

package/templates/restaurant-owner/tier5-src/himi-owner-lite-aria/index.ts

@@ -186,5 +186,33 @@ const svc = defineService<AriaChatState, {
   },
 });
 
-svc.load();
+// NO module-scope `svc.load()`, deliberately — the descriptor's `onAppear` is the
+// only entry point, and on Android the self-kick did not merely duplicate it, it
+// DISABLED the screen.
+//
+// `load` opens by creating a conversation, so a self-kick puts a `wixApi.call`
+// inside the bundle's own evaluation — and a bridge call made during
+// `worker.boot(bundle)` stalls on the Android WebView. The host completes it
+// (`bridge_wix_call … ok=true` is logged between `bundle eval done` and
+// `services=[…]`) but the JS promise never settles. `createOnce` then caches that
+// promise as the per-site create latch, so the `onAppear` load — dispatched
+// correctly, and fine on its own — awaits the same dead promise and never returns
+// either. Result on Android: no greeting, no prompt chips, no conversation, and a
+// Send that does nothing, for the life of the screen. Nothing reports it, because
+// a pending dispatch has no timeout: an action that never settles is
+// indistinguishable from one still running (#2518).
+//
+// That stall is a known Android defect, not a new one. `WebViewJSWorker` already
+// prepends per-screen input into the bundle's own evaluate rather than assigning it
+// separately, and says why: "the bundle's first wixApi.call could stall". Aria is
+// simply the first owner-lite screen to call the network at module scope and so the
+// first to meet it head-on. Fixing the stall is a core-runtime change tracked
+// separately; not calling the network before the screen exists is right regardless.
+//
+// The self-kick was never load-bearing. Both hosts queue a `tier5.*` action
+// dispatched before the worker is up — `Tier5WorkerSession.invoke` on Android and
+// `HimalayaScreenHost.dispatch` on iOS — and both say in as many words that the
+// self-kick is what made `onAppear` only LOOK like it worked. It also cost a
+// second conversation-create attempt per open and minted the greeting with
+// fallback copy, since the copy pack only arrives with the onAppear params.
 export { svc };

package/templates/restaurant-owner/tier5-src/himi-owner-lite-aria-history/index.ts

@@ -38,5 +38,14 @@ const svc = defineService<AriaHistoryState, {
   },
 });
 
-svc.load();
+// NO module-scope `svc.load()` — same reason as the chat adapter next door, which
+// carries the full explanation. This `load` opens with `getConversations`, so a
+// self-kick makes a bridge call inside the bundle's own evaluation, and such a call
+// stalls on the Android WebView (#2518).
+//
+// It is less damaging here than on the chat screen: this load has no create latch
+// for a dead promise to poison, so the `onAppear` load issues its own request and
+// the list still fills. What the self-kick leaves behind is a dispatch that never
+// settles — `pendingDispatches` has no timeout, so it is held for the life of the
+// worker, on every open. Not worth keeping for a call whose result nothing reads.
 export { svc };

package/templates/retail-store-owner/tier5-src/himi-owner-lite-aria/index.ts

@@ -186,5 +186,33 @@ const svc = defineService<AriaChatState, {
   },
 });
 
-svc.load();
+// NO module-scope `svc.load()`, deliberately — the descriptor's `onAppear` is the
+// only entry point, and on Android the self-kick did not merely duplicate it, it
+// DISABLED the screen.
+//
+// `load` opens by creating a conversation, so a self-kick puts a `wixApi.call`
+// inside the bundle's own evaluation — and a bridge call made during
+// `worker.boot(bundle)` stalls on the Android WebView. The host completes it
+// (`bridge_wix_call … ok=true` is logged between `bundle eval done` and
+// `services=[…]`) but the JS promise never settles. `createOnce` then caches that
+// promise as the per-site create latch, so the `onAppear` load — dispatched
+// correctly, and fine on its own — awaits the same dead promise and never returns
+// either. Result on Android: no greeting, no prompt chips, no conversation, and a
+// Send that does nothing, for the life of the screen. Nothing reports it, because
+// a pending dispatch has no timeout: an action that never settles is
+// indistinguishable from one still running (#2518).
+//
+// That stall is a known Android defect, not a new one. `WebViewJSWorker` already
+// prepends per-screen input into the bundle's own evaluate rather than assigning it
+// separately, and says why: "the bundle's first wixApi.call could stall". Aria is
+// simply the first owner-lite screen to call the network at module scope and so the
+// first to meet it head-on. Fixing the stall is a core-runtime change tracked
+// separately; not calling the network before the screen exists is right regardless.
+//
+// The self-kick was never load-bearing. Both hosts queue a `tier5.*` action
+// dispatched before the worker is up — `Tier5WorkerSession.invoke` on Android and
+// `HimalayaScreenHost.dispatch` on iOS — and both say in as many words that the
+// self-kick is what made `onAppear` only LOOK like it worked. It also cost a
+// second conversation-create attempt per open and minted the greeting with
+// fallback copy, since the copy pack only arrives with the onAppear params.
 export { svc };

package/templates/retail-store-owner/tier5-src/himi-owner-lite-aria-history/index.ts

@@ -38,5 +38,14 @@ const svc = defineService<AriaHistoryState, {
   },
 });
 
-svc.load();
+// NO module-scope `svc.load()` — same reason as the chat adapter next door, which
+// carries the full explanation. This `load` opens with `getConversations`, so a
+// self-kick makes a bridge call inside the bundle's own evaluation, and such a call
+// stalls on the Android WebView (#2518).
+//
+// It is less damaging here than on the chat screen: this load has no create latch
+// for a dead promise to poison, so the `onAppear` load issues its own request and
+// the list still fills. What the self-kick leaves behind is a dispatch that never
+// settles — `pendingDispatches` has no timeout, so it is held for the life of the
+// worker, on every open. Not worth keeping for a call whose result nothing reads.
 export { svc };

package/templates/yoga-studio-owner/tier5-src/himi-owner-lite-aria/index.ts

@@ -186,5 +186,33 @@ const svc = defineService<AriaChatState, {
   },
 });
 
-svc.load();
+// NO module-scope `svc.load()`, deliberately — the descriptor's `onAppear` is the
+// only entry point, and on Android the self-kick did not merely duplicate it, it
+// DISABLED the screen.
+//
+// `load` opens by creating a conversation, so a self-kick puts a `wixApi.call`
+// inside the bundle's own evaluation — and a bridge call made during
+// `worker.boot(bundle)` stalls on the Android WebView. The host completes it
+// (`bridge_wix_call … ok=true` is logged between `bundle eval done` and
+// `services=[…]`) but the JS promise never settles. `createOnce` then caches that
+// promise as the per-site create latch, so the `onAppear` load — dispatched
+// correctly, and fine on its own — awaits the same dead promise and never returns
+// either. Result on Android: no greeting, no prompt chips, no conversation, and a
+// Send that does nothing, for the life of the screen. Nothing reports it, because
+// a pending dispatch has no timeout: an action that never settles is
+// indistinguishable from one still running (#2518).
+//
+// That stall is a known Android defect, not a new one. `WebViewJSWorker` already
+// prepends per-screen input into the bundle's own evaluate rather than assigning it
+// separately, and says why: "the bundle's first wixApi.call could stall". Aria is
+// simply the first owner-lite screen to call the network at module scope and so the
+// first to meet it head-on. Fixing the stall is a core-runtime change tracked
+// separately; not calling the network before the screen exists is right regardless.
+//
+// The self-kick was never load-bearing. Both hosts queue a `tier5.*` action
+// dispatched before the worker is up — `Tier5WorkerSession.invoke` on Android and
+// `HimalayaScreenHost.dispatch` on iOS — and both say in as many words that the
+// self-kick is what made `onAppear` only LOOK like it worked. It also cost a
+// second conversation-create attempt per open and minted the greeting with
+// fallback copy, since the copy pack only arrives with the onAppear params.
 export { svc };

package/templates/yoga-studio-owner/tier5-src/himi-owner-lite-aria-history/index.ts

@@ -38,5 +38,14 @@ const svc = defineService<AriaHistoryState, {
   },
 });
 
-svc.load();
+// NO module-scope `svc.load()` — same reason as the chat adapter next door, which
+// carries the full explanation. This `load` opens with `getConversations`, so a
+// self-kick makes a bridge call inside the bundle's own evaluation, and such a call
+// stalls on the Android WebView (#2518).
+//
+// It is less damaging here than on the chat screen: this load has no create latch
+// for a dead promise to poison, so the `onAppear` load issues its own request and
+// the list still fills. What the self-kick leaves behind is a dispatch that never
+// settles — `pendingDispatches` has no timeout, so it is held for the life of the
+// worker, on every open. Not worth keeping for a call whose result nothing reads.
 export { svc };