@wix/himalaya-cli 0.1372.0 → 0.1374.0

package/guides/himi-json-output.md

@@ -78,6 +78,28 @@ The `ux_evidence_*` codes map to the existing typed `uxEvidence.state`; a succes
 `recorded` state has no refusal code. Successful pushes and warnings do not gain
 failure codes. A forced push still follows the existing override rules.
 
+## `himi store iap status` codes
+
+Status adds these stable codes to incomplete JSON results. Existing result fields and exit
+statuses are preserved: incomplete status is exit 1; a failed live Wix catalog read is exit 2.
+
+| Code | Meaning |
+|---|---|
+| `price_drift` | Apple differs from the price source's resolved target. |
+| `price_check_unavailable` | An item's price cannot be compared, such as a missing Wix item or changed currency. |
+| `status_incomplete` | Other requested provisioning is incomplete. |
+| `wix_catalog_unavailable` | `--refresh-wix` could not read the site catalog or obtain owner authentication; no manifest fallback occurred. |
+
+Item-level unavailable checks take precedence over drift in the top-level code. Detailed
+`priceSource`, `priceDrift` and `priceCheckIssue` fields live in each item's `provisioning` report.
+Manifest parsing failures retain their legacy envelopes; this is not a whole-command migration.
+
+IAP provisioning refusals from `plan`, `apply` and `status` also expose their existing typed
+`reason` as a top-level `code`: `target` (wrong app, bundle, team or territory), `access`
+(Apple authentication/authorization), `plan` (invalid reviewed plan), `account` (changed
+credential profile or key), and `drift` (Apple changed since planning). Existing `reason` and
+exit statuses remain intact. Manifest parsing failures still use their legacy envelope.
+
 ## `himi store iap connect` codes
 
 `connect` prints one envelope with the whole report. When the setup is not complete it is

package/guides/iap-products.md

@@ -164,7 +164,7 @@ himi store iap connect --manifest ./iap-products.json --profile fit-club-owner \
 | Decision | Meaning |
 |---|---|
 | `create` | absent in Apple; apply will create it and configure it |
-| `update` | an editable draft exists; apply will add only what is missing |
+| `update` | fills missing draft configuration, or changes an eligible `atLeast` price with a reviewed `changePrice` operation |
 | `reuse` | already configured exactly as requested; nothing to do |
 | `conflict` | differs in a way this command will not change; nothing is written |
 
@@ -172,9 +172,14 @@ A **conflict** is any of:
 
 - the same product id with another type;
 - the reference name already used by another product id;
-- a live or in-review product whose metadata, price or availability differs;
-- an existing price or availability that differs;
-- no exact price point for an existing product.
+- a live product whose metadata or availability differs, or an in-review product needing changes;
+- an existing `exact` price or availability that differs;
+- a price change with a different base territory, ambiguous price, custom territory prices, or a future/temporary schedule;
+- no Apple point satisfying the requested price rule, or an unknown product/review state needing changes.
+
+`changePrice` carries `from` and `to` amounts and prints both for review. It changes only
+the price: approved-product metadata and availability remain locked. The command conservatively
+holds in-review changes even though Apple documents price changes as available at any time.
 
 Resolve conflicts in App Store Connect or in the manifest, then plan again.
 
@@ -196,7 +201,9 @@ created. The plan marks this in the item's `notes`.
      write. Planned work that already happened is accepted as done.
 4. For each product, it creates the product, then a draft version, then its
    localizations. Then it sets the exact initial price and the explicit territories. Then
-   it reads everything back.
+   it reads everything back. A `changePrice` instead writes an immediate base-territory price
+   through the same price-schedule API; Apple equalizes the other territories. A changed source
+   price, schedule, review state or resolved target stops apply before the first write.
 5. Writes the result file, even when the run is partial.
 
 **Large catalogs.** App Store Connect allows about 3,600 API requests an hour per key.
@@ -224,6 +231,34 @@ schedule, even without the local journal. Nothing is ever deleted or rolled back
 **`status` is read-only.** It reports what Apple has for each product. Add `--out <file>`
 to save it in the same shape as the result file.
 
+### When the Wix price changes
+
+Price synchronization is explicit; there is no background writer. Refresh a per-item manifest,
+review the new price, then apply:
+
+```bash
+himi store iap draft --site <msid> --profile fit-club-owner --apple-app 6450000001 \
+  --bundle com.example.fitclub --base-territory USA --merge ./iap-products.json --out ./iap-products.json
+himi store iap plan --manifest ./iap-products.json --profile fit-club-owner --out ./iap-plan.json
+himi store iap apply --plan ./iap-plan.json --profile fit-club-owner --out ./iap-result.json
+himi store iap status --manifest ./iap-products.json --profile fit-club-owner --refresh-wix --json
+```
+
+`--merge` refreshes existing per-item `atLeast` amounts while preserving product ids, metadata,
+territories and mappings. Explicit `exact` overrides and shared consumable tiers keep their prices.
+Missing, hidden, free, unsupported or currency-changed Wix items retain their old entry and are
+reported as retained. Review those reports before applying: retaining an entry does not disable it.
+
+Status labels `provisioning.priceSource` as `manifest` by default. `--refresh-wix` requires Wix owner
+authentication and reads the current site catalog without changing the manifest. It reports
+`provisioning.priceDrift: { wix, apple, wouldBe, currency, baseTerritory, source }` when Apple's price
+differs from the resolved target. Normal rounding is not drift. Missing or incomparable data is
+reported as `priceCheckIssue`; a failed catalog read never falls back to the manifest. A live check
+does not reprice shared tiers. Drift or unavailable checks make the overall status incomplete.
+
+Only `atLeast` mismatches can plan a price edit. An `exact` mismatch remains a conflict even when
+a live status check identifies it. Wix order and charge amounts are not changed by this workflow.
+
 ## Connecting the Wix site: `connect`
 
 `connect` makes the manifest's Wix site ready to sell those products, from the same manifest,

package/guides/sdk-reference.json

@@ -1970,11 +1970,23 @@
         "jsdoc": "/** StartItemPayment's CatalogReference: the purchases catalog sells a Stores product under its product\n *  id (eCom's `catalogItemId`). One-time unlocks only, whatever the backend also accepts. */",
         "decl": "export const STORES_PRODUCT_SALE_RULE: AppleSaleRule = { appProductId: (id) => id, productType: \"NON_CONSUMABLE\" };"
       },
+      {
+        "name": "PRICING_PLAN_APPLE_SALES_ENABLED",
+        "kind": "const",
+        "jsdoc": "/** Off until a member's plan order, its cashier item id and Sandbox fulfillment are proven live.\n * Recurring and time-limited plans stay outside this rule; their Billing lifecycle is unfinished. */",
+        "decl": "export const PRICING_PLAN_APPLE_SALES_ENABLED = false;"
+      },
+      {
+        "name": "appleSaleRules",
+        "kind": "function",
+        "jsdoc": "/**\n * The one definition `himi store iap connect` writes mappings by and the mapping source reads them by,\n * keyed by catalog kind. wix-iap StartPayment maps the cashier order's single item id, and Online\n * Programs builds that order with the program id as the item id; programs are one-time unlocks.\n * Wix Stores and one-time unlimited Pricing Plans join only with their independent switches.\n */",
+        "decl": "export function appleSaleRules(options: { storesItemPaymentEnabled?: boolean; pricingPlanAppleSalesEnabled?: boolean } = {}): Readonly<Record<string, AppleSaleRule>>;"
+      },
       {
         "name": "APPLE_SALE_RULES",
         "kind": "const",
-        "jsdoc": "/**\n * The one definition `himi store iap connect` writes mappings by and the mapping source reads them by,\n * keyed by catalog kind. wix-iap StartPayment maps the cashier order's single item id, and Online\n * Programs builds that order with the program id as the item id; programs are one-time unlocks.\n * Wix Stores joins only with `STORES_ITEM_PAYMENT_ENABLED`. Other verticals' order item ids are not\n * established yet, so their items keep their own commerce.\n */",
-        "decl": "export const APPLE_SALE_RULES: Readonly<Record<string, AppleSaleRule>> = STORES_ITEM_PAYMENT_ENABLED\n  ? { onlineProgram: ONLINE_PROGRAM_SALE_RULE, storesProduct: STORES_PRODUCT_SALE_RULE }\n  : { onlineProgram: ONLINE_PROGRAM_SALE_RULE };"
+        "jsdoc": "",
+        "decl": "export const APPLE_SALE_RULES = appleSaleRules();"
       },
       {
         "name": "HostCallExpectation",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@wix/himalaya-cli",
-  "version": "0.1372.0",
+  "version": "0.1374.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": [
@@ -71,5 +71,5 @@
       "artifactId": "himalaya-cli"
     }
   },
-  "falconPackageHash": "602b054ac9fad163cdfcb58bd11d8f387a7af86d300154914f8c0ef6"
+  "falconPackageHash": "4011e5aaa6c46a99bb61a37553ae88008ada74ac054d70c43c09d2fe"
 }