@wix/himalaya-cli 0.1187.0 → 0.1189.0

package/guides/capabilities.md

@@ -25,7 +25,7 @@ camera  —  import from @himalaya/camera
   exports:  capturePhoto, pickDocument, scanQR
   declare:  config.ts `capabilities` AND each calling screen's `logicBundle.declaredCapabilities`
   binary:   needs a NATIVE build — iOS NSCameraUsageDescription; Android android.permission.CAMERA …
-  shells:   served by owner-lite; NOT in the branded-lite, brandy, demo-app, player binary
+  shells:   served by owner-lite, player; `himi dist` adds it to base44, branded-lite, brandy; NOT in the demo-app binary
 ```
 
 Agents: the same data is the `himi_capabilities` MCP tool. `himi sdk <name>` also prints the
@@ -89,8 +89,23 @@ Name the shell your app ships in once, in `himalaya.content.json`, and both `him
 
 `himi test` boots every screen's real worker and dispatches its actions. A declared capability
 answers with its "unavailable" result there, so the crawl checks that your worker handles a
-declined camera or a missing position without breaking. In the web preview, camera capture and
-geolocation use the browser's own file picker and location prompt.
+declined camera or a missing position without breaking; a second pass then answers the modelled
+ones (camera, location, photos, speech, …) with a SUCCESS result, so the code behind a granted
+permission runs too. Two things in the `--json` report are about capabilities:
+
+- a **`capability-undeclared`** finding for every call the screen's gate denied — even one your
+  worker caught, which on device looks like a dead button rather than an error;
+- **`capabilityCoverage`**: each `capability.<id>.<verb>` your workers call, and what the crawl
+  answers it with — `success` (modelled), `store` (a real session store: `local_database`,
+  `secure_storage`), `unavailable-only` (no model yet, so only the declined path runs), or `denied`.
+  See [himi-test → Capabilities](himi-test.md#capabilities).
+
+The bundle scan only ever **reports**: it never adds a capability to a screen's declaration. The
+per-screen list is the authorization boundary, so a worker shared by two screens cannot widen the
+one that never makes the call.
+
+In the web preview, camera capture and geolocation use the browser's own file picker and location
+prompt.
 
 ## 5. Ship it
 
@@ -103,6 +118,14 @@ geolocation use the browser's own file picker and location prompt.
   entitlements, Android permissions / features) and registers their handlers at boot.
   `himi capabilities --shell <s>` shows such an id as `yes → dist`, and `himi validate` warns that
   it "needs a new `himi dist`" — the installed binary cannot call it until you rebuild.
+- **"needs a new binary".** A successful `himi dist` remembers what its binary was built with —
+  on the job (`buildCapabilities`) and in your package (`.himi/last-dist.json`). From then on
+  `himi push` prints `needs a new binary: <ids> — run himi dist` when the release declares an id
+  that build lacks, a following device's draft offer says the same, and `himi validate` compares
+  against that build rather than the committed shell.
+- **Never a silent strip.** On iOS, a capability whose entitlement the signing profile cannot grant
+  fails the dist job, naming the capability — the binary would otherwise build green and fail on
+  the first call. The minted profile's Apple capabilities are derived from the build's own set.
 - **Preview before you build:** `himi dist --plan` prints what the release declares, what the shell
   already serves, what the build would add and the exact native delta. No job is started.
 - **Write the permission prompt.** The OS shows a sentence when the app asks for camera, location,

package/guides/component-reference.json

@@ -6,7 +6,6 @@
   "notImplementedComponents": [
     "FieldError",
     "Picker",
-    "DatePicker",
     "Tabs",
     "Snackbar",
     "Slider",
@@ -348,22 +347,16 @@
       "name": "DatePicker",
       "category": "Form primitives",
       "propsType": "DatePickerProps",
-      "bindings": [],
+      "bindings": [
+        "valuePath"
+      ],
       "dispatches": [
         {
           "callback": "onChange",
           "key": "value",
           "encoding": "unix-seconds-string",
-          "note": "Unix SECONDS, string-encoded so the params mirror stays legal. iOS ships `valueUnix` as an int instead; RN ships nothing. The normative key is `value` because that is what three of four arms already use for every other scalar control.",
+          "note": "Unix SECONDS, string-encoded so the params mirror stays legal, clamped into [minUnix, maxUnix]. iOS, Android and web conform (iOS shipped `valueUnix` as an int until the SwiftUI-parity DatePicker fix); RN ships nothing. The normative key is `value` because that is what the arms use for every other scalar control.",
           "divergences": [
-            {
-              "arms": [
-                "ios"
-              ],
-              "kind": "wrong-key",
-              "actual": "sends `valueUnix` as an int instead of the contract's `value`.",
-              "reason": "Only web conforms. This is the widest split in the vocabulary and the clearest argument for the file."
-            },
             {
               "arms": [
                 "rn"
@@ -382,19 +375,6 @@
           ]
         }
       ],
-      "notImplemented": {
-        "props": [
-          "mode",
-          "minUnix",
-          "maxUnix",
-          "valuePath"
-        ],
-        "platforms": [
-          "ios"
-        ],
-        "severity": "styling",
-        "note": "The picker itself renders as a native date wheel — these four props are inert: `mode: \"time\"` still renders a date wheel; `minUnix`/`maxUnix` do not clamp; `valuePath` does not bind."
-      },
       "propsSource": "export interface DatePickerProps {\n  valueUnix?: number;\n  minUnix?: number;\n  maxUnix?: number;\n  mode?: \"date\" | \"time\" | \"datetime\";\n  onChange?: Action;\n  /** \"$service:\" sentinel → ISO-8601 string (or unix seconds); prefills + tracks. */\n  valuePath?: string;\n}"
     },
     {

package/guides/component-reference.md

@@ -52,7 +52,7 @@ See also **[Modifiers](#modifiers)** (the `modifiers` block) and **[Actions](#ac
 | `FormField` | Form primitives | — |
 | `FieldError` | Form primitives | `textPath` |
 | `Picker` | Form primitives | — |
-| `DatePicker` | Form primitives | — |
+| `DatePicker` | Form primitives | `valuePath` |
 | `StatefulSection` | State envelopes | — |
 | `Skeleton` | State envelopes | — |
 | `FragmentSlot` | Descriptor-shipped dynamic structure | `casePath` |
@@ -116,16 +116,15 @@ See also **[Modifiers](#modifiers)** (the `modifiers` block) and **[Actions](#ac
 
 These props are accepted by the schema and pass validation, but the named platform's renderer never reads them — they silently do nothing (no warning, no log). Prefer a prop NOT listed here, or drive the behaviour from a worker.
 
-**Scope: 14 of 84 components, all of them ios-only** — every other component/platform pair reads every prop it decodes. The list splits in two, and the halves mean different things:
+**Scope: 13 of 84 components, all of them ios-only** — every other component/platform pair reads every prop it decodes. The list splits in two, and the halves mean different things:
 
 - **`category` (4: `BottomSheet`, `Menu`, `Tooltip`, `Popover`)** — the prop changes the component's *kind*. These genuinely are **not implemented**: an overlay renders always-visible inline, so the component does not do the job its name implies. Check the row's note for a working alternative — for a dismissible sheet it is `presentation: "sheet"` on the navigating `Action`, not `BottomSheet`.
-- **`styling` (10: `FieldError`, `Picker`, `DatePicker`, `Tabs`, `Snackbar`, `Slider`, `ActivityIndicator`, `ChipsInput`, `OtpInput`, `Video`)** — the component itself **works**; only the listed prop is inert. `Slider` on iOS is a working slider whose `debounceMs` does not throttle — not a broken `Slider`. Use the component; just do not depend on that one prop.
+- **`styling` (9: `FieldError`, `Picker`, `Tabs`, `Snackbar`, `Slider`, `ActivityIndicator`, `ChipsInput`, `OtpInput`, `Video`)** — the component itself **works**; only the listed prop is inert. `Slider` on iOS is a working slider whose `debounceMs` does not throttle — not a broken `Slider`. Use the component; just do not depend on that one prop.
 
 | Component | Unread props | Platform | Kind | Note |
 |---|---|---|---|---|
 | `FieldError` | `severity` | ios | styling | `severity: "warning"` still paints `danger` red. |
 | `Picker` | `optionsPath`, `placeholder` | ios | styling | `optionsPath` does not bind options; `placeholder` is not shown. |
-| `DatePicker` | `mode`, `minUnix`, `maxUnix`, `valuePath` | ios | styling | The picker itself renders as a native date wheel — these four props are inert: `mode: "time"` still renders a date wheel; `minUnix`/`maxUnix` do not clamp; `valuePath` does not bind. |
 | `Tabs` | `style` | ios | styling | The tab bar itself renders — only `style` is inert: `swipe` still renders as top tabs. |
 | `Snackbar` | `durationMs` | ios | styling | `durationMs` does not control the auto-dismiss timeout. |
 | `Slider` | `debounceMs` | ios | styling | `debounceMs` does not throttle the onChange stream. |
@@ -821,17 +820,13 @@ export interface DatePickerProps {
 }
 ```
 
-> ⚠️ **Implemented, but these props are inert on ios:** `mode`, `minUnix`, `maxUnix`, `valuePath` — The picker itself renders as a native date wheel — these four props are inert: `mode: "time"` still renders a date wheel; `minUnix`/`maxUnix` do not clamp; `valuePath` does not bind.
-
 **Dispatches** — see [What a control sends](#what-a-control-sends-action-payloads):
 
 | callback | key | type |
 |---|---|---|
 | `onChange` | `value` | unix-seconds-string |
 
-> `onChange` — Unix SECONDS, string-encoded so the params mirror stays legal. iOS ships `valueUnix` as an int instead; RN ships nothing. The normative key is `value` because that is what three of four arms already use for every other scalar control.
-
-> ⚠️ **`onChange` on ios — DIVERGES:** sends `valueUnix` as an int instead of the contract's `value`. Only web conforms. This is the widest split in the vocabulary and the clearest argument for the file.
+> `onChange` — Unix SECONDS, string-encoded so the params mirror stays legal, clamped into [minUnix, maxUnix]. iOS, Android and web conform (iOS shipped `valueUnix` as an int until the SwiftUI-parity DatePicker fix); RN ships nothing. The normative key is `value` because that is what the arms use for every other scalar control.
 
 > ⚠️ **`onChange` on rn — DIVERGES:** dispatches the bare action with no date at all.
 

package/guides/himi-test.md

@@ -125,6 +125,7 @@ Only **unambiguous** defects, so a green run stays worth trusting:
 | `poll-action-missing` | error | A `_poll` directive every host will silently ignore — an action the bundle never declares, a malformed `action`, a missing `id`, or a non-positive `intervalMs`. Each ends the same way: a screen that never refreshes, with nothing saying why. Nothing in the descriptor names the polled action, so no static check can see it. (A merely too-small interval is legal — the host clamps it.) |
 | `no-request-issued` | **warning** | A worker that uses the Wix transport but never fetches — "the screen loaded with sample data." A warning: a conditional or tap-triggered fetch is legitimate. |
 | `native-decode-failed` | error | Under `--native`, the real Swift/Kotlin decoder rejected the baked descriptor bytes (one bad enum blanks the whole screen on device). |
+| `capability-undeclared` | error | A `capability.<id>.<verb>` call the screen's gate denied — reported from the gate itself, so it is raised **even when the worker catches the rejection** (which on device leaves a control that silently does nothing). Fix: declare the id on that screen's `logicBundle.declaredCapabilities` and in `config.ts` `capabilities`. One per capability per screen. See [Capabilities](#capabilities). |
 | `journey-failed` | error | A `himi-test.json` journey named an action the screen lacks, threw, or never rendered its `expectText`. |
 | `inverse-pair-diverges` | **warning** | An action and the action that undoes it do not return to the state the boot settled on — `add` then `remove` leaving a different list, or a counter it forgot to put back. |
 | `refresh-not-idempotent` | **warning** | `refresh` from a fresh boot settles somewhere other than the boot did, on identical data — usually a refresh that appends instead of replacing. |
@@ -267,6 +268,36 @@ went unproven, it names the gap and pairs it with a himi command or a source edi
 derived from what actually ran, never homework. Assembly:
 `tools/himi-cli/src/coverage.ts`.
 
+## Capabilities
+
+A `capability.*` call is answered twice. The main pass answers every granted one with `null` — the
+device's "unavailable" arm — so a screen's declined-camera / no-position path is checked. The
+capability-success pass then re-crawls each screen whose bundle calls a **modelled** capability
+(audio-record, speech, on-device-ai, calls, media-playback, calendar, files, photos, pdf, share,
+open-url, camera, location) with a success answer shaped exactly like the one its SDK binding
+destructures, so the code behind a granted permission runs too. `local_database` and
+`secure_storage` are served from a real session store on both passes.
+
+`--json` carries what each call got as `capabilityCoverage`:
+
+```jsonc
+"capabilityCoverage": {
+  "counts": { "success": 2, "store": 1, "unavailable-only": 1, "denied": 0 },
+  "calls": {
+    "capability.camera.capture":          { "arm": "success",          "screens": ["notes"] },
+    "capability.local_database.getAll":   { "arm": "store",            "screens": ["notes"] },
+    "capability.location.getCurrent":     { "arm": "success",          "screens": ["notes"] },
+    "capability.haptic.play":             { "arm": "unavailable-only", "screens": ["notes"] }
+  }
+}
+```
+
+`unavailable-only` means no model exists yet, so only the declined path of that call has run;
+`denied` means no screen running the call grants its id (each denial is also a
+`capability-undeclared` finding), and `deniedOn` lists screens that deny a call others allow. The
+map is static — it says what a call would be answered with, not that a tap reached it; the gap
+ledger says that.
+
 ## Writes to Wix
 
 Every run lists what the app **writes** to the Wix site, per screen and action — the inventory an

package/guides/qa-builds.md

@@ -326,7 +326,7 @@ one never blocks a rollout — the dist routes just `501` with the reason.
 | `HIMI_DIST_ALLOWED_XCODE_VERSIONS` | comma-separated Xcode versions a caller may pin (`xcodeVersion` in the request body); unset ⇒ the built-in list. Nothing upstream constrains this field — the Job Service client validates it as `z.string().max(50)` — so without the allow-list it is caller-supplied text choosing a toolchain on a shared pool. A blank value reads as unset (the built-in list), never as "allow anything". |
 | `HIMI_DIST_APPLE_SIGNING` | **Minted iOS signing is ON by default** — set `0`/`false`/`off` to disable it and go back to scavenging a profile off the pool. Rarely what you want: minting ships the profile and the certificate with the job, so nothing has to pre-exist on the machine. (Earlier text here cited `0 profile(s) available` on four machines as a reason to keep minting on — that reading came from a TRUNCATED survey and is retracted below; build 992367 logged 352 profiles. The recommendation is unchanged, the evidence for it was wrong.) |
 | `HIMI_DIST_APPLE_API_KEY_NAME` | Apple account the identity is minted under; unset ⇒ `wix-enterprise` |
-| `HIMI_DIST_APPLE_CAPABILITIES` | COMPLETE capability set for a minted id (the sync call replaces rather than merges); unset ⇒ push + associated domains |
+| `HIMI_DIST_APPLE_CAPABILITIES` | Apple capability types to ADD to every minted id. The set itself is derived per job: push + associated domains (the template baseline) plus the Apple capability of every entitlement in the iOS plan of the job's `buildCapabilities` (`appleCapabilitiesForBuild`). This variable only **widens** that derived set (e.g. `APP_GROUPS` for a widget) — it can never remove a derived capability, because the sync call replaces rather than merges and a narrower list would switch off what the content asked for. Unset ⇒ the derived set alone |
 | `QA_DIST_SLACK_CHANNEL` | Post QA build results to a channel instead of DMing the requester. Worth setting: a DM is unreadable by anything but that person, so a channel is what makes build results scriptable (and visible to the team). |
 
 Both per-credential caps are **clamped into the range that can be enforced**, and the two ranges

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@wix/himalaya-cli",
-  "version": "0.1187.0",
+  "version": "0.1189.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": "ffb3ffbafe40c1d9eed8d08db97af4d46cc1506f60fc49e11cf7df80"
+  "falconPackageHash": "6cdd1d60a3c8d77a450fac977716f1d7ded301af4e074c978148513e"
 }