@wix/himalaya-cli 0.857.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/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.857.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": "629ade3aa68530bbdcfe1842b24b52fcb778d8e8f85ff394bc3372fb"
+  "falconPackageHash": "972ac0ce50f52661ff47fd5e94ce05f0bb2cb51462e5c44281e4f147"
 }