@wix/himalaya-cli 0.849.0 → 0.851.0

package/guides/mobile-ux.md

@@ -152,43 +152,56 @@ The fourth marker, **width evidence**, is graded by **content, not by phrase**
 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, 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). `Rendered 320, 390 and 834 (home-320.png, home-390.png, home-834.png)` satisfies it
-  — a single width does not. What this proves is that you rendered more than one size class, not
-  which wider one: 600px is the `medium` breakpoint and `expanded` begins at 840px, so 834 counts
-  as wider without being expanded. The two bands are contiguous, so every width you actually render
-  counts as one or the other: `pixel` (412) and `iphone-max` (430) from `himi render --device` are
-  compact.
-  Each number must read as a **width**: give it a unit (`834px`), put it in a screenshot filename
-  (`home-834.png`, `home-834-dark.png`, `home-834x1112.png`), or name it with the vocabulary of
-  widths — `width`, `wide`, `pixel`, `viewport`, `breakpoint`, `compact`, `expanded`, `column`,
-  `portrait`, `landscape`. One such word covers a whole list of widths from either end (`Rendered
-  320, 390 and 834 widths`, `Widths: 320, 390, 834` and `Rendered compact (320) and expanded (834)`
-  all work), and the list may wrap across lines — but it does not reach across another phrase or
-  into the next line unless that line continues the list: in `Rendered home at 834px; p95
-  250 ms` only `834` is a width, so that line names a single width and is still reported. In a
-  `390x844` pair the first number is the width and the second is the height, so one portrait
-  screenshot is one width — `home-390x844.png` on its own is not two. Bare
-  digits count for nothing, which keeps a latency budget, a price or an issue number from standing
-  in for the half you did not render. A number in the 1990-2099 range needs its **unit** to count
-  as a width: `2048px` is taken at its word, while a bare `2026` and a year-shaped filename
-  (`shot-2026.png`, `evidence-2026-09-18.png`) are not widths — `home-2048.png` cannot be told
-  apart from `shot-2026.png`, so spell the unit when your render really is that wide.
-  `render` is deliberately **not** one of the cues: an acceptance row says "renders in under
-  250 ms" far more often than it names a viewport. Neither is a pixel measurement of something
-  that is not a viewport — `Row height 320px`, `Font size: 512px` and `844 tall` are ignored,
-  because a unit says pixels, not width. Assets are judged by the SENTENCE they sit in rather than
-  by word order: a sentence naming an image, logo, banner, hero, icon, media or artwork is a record
-  of assets, so none of its numbers count — `Use 320px-wide mobile and 1024px-wide desktop hero
-  images` records no render. A screenshot **filename** is the exception and outranks the sentence
-  it appears in, because a file that was written is the strongest evidence this marker takes:
-  `Screenshots: hero-320.png and hero-834.png` counts.
+- 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)
+  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
+  whole rule; nothing is inferred from the words around the number. So
+  `Rendered 320px and 834px`, `Captured 834px down to 320px`, `Widths: 320px, 390px, 834px` and
+  `Rendered 320, 390 and 834 (home-320.png, home-390.png, home-834.png)` all satisfy it, and a
+  single width does not.
+
+  What this proves is that you rendered more than one size class, not which wider one: 600px is the
+  `medium` breakpoint and `expanded` begins at 840px, so 834 counts as wider without being expanded.
+  The two bands are contiguous, so every width you actually render counts as one or the other:
+  `pixel` (412) and `iphone-max` (430) from `himi render --device` are compact.
+
+  **A bare number never counts, however the sentence labels it.** `Widths: 320, 390, 834`,
+  `Rendered 320, 390 and 834 widths` and `Rendered compact (320) and expanded (834)` all name no
+  unit on any number, so none of them is width evidence — add one unit per width and they are. In
+  particular the word **`width` is a label, not a unit**: it says what you decided the number means,
+  so `320 widths` does nothing that `320` does not. `pixels` and `wide` *are* units and do count —
+  `320 pixels`, `320 wide`, `320 pixel widths`. This
+  is deliberate: reading the prose around a number is exactly what used to reject honest documents
+  (a comma and the word `illustration` were enough), so the gate no longer does it. The cost of
+  bare digits not counting is one character each; the cost of guessing from prose was a rejected
+  render you could not diagnose.
+
+  Three things still disqualify a number that *is* spelled as a width, and all three are about the
+  **axis** rather than about the subject: a **height or type/spacing size** (`Row height 320px`,
+  `Font size: 512px`, `844 tall`, `844 high`), the **second half of a `NxM` pair** (in
+  `home-390x844.png` the width is 390 and 844 is the height, so one portrait screenshot is one
+  width, not two), and a number **outside 200–4000px** (`64px` chips and a `9000px` export canvas
+  are not viewports). A number in the **1990–2099 range** needs its unit rather than a filename:
+  `2048px` and `2048 pixels` are taken at their word, while `home-2048.png` cannot be told apart
+  from `shot-2026.png`, so spell the unit when your render really is that wide.
+
+  **Accepted, deliberately:** an asset dimension written with a unit or in a filename now counts —
+  `Hero image is 320px wide; the banner is 1024px wide` and `Icon sizes: icon-320.png,
+  icon-834.png` pass. The marker is permissive there on purpose. A gate that rejects real work
+  costs build loops; a permissive one costs a line of prose, and a card or drawer width always
+  passed anyway.
 - Or keep the scaffold's own sentence, `compact (320/360)` followed later by `expanded`, which is
   still accepted as-is. The two **may wrap across lines** — the check is not line-based — but
   `expanded` must follow within about 400 characters, so keep them in the same sentence or bullet
   rather than in separate sections.
 
+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
+gave you rather than pasting the example: the example is a form that works, not the only one.
+
 A `MOBILE-UX.md` that is **absent or empty** is not four missing markers. `himi ux audit` reports it
 once, as a missing contract; `himi validate` stays silent about it entirely. Asking for the document
 itself is the audit's job — most apps never adopt this contract, and a warning on every one of them

package/guides/sdk-reference.json

@@ -1509,6 +1509,12 @@
     "source": "core/sdk/local-db/src/index.ts",
     "description": "Tier-5 typed binding to the platform's local-database capability: a per-entity on-device store (EntityStore) + an offline WriteQueue, so a worker bundle can persist and query real data on device.",
     "api": [
+      {
+        "name": "availability",
+        "kind": "function",
+        "jsdoc": "/**\n * Whether this host actually backs the local database — the probe #2502 asked for.\n *\n * Without it, every read on a host that does not serve the capability is\n * INDISTINGUISHABLE from a successful read of an empty collection: `getAll` coalesces a\n * missing answer to `[]` and `get` to `null` just below, so an author sees \"0 rows\" and\n * cannot tell whether the store is empty or absent. That ambiguity cost three QA slots on\n * one run; one of them shipped a whole in-memory fallback that turned out to be dead code.\n *\n * `full` on iOS / Android / web and in the headless `himi render` host; `degraded` where the\n * store works but does not survive a reload (web without IndexedDB); `unavailable` when the\n * host does not back it. Branch on this rather than inferring absence from an empty result.\n *\n * NEVER THROWS, like `@himalaya/pdf`'s `isAvailable`, and that is load-bearing rather than\n * politeness: the hosts this probe exists to detect are exactly the ones that REJECT it.\n * Both native dispatchers throw on an unregistered id (`ActionError.unknown`), so on any app\n * binary shipped before this verb existed — or a shell that never calls\n * `LocalDatabaseCapability.register` — a rejecting probe would put an unhandled rejection in\n * the worker's `load()` of every author who wrote the documented\n * `if (await availability() === \"full\")`. A refusal to answer IS the answer here.\n */",
+        "decl": "export async function availability(): Promise<Availability>;"
+      },
       {
         "name": "DbEntity",
         "kind": "interface",
@@ -2613,6 +2619,12 @@
     "source": "core/sdk/secure-storage/src/index.ts",
     "description": "Tier-5 typed binding to the platform's secure-storage capability.",
     "api": [
+      {
+        "name": "availability",
+        "kind": "function",
+        "jsdoc": "/**\n * Whether this host actually backs secure storage — the probe #2502 asked for.\n *\n * Without it, `read` on a host that does not serve the capability is INDISTINGUISHABLE\n * from a key that was never written: both answer `null` (see `read` below, which coalesces\n * a missing answer). An author cannot tell \"unsupported here\" from \"genuinely empty\", which\n * is exactly what made a silent no-op look like a working-but-empty keychain.\n *\n * `full` on iOS (Keychain) / Android (Keystore-AES) / web and in the headless\n * `himi render` host; `unavailable` when the host does not back it — which on web includes\n * a context with no IndexedDB (a sandboxed iframe, a storage-blocked third-party frame),\n * where every `read`/`write` would reject.\n *\n * NEVER THROWS, like `@himalaya/pdf`'s `isAvailable`, and that is load-bearing rather than\n * politeness: the hosts this probe exists to detect are exactly the ones that REJECT it.\n * Both native dispatchers throw on an unregistered id (`ActionError.unknown`), so on any app\n * binary shipped before this verb existed — or a shell that never calls\n * `SecureStorageCapability.register` — a rejecting probe would put an unhandled rejection in\n * the worker's `load()` of every author who wrote the documented\n * `if (await availability() === \"full\")`. A refusal to answer IS the answer here.\n */",
+        "decl": "export async function availability(): Promise<Availability>;"
+      },
       {
         "name": "AccessControl",
         "kind": "type",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@wix/himalaya-cli",
-  "version": "0.849.0",
+  "version": "0.851.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": "464c186de522efebf80157a9bca4d7349bdbf3331ac8adfaf726f4d4"
+  "falconPackageHash": "2c72306bbd7422cc43f4b015ca58fa3faa1b69328012a00c4294baff"
 }