@wix/himalaya-cli 0.841.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.841.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": "60bd923f4e7d6bcb8c585e19b160bbc63f2db7758a553bd612e945ad"
+  "falconPackageHash": "b45ead5f2fb4dcd64fd4c31516607200700f0f8e9a1926efb5d6a6e2"
 }