@wix/himalaya-cli 0.1617.0 → 0.1618.0

package/guides/component-reference.json

@@ -2,7 +2,7 @@
   "_comment": "GENERATED by core/web-embed/authoring/gen-reference.mjs from core/ts/src/schema.ts — do not hand-edit. The schema is the source of truth; regenerate on schema changes.",
   "schemaSource": "core/ts/src/schema.ts",
   "bindingGrammar": "$service:<service>.<path> (worker state) · $item.<field> (list row) · $flag:<key> (feature flag) · $env:<key> (client environment — #1056). Bindings resolve in the text/value props marked 'binding-aware' below — INCLUDING Modifiers token refs — but only `background` and `border.color`, which are the two whose token a binding actually fills: a worker can drive per-item theming (e.g. a game board's per-square color), not just text. `shadow` is NOT binding-aware on any renderer, and a gradient is driven by its own `backgroundGradientPath` prop resolving to a gradient token NAME, not by a binding inside a token ref — so `shadow: { token: \"$item.x\" }` and `backgroundGradient: { token: \"$item.x\" }` keep the sentinel and silently lose the per-item styling. Colour slots split by LEVEL, not by component: inside modifiers a colour is a TokenRef OBJECT ({ token: \"…\" }), inside props it is a bare TokenName STRING — there is no modifiers.color or modifiers.tint (see the 'Token slots' section in component-reference.md). A few input props render the LITERAL and are NOT binding-aware — notably SearchField.placeholder and Chip.label; SearchField.value is live and binding-aware like other content props. Bindings also CANNOT target strict-enum fields (style, size, alignment, severity, presentation, contentMode, …) — those fail at render, not validation. $env: is client-resolved (no worker) and valid in modifiers.hiddenPath and FragmentSlot.casePath ONLY — keys reduceMotion/colorScheme/sizeClass/isRTL/keyboardVisible, e.g. hiddenPath:\"$env:reduceMotion\" or hiddenPath:\"$env:colorScheme==light\", casePath:\"$env:colorScheme\"; unknown key fails open (shown / defaultCase).",
-  "componentCount": 88,
+  "componentCount": 89,
   "notImplementedComponents": [
     "Text",
     "Icon",
@@ -97,6 +97,15 @@
       ],
       "propsSource": "export interface ErrorStateProps {\n  /** Default `\"server\"`. An unknown value is treated as `\"server\"`. */\n  variant?: \"server\" | \"offline\" | \"permission\" | \"signIn\";\n  /** `$service:` binding that selects the variant at runtime; wins over `variant`. */\n  variantPath?: string;\n  title?: string;\n  body?: string;\n  /** The CTA's action. Absent → no button. */\n  cta?: Action;\n  ctaLabel?: string;\n  /** `\"screen\"` (default, ~96px from the top) or `\"section\"` (~24px). */\n  placement?: \"screen\" | \"section\";\n}"
     },
+    {
+      "name": "QrCode",
+      "category": "Core",
+      "propsType": "QrCodeProps",
+      "bindings": [
+        "valuePath"
+      ],
+      "propsSource": "export interface QrCodeProps {\n  /** Literal payload (UTF-8). One of `value` / `valuePath` is required. */\n  value?: string;\n  /** `$service:` / `$item.` binding for the payload; wins over `value` once it resolves to a\n   *  non-empty string (until then — no worker yet, an empty field — `value` draws). */\n  valuePath?: string;\n  /** Side length (pt/dp/px), quiet zone included. Default `160`. */\n  size?: number;\n  /** Default `\"M\"`. A literal over the level's capacity is a validator error. */\n  errorCorrection?: \"L\" | \"M\" | \"Q\" | \"H\";\n  /** Module colour token. Default `\"textPrimary\"`. */\n  color?: string;\n  /** Background colour token. Default `\"surfacePrimary\"`. */\n  background?: string;\n  /** Light margin, in modules. Default `4` (the spec minimum). */\n  quietZone?: number;\n}"
+    },
     {
       "name": "Text",
       "category": "Core",

package/guides/component-reference.md

@@ -3,7 +3,7 @@
 > GENERATED from `core/ts/src/schema.ts` by `core/web-embed/authoring/gen-reference.mjs`.
 > The schema is the source of truth — regenerate on schema changes; do not hand-edit.
 
-**88 core component types.** Every component body is `{ "package": "himalaya", "type": "<Type>", "props": { … } }`.
+**89 core component types.** Every component body is `{ "package": "himalaya", "type": "<Type>", "props": { … } }`.
 Binding grammar: `$service:<service>.<path>` (worker state) · `$item.<field>` (list row template) · `$flag:<key>` (feature flag) · `$env:<key>` (client environment — #1056).
 Bindings resolve in the text/value props marked **binding-aware** below — **including two `Modifiers` token refs**, `background` and `border.color`, which are the only two whose token a binding actually fills: a worker can drive per-item **theming** (e.g. a game board's per-square color, `background: { token: "$item.bg" }`), not just text content. `shadow` and `backgroundGradient` are `TokenRef`s but are **not** binding-aware on any renderer — `shadow: { token: "$item.x" }` keeps the sentinel as a literal token name and silently loses the per-item styling, and a gradient is driven by its own `backgroundGradientPath` prop resolving to a gradient token NAME, not by a binding inside a token ref.
 `$env:` is **client-resolved** (no worker) and valid in `modifiers.hiddenPath` and `FragmentSlot.casePath` **only** — keys `reduceMotion` / `colorScheme` / `sizeClass` / `isRTL` / `keyboardVisible` (an on-screen keyboard is up — `hiddenPath: "$env:keyboardVisible"` hides a header while typing), with an optional `==`/`!=` comparison (e.g. `hiddenPath: "$env:reduceMotion"`, `hiddenPath: "$env:colorScheme==light"`, `casePath: "$env:colorScheme"`). An unknown key fails open (shown / `defaultCase`).
@@ -38,6 +38,7 @@ See also **[Modifiers](#modifiers)** (the `modifiers` block) and **[Actions](#ac
 | `Spacer` | Core | — |
 | `EmptyState` | Core | — |
 | `ErrorState` | Core | `variantPath` |
+| `QrCode` | Core | `valuePath` |
 | `Text` | Core | `text` |
 | `Image` | Core | `url`, `initials`, `contentDescription` |
 | `Icon` | Core | — |
@@ -120,7 +121,7 @@ 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: 7 of 88 components, all of them android / web / ios-only** — every other component/platform pair reads every prop it decodes. The list splits in two, and the halves mean different things:
+**Scope: 7 of 89 components, all of them android / web / ios-only** — every other component/platform pair reads every prop it decodes. The list splits in two, and the halves mean different things:
 
 - **`category` (2: `MediaPlayer`, `TimeGrid`)** — 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.
 - **`styling` (5: `Text`, `Icon`, `WebView`, `Video`, `PdfView`)** — the component itself **works**; only the listed prop is inert. Use the component; just do not depend on that one prop.
@@ -438,6 +439,28 @@ export interface ErrorStateProps {
 }
 ```
 
+#### QrCode
+
+```ts
+export interface QrCodeProps {
+  /** Literal payload (UTF-8). One of `value` / `valuePath` is required. */
+  value?: string;
+  /** `$service:` / `$item.` binding for the payload; wins over `value` once it resolves to a
+   *  non-empty string (until then — no worker yet, an empty field — `value` draws). */
+  valuePath?: string;
+  /** Side length (pt/dp/px), quiet zone included. Default `160`. */
+  size?: number;
+  /** Default `"M"`. A literal over the level's capacity is a validator error. */
+  errorCorrection?: "L" | "M" | "Q" | "H";
+  /** Module colour token. Default `"textPrimary"`. */
+  color?: string;
+  /** Background colour token. Default `"surfacePrimary"`. */
+  background?: string;
+  /** Light margin, in modules. Default `4` (the spec minimum). */
+  quietZone?: number;
+}
+```
+
 #### Text
 
 ```ts

package/guides/designing-himi-screens.md

@@ -317,7 +317,9 @@ dense row); `ProgressBar` for determinate progress, `ActivityIndicator` for inde
 a single dial metric. *Use a `Badge` for a count, a `Tag` for a category — they aren't interchangeable.*
 
 **Media** — `Image` (`fillWidth`, `height`, always `contentDescription`); `Video`/`Lottie`/`Rive` for
-motion media; `Map` for location; `Avatar` for a person; `WebView` only when native can't express it.
+motion media; `Map` for location; `Avatar` for a person; `QrCode` to share a link, ticket or invite
+as a code generated on the device (bind `valuePath`; keep the payload short, since a literal over the
+level's capacity fails validation); `WebView` only when native can't express it.
 *Fill-width media gets a `cornerRadius` so it doesn't fight the card edges.*
 For audio apps, keep playback UI in SDUI and call `@himalaya/media-playback` from the Tier-5 worker:
 compose artwork with `Image`, transport controls with icon buttons, scrubbing with `Slider`, buffering

package/guides/hhp.md

@@ -213,10 +213,12 @@ A screen may also carry `params` (the navigation input a device opens it with, u
 himi fidelity --content <dir> [--screen a,b] [--variant light,dark,rtl,tablet] [--ios <udid>] [--android <serial>] [--ios-tablet <udid>] [--android-tablet <serial>] [--app-id <id>] [--release <id>] [--serve <port>] [--no-native] [--json] [--post-pr <n>]
 ```
 
+`rtl` runs only when config.ts `locale.default` or `locale.translations` names a right-to-left language the Player supports (today `he`), and `locale.pin` does not pin a left-to-right default. A language picked inside the app also outranks the device, and the command cannot read or reset it: on a device where the app's language was changed in the Player, reinstall the Player before an `rtl` run. The Player follows the app's locale, so an app that ships no such language stays left-to-right on a Hebrew device, and comparing it with a mirrored page would only report that. Otherwise every `rtl` row is reported `skipped` with the reason.
+
 For each screen and variant (`light`, `dark`, `rtl`, `tablet`), the command does four things:
 
 1. **Captures the mockup.** It draws the page in Chromium at the variant's width. Dark mode is drawn by emulating `prefers-color-scheme`. RTL is drawn by setting `dir=rtl` on the page.
-2. **Captures the web render** from the app's recorded data, as `himi render` does by default. Native frames come from Himi Player on the devices you pass: `--ios <udid>` and `--android <serial>`, plus `--ios-tablet` and `--android-tablet` for the tablet variant. Only those devices are touched. For each variant the command sets dark or light appearance and, for `rtl`, the Hebrew language (iOS `AppleLanguages`, Android per-app locale, API 33+). It opens `himi://app/<app>/screen/<screen>` and captures once two frames match. Every setting it changed is restored afterwards, also on Ctrl-C. A variant with no device is reported `skipped`, never passed. Without `--release <id>` or `--serve <port>` the Player shows the app's **live** release, not your working copy. `--serve <port>` serves the working copy on `127.0.0.1:<port>` as `himi run` does, so native and web render the same release. The Player reads a local origin only from a Debug build that compiled it in (see [View your package on a device](himi-player-implementation.md#view-your-package-on-a-device)): build it with `HIMALAYA_API_BASE_URL_INFO=http://127.0.0.1:<port>` on iOS and `-PhimalayaDevServeBaseUrl=http://10.0.2.2:<port>` on Android. An iOS device whose Player reads another origin is skipped with the rebuild to run. Android's origin cannot be read back from the installed app, so check that build yourself. A screen that declares `params` is skipped natively for now, because the Player's deep link does not carry them yet. On a fresh iOS simulator, open one `himi://` link by hand first and accept iOS's "Open in Himi Player?" prompt: the command cannot answer it, and until it is accepted every iOS capture shows the prompt.
+2. **Captures the web render** from the app's recorded data, as `himi render` does by default. Native frames come from Himi Player on the devices you pass: `--ios <udid>` and `--android <serial>`, plus `--ios-tablet` and `--android-tablet` for the tablet variant. Only those devices are touched. For each variant the command sets dark or light appearance and, for `rtl`, the app's right-to-left language (iOS `AppleLanguages`, Android per-app locale, API 33+). It opens `himi://app/<app>/screen/<screen>` and captures once two frames match. Every setting it changed is restored afterwards, also on Ctrl-C. A variant with no device is reported `skipped`, never passed. Without `--release <id>` or `--serve <port>` the Player shows the app's **live** release, not your working copy. `--serve <port>` serves the working copy on `127.0.0.1:<port>` as `himi run` does, so native and web render the same release. The Player reads a local origin only from a Debug build that compiled it in (see [View your package on a device](himi-player-implementation.md#view-your-package-on-a-device)): build it with `HIMALAYA_API_BASE_URL_INFO=http://127.0.0.1:<port>` on iOS and `-PhimalayaDevServeBaseUrl=http://10.0.2.2:<port>` on Android. An iOS device whose Player reads another origin is skipped with the rebuild to run. Android's origin cannot be read back from the installed app, so check that build yourself. A screen that declares `params` is skipped natively for now, because the Player's deep link does not carry them yet. On a fresh iOS simulator, open one `himi://` link by hand first and accept iOS's "Open in Himi Player?" prompt: the command cannot answer it, and until it is accepted every iOS capture shows the prompt.
 3. **Scores mockup↔web** with ImageMagick SSIM, globally and per tile. The worst tile says where the screens differ most.
 4. **Asks a fresh model** two questions, using the repo's fidelity judge prompt. The model never ran in the session that wrote the app.
    - **Design:** does WEB look like the MOCKUP? This judges the port.

package/guides/himi-json-output.md

@@ -83,10 +83,20 @@ publication readiness or bound metadata not yet supplied to the final push.
 | --- | --- |
 | `invalid_usage` | Missing, repeated or unsupported checker arguments. |
 | `payment_review_unreadable` | The collected source evidence or site-bound payment review cannot be read or verified. |
-| `payment_decision_required` | Payment intent, readiness evidence or an explicit owner decision remains unresolved before scaffolding. Selecting connect-provider waits for setup and a new review. |
+| `payment_decision_required` | Payment intent, site-bound evidence, target checkout compatibility or a required owner decision remains unresolved before scaffolding. Selecting connect-provider waits for setup and a new review. Unknown payment readiness alone does not refuse a reviewed, supported existing checkout. |
 
 The checker validates recorded evidence and decisions; it does not independently
 verify merchant readiness or create transactions. General publication remains unchanged.
+Newly collected schema-2 payment reviews require checkout compatibility evidence
+for every online-paid flow. Legacy schema-1 completed ready reviews remain accepted
+without that field.
+
+Successful checks include a `warnings` array. When an existing paid flow proceeds
+with unverified payment readiness and supported target checkout, it contains
+`{ code: "payment_readiness_unverified", flowId, message }` for that flow. This is
+advisory: it does not mean payments are disconnected, does not require an owner
+decision and does not certify a successful purchase. Other successful reviews
+return an empty array.
 
 ## `himi one-app validate-identity` codes
 

package/guides/index.json

@@ -1,7 +1,7 @@
 {
   "_comment": "AUTO-GENERATED by tools/authoring-kit/bundle.mjs — DO NOT EDIT. Regenerate with: npm run authoring:gen",
   "schemaStamp": {
-    "componentCount": 88,
+    "componentCount": 89,
     "schemaSource": "core/ts/src/schema.ts"
   },
   "portalUrl": "https://apps.wix.com/_api/himi-serve/docs",

package/guides/one-app-section-mappings.md

@@ -31,6 +31,38 @@ Source snapshots: Catalyst `617c06d43d2a5608b6876d724553269b1e5346f0`; Himalaya
 
 ## Mappings by server group
 
+### Member-only visibility during migration
+
+The following eleven definitions omit `visitorModeEnabled`, whose source default
+is false. Their authentication visibility is supported through
+`oneAppSection`/`createOneAppSectionService`: hidden for visitors and unresolved
+authentication, visible after confirmed sign-in subject to all other restrictions,
+hidden again after sign-out. This visibility support does not change a row's data/UI
+mapping classification or certify an unimplemented vertical.
+
+| Section definition | Visibility migration rule |
+| --- | --- |
+| `food_section` | Signed-in-only; preserve instance settings, content and ordering. |
+| `newBlog_submit_post_section` | Signed-in-only; preserve author permissions, settings and ordering. |
+| `selections` | Signed-in-only; preserve instance settings, content and ordering. |
+| `file_share_section` | Signed-in-only; preserve folder/file access, settings and View All action. |
+| `events_guests_section` | Signed-in-only; preserve event scope, guest privacy and settings. |
+| `events_discussion_section` | Signed-in-only; preserve event scope, discussion settings and actions. |
+| `performance_tracker_section` | Signed-in-only; preserve member performance, settings and tracker CTA. |
+| `achievements_participant_carousel_section` | Signed-in-only; preserve member participation/progress, settings, default limit 5 and participant-programs CTA. |
+| `memberships_packages_section` | Signed-in-only; preserve member plan orders, balances/credits, settings and MyMemberships CTA. |
+| `upcoming_bookings_section` | Signed-in-only; preserve upcoming-only selection, settings, limit and ActivityFeedCards CTA. |
+| `loyalty_status_section` | Signed-in-only; preserve member points, tier/status and display settings. |
+
+Use the collected definition when present, including an explicit visitor-enabled
+override; otherwise the migration graph uses these pinned stable IDs. Preserve
+general experiments, visitor experiments and other conditions, with unknown values
+unresolved. Apply the same gate to layouts, detached layouts and Business Profile
+placements of these eleven types, keeping duplicate instances separate. Other
+section types retain their existing visibility/access behavior and receive no new
+authentication gate, including when their definitions are absent. See the current migration guide's
+[visibility recipe and deterministic test contract](https://apps.wix.com/_api/himi-serve/docs/one-app-to-himi-app.md#preserve-section-visibility-across-authentication).
+
 The **Himalaya implementation** cell is blank for every unassigned row. Notes on existing partial building blocks are not fallback selections.
 
 ### 1. mobile-app-widgets-section-definitions.json

package/guides/one-app-to-himi-app.md

@@ -164,6 +164,14 @@ The CLI's versioned native-widget inventory supplies these rows automatically.
 | `newBlog_postlist_vertical_section`, `newBlog_compact_post_list_vertical_section` | Row display options, unlimited paging or a limited count with See All Posts, and layout. Coverage derives these per placement from the authored settings: see "Generate blog post lists from their settings". |
 | `events_list_section` | Date badge, Share and the appropriate RSVP/ticket action. |
 | `platform_general_members_section`, `platform_general_members_section_bp` | Effective member strip and directory journey: totals/search, alphabetical sections, Follow, activity/privacy. Distinguish badge chips from actual viewed-member program progress. |
+| `file_share_section` | Signed-in-only file/folder section. Preserve access rules, instance settings and View All (`media.openFileShareListScreen`); a media gallery is not File Share. |
+| `events_guests_section` | Signed-in-only guests for the configured event, preserving the event selector, guest privacy and display settings; an avatar summary is not the full guest list. |
+| `events_discussion_section` | Signed-in-only discussion for the configured event, preserving its selector, settings and actions; do not substitute a group feed or blog comments. |
+| `performance_tracker_section` | Signed-in-only member performance tracker, settings and `wix.bookings.performanceTrackerCTA`; do not substitute a generic steps/session-goal widget. |
+| `achievements_participant_carousel_section` | Signed-in-only participating-programs carousel with actual member progress, source selectors/settings, default limit 5 and `wix-one-app-achievements.ParticipantChallengesScreen` CTA; not the public Programs catalog. |
+| `memberships_packages_section` | Signed-in-only memberships/packages, including member plan orders, package balances/session credits, authored settings and `memberships.screens.MyMemberships` CTA. |
+| `upcoming_bookings_section` | Signed-in-only upcoming member bookings, preserving upcoming-only selection, source limit/settings and `wix.bookings.activities.ActivityFeedCards` CTA; do not include historical bookings. |
+| `loyalty_status_section` | Signed-in-only member points, tier/status and authored display settings; the public rewards catalog does not implement member status. |
 
 This initial checklist comes from reported native source-device observations
 on 2026-11-02 across two migrations, not editor demo records.
@@ -177,6 +185,92 @@ no adaptation waiver, and this checklist must not force the disabled control on.
 Data/access-dependent controls need the relevant source state; never fabricate
 participants or derive program completion from a badge title.
 
+### Preserve section visibility across authentication
+
+The eight member-only rows above are supported by the shared visibility recipe below;
+their data/UI implementation still needs the per-section mapping and live verification.
+The same visibility rule also applies to `food_section`,
+`newBlog_submit_post_section` and `selections`; these three are intentionally not
+added to the native-defaults table.
+
+OneApp's section-definition contract defaults omitted `visitorModeEnabled` to
+`false`. The eleven IDs above omit it in the pinned source definitions. The source
+graph records `sectionVisibility[sectionId]` **only for these eleven definition IDs**, deterministically from collected
+`definitions.sections[sectionDefinitionId]`, falling back to those pinned IDs
+only when the definition is absent. A collected explicit `true` takes precedence.
+For these eleven types, malformed definitions or flags/experiment lists remain unresolved; never
+guess from a display name. The raw section instances, settings, permissions and
+placement order remain intact, even when absent from the visitor-enriched view.
+
+All other section types keep their existing visibility and access behavior. Do not
+wrap them in this new authentication gate or infer member-only access from missing
+definitions. An absent `sectionVisibility[sectionId]` means this recipe does not
+apply; it does not mean hidden or unresolved. Preserve their existing permission,
+experiment and other source restrictions separately.
+The graph omits `sectionVisibility` entirely when no reviewed placements exist;
+use `graph.sectionVisibility?.[sectionId]` when selecting the recipe.
+
+For every placement **of these eleven types** in screen layouts, detached layouts and the Business Profile:
+
+- Keep the section hidden while authentication is unresolved and while signed out.
+  Show it after successful sign-in in its original position, subject to its other
+  permission/OS/paid-plan and general experiment conditions. Hide it after sign-out.
+  Cancelled or failed sign-in does not reveal it; restored sessions reveal it only
+  after identity is established. Keep content/configuration, not the last member's
+  runtime data.
+- Preserve `experiments` for every identity. For visitor-enabled definitions,
+  require all `visitorModeExperiments` for visitors; unknown values are unresolved,
+  never assumed true. General restrictions continue to apply after sign-in.
+- Use `oneAppSection` and `createOneAppSectionService` from
+  `@wix/himalaya/screens` in the screen's worker. Assign a distinct stable service
+  and wrapper ID to every placement, including repeated types and profile copies.
+  Declare `wix_platform` and `app_info`, and set the screen bundle's
+  `minBinaryVersion: "1.9.0"` (`min_binary_version` on the wire), for identity reads and the host's reserved
+  `onIdentityChange` hook (iOS/macOS, Android and web). No rebuild or remigration
+  is needed on identity changes. Older hosts without this hook need a runtime
+  update; a one-time identity read alone is not parity. The helper also checks the
+  native binary version and hydration/persistence support (the web host uses
+  the advertised `identityChangeVersion` feature support, since its version is a
+  placeholder), resets legacy hydrated data
+  synchronously and stays hidden without reads on an incompatible runtime.
+- Pass the graph's visibility rule to the service, current experiment values via
+  `experiments`, and the conjunction of the other rules via `otherAllowed`.
+  Pass `getIdentity: () => auth.getIdentity()` from the screen worker's
+  `@himalaya/wix-platform` import; the helper calls it only after runtime compatibility checks.
+  Call `load` when non-auth conditions change. Supply the member read through
+  `read`, bind its `data`/`loading`/`error` state in the authored content,
+  and compose it inside `oneAppSection(content, {id, service})`. Do not start an
+  eager member worker or read outside the gate. The helper's empty hidden
+  FragmentSlot case does not mount member controls/onAppear actions. It clears
+  runtime data on identity changes and drops late reads from the previous identity.
+
+Coverage derives an `access-state` obligation only for placements with a visibility rule in that scoped map.
+Do not mark it supported on a manual screenshot or AI evaluation alone: run
+deterministic tests asserting migration output and observable rendered sections.
+Parameterize all eleven IDs; assert unchanged content/settings/order and stable
+repeat output; cover visitor → successful sign-in → sign-out, unresolved/restored
+identity, cancelled/failed sign-in, duplicate instances, layouts plus Business
+Profile, mixed public/private screens, omitted/false/true flags, experiments and
+other restrictions. Assert zero hidden member reads and reject late results after
+sign-out or account changes. Keep the test command/results and rendered evidence
+with the exact release's coverage records.
+Verify non-target section types, including those with absent definitions, receive
+no new gate or authentication obligation and retain their content and placement.
+
+For a signed-in-only placement, the passed `access-state` record must include
+`sectionVisibility: {kind: "automated", command, hiddenMemberReads: 0, states,
+testReport: {path, sha256}}`. The report path is relative to the content root and
+its SHA-256 must match the actual test report. `states` must assert
+`unresolved`, `visitor`, `signedOut`, `cancelled`, `failed` and
+`otherRestricted` as `"hidden"`, and `signedIn`/`restored` as `"visible"`.
+The check's existing requirement ID, target and release hash still apply.
+Coverage verification rejects a generic/manual pass, missing assertions or changed
+test reports. These records report tests actually run, never invented evidence.
+
+Source evidence: [section definitions](https://github.com/wix-private/catalyst-server/tree/617c06d43d2a5608b6876d724553269b1e5346f0/one-app-sections/one-app-sections-definitions/src/main/resources/sections),
+[visitor criteria](https://github.com/wix-private/mobile-apps-editor/blob/53cac5fabd41f761632d3574b6a74624c2816427/packages/mobile-apps-editor-middleware/src/domain/EnrichedStructure/DisplayCriteria.ts#L161)
+and [layout/profile filtering](https://github.com/wix-private/mobile-apps-editor/blob/53cac5fabd41f761632d3574b6a74624c2816427/packages/mobile-apps-editor-middleware/src/domain/EnrichedStructure/EnrichedViewer.ts#L293).
+
 ### Generate blog post lists from their settings
 
 A migrated blog list is app-authored, not a template screen, so nothing makes it match the source
@@ -845,13 +939,39 @@ The readiness `metaSiteId` must match this migration's collected site. `state` i
 when it was checked. Use verified site-bound owner payment settings or a proven
 read-only contract when available. A denied or unavailable read remains
 `unverified`, with the actual access gap recorded. Never infer provider eligibility
-from the site's country. Ready evidence permits `decision: { action: "proceed" }`.
-For missing or unverified setup, tell the owner what is known and ask them to:
-
-- `connect-provider`: complete setup in their site dashboard, then recheck before
-  generating that paid UI. Migration does not connect the provider itself.
+from the site's country. The target must stay bound to the same site; preserve its
+existing payment configuration instead of asking the owner to connect it again.
+
+Review the source purchase action against the target's checkout path, including
+the vertical, payment method and any native in-app purchase requirements. Record
+`checkout: { state, evidence }`, where `state` is `supported`, `unsupported` or
+`unverified` and `evidence` names the source flow and target implementation. Do not
+mark an unsupported target ready just because the merchant has a provider.
+Newly collected reviews use `schemaVersion: 2` and require `checkout` for every
+online-paid flow, including those with verified merchant readiness. Legacy
+schema-1 ready reviews without `checkout` remain accepted for compatibility.
+Do not downgrade a newly collected review to bypass its checkout check.
+
+If payment readiness is `ready`, use `decision: { action: "proceed" }` unless the
+checkout review identifies a gap. If readiness is `unverified` and checkout is
+`supported`, preserve the existing flow by default: omit `decision` or record
+`{ action: "proceed" }`. No owner decision or pre-checkout warning is required
+solely because the payment settings read is unavailable. Keep the uncertainty in
+the review and migration report; the checker returns a per-flow
+`payment_readiness_unverified` warning without refusing generation. Do not tell
+the owner or customers that payments are disconnected based on an unavailable read.
+
+For confirmed missing setup or a target checkout gap, explain the specific issue
+and ask how to proceed. Investigate unverified target compatibility before asking
+the owner to choose an adaptation. The available decisions are:
+
+- `connect-provider`: for confirmed missing payment setup, complete setup in their
+  site dashboard, then recheck before generating that paid UI. Migration does not
+  connect the provider itself. Connecting a provider cannot resolve an unsupported
+  target checkout.
 - `retain`: keep the flow with a localized explanation **before checkout** that
-  payments are unavailable or unverified, plus a real contact or back action.
+  describes the confirmed issue or unresolved compatibility, plus a real contact
+  or back action. Do not claim missing payment setup when its status is unknown.
   Record that copy in `decision.explanation` and the actual planned recovery in
   `decision.recovery`: `{ action: "back" }` or `{ action: "contact", target:
   "<real contact route>" }`. Implement the copy and action in the target; the
@@ -860,17 +980,21 @@ For missing or unverified setup, tell the owner what is known and ask them to:
   and the remaining free/offline content.
 
 Record their instruction in `decision.instruction`; cite an existing explicit
-instruction instead of asking again. Run `himi one-app validate-payments
+instruction instead of asking again; an existing retain/hide/connect-provider
+instruction still applies when the payment read is unavailable. Run `himi one-app validate-payments
 --evidence-dir .himi/one-app --json` before scaffolding. It reads this editable
 review and the hash-verified collected source, checks decisions and site binding,
 and creates nothing. A passing check validates the recorded plan, not the truth
 of merchant readiness. The review's original manifest hash describes the initial
 template; edit the review without rewriting collected evidence or manifest hashes.
 Keep the decision, resulting target controls and controlled runtime evidence in
-the reconstruction plan and migration report. For retained flows, handle the exact
+the reconstruction plan and migration report. For all paid flows, handle the exact
 structured `SITE_NOT_ACCEPTING_PAYMENTS` failure with clear recovery; unrelated
 HTTP 428 failures must retain their own meaning. Test paid/free/offline and
-missing/ready/unverified cases without real transactions. General app validation
+missing/ready/unverified cases and target checkout compatibility without real
+transactions. If a purchase worked in the original app but fails after migration,
+investigate the target checkout and site binding before attributing it to the
+owner's payment setup. General app validation
 and publishing do not gain a new payment gate.
 
 Write `SPEC.md` and `MOBILE-UX.md` in the workspace. Use the current

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@wix/himalaya-cli",
-  "version": "0.1617.0",
+  "version": "0.1618.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": [
@@ -72,5 +72,5 @@
       "artifactId": "himalaya-cli"
     }
   },
-  "falconPackageHash": "ca22226ed33669cefe5f25805d924885e9f4472817b9be7ad316e2d1"
+  "falconPackageHash": "53661afff21585080db36c8653b597e5ec6bbe96697d7157bf90ee05"
 }