@wix/himalaya-cli 0.1140.0 → 0.1142.0

package/guides/designing-himi-screens.md

@@ -281,7 +281,7 @@ Concrete patterns lifted from real usage:
 - **Cell list** — `card([ vstack({ spacing: 0, alignment: "leading", children: [ …ListItem cells… ] }) ])`. `spacing: 0` because the cells own their own dividers/padding.
 - **Overlay** — `zstack({ alignment: "center", children: [ backdropImage(cornerRadius 12), withModifiers(label, { padding, background: { token: "accentPrimary" }, cornerRadius: 10 }) ] })`.
 - **Responsive** — `grid({ columns: 1, columnsMedium: 2, spacing: 12 })` for 1-up on phone / 2-up on tablet; `splitView({ primary, detail, primaryMaxWidth: 280 })` for master/detail that stacks on a phone; set `contentMaxWidth` in tokens so wide surfaces keep a readable column instead of running edge-to-edge.
-- **Centered separator, not a flanked divider** — the classic "—— or ——" needs each `divider()` to take equal remaining width, and the HStack row-share only kicks in for controls with an intrinsic fill. **Never put a bare `divider()` inside an HStack for a row that must render on Android**: iOS and web draw it as a thin vertical rule the height of the row, but Android still draws a horizontal rule that claims the row's full width and squeezes its siblings (a stat row's `12` wraps to `1`/`2`). For a stats row, separate the columns with `spacer()`s or spacing instead. Use a **centered caption** instead: `hstack({ children: [spacer(), text("or continue with", "caption", { color: "textSecondary" }), spacer()] })`, optionally over a single full-width `divider()`.
+- **Centered separator, not a flanked divider** — the classic "—— or ——" needs each `divider()` to take equal remaining width, and the HStack row-share only kicks in for controls with an intrinsic fill. **A bare `divider()` inside an HStack is a column separator, not a flanking line**: iOS, macOS, Android, web and React Native all draw it as a thin vertical rule the height of the row that takes no share of the width, which is right for a stats row (`12 | 340 | 87`) and wrong for "—— or ——". For "—— or ——", use a **centered caption**: `hstack({ children: [spacer(), text("or continue with", "caption", { color: "textSecondary" }), spacer()] })`, optionally over a single full-width `divider()`.
 
 > **Intrinsic-fill controls grab the row.** `Button` and `TextField` have an intrinsic FILL, so the next four idioms are about NOT letting that surprise you (they were the papercuts every off-repo app hit):
 

package/guides/getting-started.md

@@ -122,6 +122,27 @@ placeholder copy, flow/state matrix, and compact/phone/expanded + device evidenc
 the app ready. Keep scenario switches out of customer UI. A labelled preview fallback is acceptable
 only when the host cannot perform the task and it cannot write customer data.
 
+**Adopting a template, step by step.** A template proves a capability; it is not the customer's
+product. Right after `init`:
+
+1. **Inventory what you inherited** before editing: its screens, local and remote data, auth,
+   capabilities, demo/fallback behaviour, and template-specific copy. Write it down — it is the
+   list the next steps work through.
+2. **Replace the template's identity**: its app name, addresses, sample content, and every
+   `YOUR_*` / `replace with` placeholder. A placeholder left in is shipped as copy —
+   `himi ux audit --strict` fails on one as `template-placeholder`.
+3. **Put each inherited risky flow in the acceptance matrix** — booking/cancellation, payments,
+   deletion, media, maps, entitlement — or remove it (`himi template trim`). A flow the plan does
+   not mention is a flow nobody approved.
+4. **Classify every control** as primary, secondary, destructive, or preview/fallback, and keep a
+   destructive or writing control only when the approved data-access matrix allows it.
+5. **Prove each adopted flow, not just each screen**: with fixtures or `dev/net-mocks.json`, prove
+   typed input → submit → the persisted result with a typed journey in `himi-test.json`
+   (`--deep` replays action chains but never types a field value), then prove the destination
+   and cancel/back recovery separately — a typed journey is screen-local and does not follow
+   navigation, so use a render of the destination or a device drive. A fresh-screen crawl alone
+   does not prove a flow.
+
 Before authoring a multi-screen mobile app, ensure the customer-approved `SPEC.md` and
 `MOBILE-UX.md` are in the content-package root. Use `himi docs <topic>` only after `himi docs`
 shows that topic for the installed CLI.

package/guides/himi-skill.md

@@ -151,6 +151,27 @@ placeholder copy, flow/state matrix, and compact/phone/expanded + device evidenc
 the app ready. Keep scenario switches out of customer UI. A labelled preview fallback is acceptable
 only when the host cannot perform the task and it cannot write customer data.
 
+**Adopting a template, step by step.** A template proves a capability; it is not the customer's
+product. Right after `init`:
+
+1. **Inventory what you inherited** before editing: its screens, local and remote data, auth,
+   capabilities, demo/fallback behaviour, and template-specific copy. Write it down — it is the
+   list the next steps work through.
+2. **Replace the template's identity**: its app name, addresses, sample content, and every
+   `YOUR_*` / `replace with` placeholder. A placeholder left in is shipped as copy —
+   `himi ux audit --strict` fails on one as `template-placeholder`.
+3. **Put each inherited risky flow in the acceptance matrix** — booking/cancellation, payments,
+   deletion, media, maps, entitlement — or remove it (`himi template trim`). A flow the plan does
+   not mention is a flow nobody approved.
+4. **Classify every control** as primary, secondary, destructive, or preview/fallback, and keep a
+   destructive or writing control only when the approved data-access matrix allows it.
+5. **Prove each adopted flow, not just each screen**: with fixtures or `dev/net-mocks.json`, prove
+   typed input → submit → the persisted result with a typed journey in `himi-test.json`
+   (`--deep` replays action chains but never types a field value), then prove the destination
+   and cancel/back recovery separately — a typed journey is screen-local and does not follow
+   navigation, so use a render of the destination or a device drive. A fresh-screen crawl alone
+   does not prove a flow.
+
 Before authoring a multi-screen mobile app, ensure the customer-approved `SPEC.md` and
 `MOBILE-UX.md` are in the content-package root. Use `himi docs <topic>` only after `himi docs`
 shows that topic for the installed CLI.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@wix/himalaya-cli",
-  "version": "0.1140.0",
+  "version": "0.1142.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": [
@@ -67,5 +67,5 @@
       "artifactId": "himalaya-cli"
     }
   },
-  "falconPackageHash": "42a37432b11097784e0389ac94c65fc4c19358634b3ea5270db5cd25"
+  "falconPackageHash": "da6ce19c2485b32baf1d9f2aca5df0f7110f9b0dbff3115b10b40ac9"
 }