@wix/himalaya-cli 0.856.0 → 0.858.0

package/guides/getting-started.md

@@ -230,6 +230,12 @@ the complete decision order and examples.
   publishes to the internal registry `npm.dev.wixpress.com`, which is unreachable off-VPN. The
   CLI itself is not: it comes from public npm.
 - ⛔ **Needs a Wix sign-in:** `himi push` / `promote` publish and activate your release.
+  To change **part** of a release instead of republishing it, `push --only <selector>` publishes
+  just the named items — same build + lint gate, derived from the live release — and `himi patch`
+  does the same from a raw file on a machine with no content package. Both require an explicit
+  `--draft` or `--live`: a partial publish has no safe default, and neither carries an attestation
+  or refreshes the source archive (the output names both). Prefer `push` for anything you would
+  want restorable.
   After a push, **`context` / `screens` / `diagnose` / `deeplinks` / `render --remote` /
   `telemetry` / `logs`** read back from what you published (over `/v1/preview/…`,
   `/v1/telemetry/events`, `/v1/telemetry/logs`), and so does **`himi dist`**

package/guides/mobile-ux.md

@@ -135,6 +135,10 @@ driving a native shell, record the result—not an assumption—with `himi ux re
 is required for `passed`/`failed` and names what you actually drove; an unavailable platform drove
 nothing, so it takes no checks and needs a `--reason` instead.
 
+`himi render --width`/`--device` writes into the same `.himi/ux-audit.json`, appending the width it
+rendered. That is what the width marker below reads first, so rendering the screen at two widths is
+itself the evidence — see the strict audit contract.
+
 ### Strict audit contract
 
 **Two commands read this contract.** `himi validate` reports a gap as a **warning**, so a rewrite
@@ -162,12 +166,31 @@ better document, were refused, and pasted the sentence back:
 - *or literally*: the phrase `one primary CTA per state` appears anywhere. It is not deprecated —
   a document that passes today keeps passing.
 
-The remaining marker, **width evidence**, is graded by **content, not by phrase** — it is a
-fact about what you rendered rather than a string, so there is nothing to paste. Satisfy it either
-way:
-
-- Name two pixel widths spanning compact → wider, **each spelled as a width on itself**, within
-  about 400 characters of each other so they read as one statement: one **below 600px** (compact)
+The remaining marker, **width evidence**, is graded by **what you rendered, not by a phrase** — it
+is a fact rather than a string, so there is nothing to paste. Three things satisfy it, and they are
+tried in this order:
+
+- **A recorded render — the primary path, and the one to prefer.** `himi render <screenId>
+  --content <app> --width 390`, then the same screen again at `--width 834` (or `--device iphone`
+  and `--device ipad`), appends the width each run actually rendered to `.himi/ux-audit.json` —
+  the same structured evidence file `himi ux record` writes. A recorded render **below 600px**
+  plus one **at 600px or wider** satisfies this marker on its own: the document need not name a
+  width anywhere. The gate is then reading a fact the tool produced instead of a sentence you
+  typed, which is the whole point of the marker.
+
+  Each entry carries the screen, the width, the `--device` preset when you used one, and the PNG
+  when `--png` wrote one. Re-rendering the same screen at the same width **replaces** that entry
+  rather than appending another, so a long dev loop leaves one line per screen and width, and a
+  native audit already recorded in the same file is never disturbed. A render with **no**
+  `--width`/`--device` records nothing on purpose: without one the PNG viewport is the headless
+  browser's desktop default, and writing that down would manufacture the very expanded render the
+  marker exists to prove. Recording never fails or slows a render — if the file cannot be written
+  the render still succeeds, and the paths below still apply. `.himi/` is gitignored, so this is
+  evidence about your checkout rather than something a pull request carries.
+
+- Or name two pixel widths in the document, spanning compact → wider,
+  **each spelled as a width on itself**, within about 400 characters of each other so they read as
+  one statement: one **below 600px** (compact)
   and one **at 600px or wider** (medium or expanded). A number is spelled as a width when it
   carries a **unit** — `320px`, `320 px`, `320pt`, `320dp`, `320 pixels`, `320 wide` — or sits in a
   **screenshot filename** — `home-320.png`, `home-834-dark.png`, `home-390x844.png`. That is the
@@ -211,9 +234,17 @@ way:
   `expanded` must follow within about 400 characters, so keep them in the same sentence or bullet
   rather than in separate sections.
 
+The two written paths are a **fallback, not a deprecation**: plenty of real renders are not driven
+by `himi render` at all — a simulator, a real phone, or an automated UI driver leaves no entry in
+`.himi/ux-audit.json` — so a document that satisfies this marker today still satisfies it. A render
+record can only **add** a way to pass; it never takes one away, and a record showing fewer size
+classes than your document claims is not itself a finding.
+
 When the marker fails, the error names **which** of the four things went wrong — no compact width,
 no wider width, two widths too far apart to be one statement, or no number spelled as a width — and
-says so alongside the height-axis rule if that is what discarded your numbers. Read the branch it
+says so alongside the height-axis rule if that is what discarded your numbers. When the render
+record holds something, it also names what it holds and the single command that would complete it
+("holds 390px — compact only. Render the same screen again at 600px or wider"). Read the branch it
 gave you rather than pasting the example: the example is a form that works, not the only one.
 
 **HTML comments are stripped before any of this runs.** The scaffold ships a `<!-- LOAD-BEARING -->`

package/guides/qa-builds.md

@@ -1046,7 +1046,7 @@ therefore no seed endpoint to call.
 yarn workspace @himalaya/native-ci dist:ios       # → run-dist.ts ios --force
 yarn workspace @himalaya/native-ci dist:android
 # target another app:
-APP_DIR=apps/orion-clone APP_BUNDLE_ID=com.wix.orion.clone.dev \
+APP_DIR=apps/demo-app APP_BUNDLE_ID=com.himalaya.demoapp.dev \
   yarn workspace @himalaya/native-ci dist:ios
 ```
 

package/guides/recipe-four-state.md

@@ -9,7 +9,7 @@ bound to a worker boolean.
 
 This is the corpus norm: of the in-repo worker bundles, ~3 in 4 model loading,
 more than half model error, and the reference apps (`apps/himi-owner-lite`,
-`apps/himi-blog`, `apps/demo-app`) all ship this exact shape. The
+`apps/demo-app`, and Himi Blog) all ship this exact shape. The
 `examples/dynamic-list.*` and `examples/form-submit.*` pairs both demonstrate it.
 
 ## 1. One status field, derived display strings

package/guides/recipe-search.md

@@ -5,8 +5,8 @@ the full result set in state, derive the visible rows from a query string. No
 network round-trip per keystroke, instant results, and the empty state can say
 *why* it's empty.
 
-Mined from `apps/himi-blog` (`himi-blog-feed` worker: search + category chips over
-posts). The `examples/search-list.*` pair that `himi agent-init` writes is a
+Mined from the Himi Blog app's `himi-blog-feed` worker (search + category chips
+over posts). The `examples/search-list.*` pair that `himi agent-init` writes is a
 distilled, runnable version. Builds on `himi docs recipe-dynamic-list` — read that
 first; this recipe only adds the query layer.
 
@@ -31,7 +31,7 @@ first; this recipe only adds the query layer.
 - `onSubmit` (keyboard search key) is optional when `onChange` already filters live.
 - For category/facet filtering alongside text search, add `FilterChips` with
   `optionsPath: "$service:posts.categories"` and a `selectCategory` action — same
-  worker-side pattern (see `apps/himi-blog`).
+  worker-side pattern as the `himi-blog-feed` worker.
 
 ## 2. The worker: keep `all`, derive `items`
 

package/guides/releasing-with-himi-serve.md

@@ -103,6 +103,48 @@ himi-serve release visibility --app <app> public             # flip without repu
 `"visibility": "unlisted"` in `himalaya.content.json`.) The verb is `POST
 /v1/admin/app-settings` — owner-role callable, scope-checked, audited.
 
+## Patching one item of a release
+
+A whole `himi push` sends every screen, bundle, tokens and app-config in one body. To change
+**part** of a release instead, two doors derive a new release from an existing one, moving only
+what you name (`POST /v1/admin/release/patch`):
+
+```bash
+# You have the content package: same build + lint gate as a whole push, publishing less.
+himi push --only changed --draft                  # every item whose bytes differ from the base
+himi push --only screen:cart,tokens --live
+himi push --only bundle:cart --draft              # drags the screens that reference it
+
+# You do not: a raw file, no build, no package lint.
+himi patch screen cart --app my-app --file cart.json --live --notes "hotfix #4412"
+himi patch tokens --app my-app --file tokens.json --draft
+```
+
+**Blast radius is never implied.** A whole `himi push` defaults to `--draft` because you promote
+it afterwards; a patch requires an explicit `--draft` or `--live`, and neither is a usage error.
+
+**The base is the live release**, or `--from-release <id>` to branch off a past one. A branch does
+**not merge**: activating it materializes that base's bytes for every item the patch does not move,
+so anything published since goes backwards. Both doors compute that list and refuse — draft or
+live — until you have seen it and passed `--accept-regressions`.
+
+**What a derived release does not carry**, each reported in the output rather than assumed:
+
+| Slice | What happens |
+|---|---|
+| attestation | **Dropped.** Evidence belongs to exact bytes, so a derived release has none and does not inherit the base's. |
+| source archive | **Inherited, not refreshed** — the route accepts no archive. `himi pull` on the patched release returns the base's source, *without* your edit, so the output sets `restore: null` and says so. Only a full `himi push` re-syncs the backup. |
+| assets, icon, platforms, `minBinaryVersion` | **Inherited.** `push --only` holds both manifests, so it detects a package that changed one of these and refuses `not_carried_by_patch` (override: `--accept-partial`). `himi patch` cannot see it. |
+| a new screen | **Refused.** `himi patch screen` updates a screen the base already has; it cannot add one. A new screen also changes navigation, deep links and the surface envelope, and only a full `himi push` builds and checks those — so adding goes through `push`, while updating an existing screen is exactly what the raw-file door is for. |
+
+A bundle patch must repoint a screen at the new bytes (`push --only bundle:<name>` infers this;
+`himi patch bundle` takes `--for-screen`), because the manifest records patched bundles by sha
+while screens still name the key they were built with — so bytes published alone land where
+nothing reads them.
+
+Caps are enforced at the door (413 `item_too_large`): a screen descriptor 256 KiB, a bundle 4 MiB,
+tokens and app-config 64 KiB each, and the whole body 8 MiB.
+
 ## Consume (what a device / agent reads)
 
 ```

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@wix/himalaya-cli",
-  "version": "0.856.0",
+  "version": "0.858.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": "82a824b69c0914106e80e0fb205b046bd8e669b53f46887b3adf0eed"
+  "falconPackageHash": "972ac0ce50f52661ff47fd5e94ce05f0bb2cb51462e5c44281e4f147"
 }