{
  "schemaVersion": 1,
  "description": "Capabilities we have profiled but not yet resolved to a Wix target. PENDING IS THE DEFAULT: any capability without a target entity is pending, whether or not it is listed here. Listing it adds our working note — why we think a target does or does not exist, and what to author.\n\n`suspected` is OUR guess and carries no authority:\n  - target-exists : we believe Wix can receive this; `plannedTarget` names the entity to author.\n  - no-target     : we believe Wix cannot represent this. This is still PENDING. Only a human can turn it into a verdict, and there are exactly two signed destinations, both mutually exclusive with this file: requires-development.json (\"Wix has no surface — build it first\") and the `capabilities[]` register in no-migration-needed.json (\"nothing to move\" — the outcome exists in Wix or was never data).\n\nAn agent may never conclude that Wix cannot do something. Two such conclusions have already been wrong (gift cards and events both had a create API), so the automation is limited to 'profiled' or 'pending' and the impossibility verdict is reserved for a named human.",
  "capabilities": [
    {
      "capability": "commerce.gift-card-activity",
      "reason": "PW WooCommerce Gift Cards keeps a per-card activity ledger (issuance, redemptions, adjustments — the rows its balances are summed from) in the same plugin-owned custom tables as the cards. Durable historical data, doubly unplaced: the source side is db-only (free v2.47 registers no REST surface at all, VERIFIED LIVE 2026-08-16), and Wix has no public method to write historical gift-card transactions (gift-cards/gift-card pitfall no-transaction-history-import).",
      "searched": "gift card transaction history, redemption history, gift card activity, stored value ledger — dev.wix.com business-solutions/gift-cards (docs-survey sweep evidence on gift-cards/gift-card, 2026-08-11): create accepts initialValue only; balance is derived; no historical-transaction write. The domain entity's documented fallback for history is a CMS archive.",
      "suspected": "target-exists",
      "plannedTarget": "cms/data-item — a CMS archive collection per gift-cards/gift-card fallbacks[0]; needs a human to confirm whether an archive is wanted or history is accepted as reportable loss (the sibling woocommerce-gift-cards profile records it as reportable loss).",
      "note": "Authored 2026-08-16 with the pw-woocommerce-gift-cards profile. Deliberately NOT declared in the profile's capabilities[]: classifyCoverage associates capabilities with ALL of a plugin's entities (per-plugin union), so a declared-but-unplaced capability on a profile whose other entities carry known refs would misclassify as migration-planned via api instead of pending — a classifier coarseness worth a finding."
    },
    {
      "capability": "members.domain-restricted-login",
      "reason": "Social-login / SSO plugins (Nextend Social Login, miniOrange, OAuth/OIDC client plugins) configured with an organization-restricted identity source — e.g. a Google OAuth client limited to one Workspace domain ('internal' app type / hd claim), or a corporate OIDC/SAML IdP — so only organization users can log in. Wix's native social login is the consumer Google/Facebook toggle on the default signup form with no domain-restriction setting, so migrating to the native toggles silently downgrades 'internal only' to 'anyone with a Google account'. The open (unrestricted) social-login case is NOT this capability — that is reconfigure-in-wix via the native toggles, with the caveat that Wix supports Google and Facebook only (default form only) and every other provider a plugin offers (Apple, X, LinkedIn, Kakao, ...) is a reportable loss.",
      "searched": "social login, SSO, site members, restrict login to organization, OIDC — searched support.wix.com and dev.wix.com 2026-08-16 (WebSearch/WebFetch). Found: support.wix.com/en/article/managing-signup-login-and-security-settings-for-your-site-members (native social login = Google + Facebook toggles, no restriction settings); support.wix.com/en/article/request-social-login-buttons-on-the-custom-signup-form (social buttons on default form only); support.wix.com/en/article/sso-setting-up-single-sign-on-sso-login-for-your-site-members (member SSO via OIDC IdP exists but is Wix Studio Enterprise / Wix Channels only — the domain restriction is enforced at the IdP); dev.wix.com/docs/develop-websites/articles/code-tutorials/wix-editor-elements/using-oauth-sso-with-velo (hand-built alternative = development, not migration).",
      "suspected": "target-exists",
      "plannedTarget": "Members SSO (Wix Studio Enterprise / Wix Channels): connect the organization IdP over OIDC and keep the restriction enforced at the IdP — but this is PLAN-GATED, so it is not a mapping the planner can apply unconditionally. A human must decide how the plan surfaces the choice when the target site is not Enterprise: (a) recommend Enterprise, (b) native Google login + manual member approval (administrative gate, not auth-time enforcement), or (c) Velo custom OAuth (requires-development). Silent downgrade to open social login must not be an option.",
      "note": "Observed with Nextend Social Login on a live WordPress installation. Detection caveat: the restriction lives in the IdP-side OAuth client configuration, not in any WordPress-readable setting — REST discovery can see the plugin but cannot see that its client is org-restricted, so this capability likely needs an operator question or login-page probing to detect at all. No data moves in either variant: members migrate via the member import and re-associate by email match at first social/SSO login."
    },
    {
      "capability": "commerce.membership-content-access",
      "reason": "The access-control half of a WooCommerce membership plan, which is the larger half. A WP Swings membership plan carries wps_membership_plan_target_ids / _target_categories / _target_tags (gated products), _post_target_ids / _target_post_categories / _target_post_tags (gated posts), _page_target_ids (gated pages), member-benefit rules (wps_membership_plan_offer_price_type + wps_memebership_plan_discount_price member discount, wps_memebership_plan_free_shipping, wps_membership_plan_hide_products, wps_set_maximum_product_purchase_limit) and delayed-access controls (wps_membership_plan_access_type, _time_duration/_type). Wix has the OUTCOME but not an importable target: page permissions can be gated on a purchased Pricing Plan, and Blog and Groups can be limited to plan holders, but all of it is Editor/dashboard configuration with no documented public write API mapping 'plan X unlocks page/product/post Y'. The one API-writable fragment is stores/product `purchaseEligibility.userCriteria: MEMBERS_ONLY`, which is binary members-only with no per-plan granularity and does not cover posts, pages, discounts or shipping. So the plan and the enrollment migrate (pricing-plans/plan and pricing-plans/plan-order), and what they unlock does not travel with them — members would land holding plans that gate nothing until an owner reconfigures.",
      "searched": "members-only content, restrict page access, content gating, paywall, member discount, plan-gated pages — dev.wix.com and support.wix.com 2026-08-16 (WebSearch + WebFetch). dev.wix.com: api-reference/business-solutions/pricing-plans (Plans V3 + Orders — plan objects carry no entitlement/benefit/target field); catalog-v3/products-v3/product-object.md (purchaseEligibility.userCriteria enum MEMBERS_ONLY, no plan reference); business-solutions and app-management permission trees searched for a page-permissions write API — only app authorization scopes surfaced, no site-page permission endpoint. support.wix.com: pricing-plans-making-site-pages-members-only, wix-editor-applying-page-permissions, cms-restricting-access-to-dynamic-content-by-member-roles-or-by-paying-subscribers, pricing-plans-limiting-your-blog-to-members-who-purchased-a-pricing-plan, wix-stores-creating-restricted-store-pages — all describe Editor/dashboard configuration, none an API.",
      "suspected": "no-target",
      "plannedTarget": null,
      "note": "Authored 2026-08-16 with the membership-for-woocommerce profile. 'no-target' here means no importable target, NOT that Wix lacks the feature — the likely signed destination is the capabilities[] register in no-migration-needed.json with reason reconfigure-in-wix, listing the gated-object inventory as an owner task, rather than requires-development.json. A human picks. Deliberately NOT declared in the profile's capabilities[], following the precedent recorded on commerce.gift-card-activity: classifyCoverage unions capabilities across all of a plugin's entities, and this profile's other entities do carry pricing-plans refs, so declaring it would misclassify the whole plugin as migration-planned via api instead of pending. It stays visible through the profile's content-access-fidelity-caveat and content-access-gating-has-no-plan-field pitfalls."
    },
    {
      "capability": "content.form-notification-templates",
      "reason": "Every WordPress form plugin stores owner-notification and auto-reply email templates next to the field list (CF7 properties.mail / mail_2 with recipient/sender/subject/body/additional_headers in mail-tag syntax; WPForms settings.notifications). Wix Forms' Create Form has no equivalent input — submitSettings only carries submitSuccessAction (NO_ACTION/THANK_YOU_MESSAGE/REDIRECT/POPUP). Owners who migrate silently stop receiving their enquiry emails.",
      "searched": "dev.wix.com api-reference menu walk 2026-08-16: api-reference/crm/forms.md (all 8 surfaces — no notification/email surface anywhere in the tree); form-schemas/form-object.md and create-form.md (no mail/notification field); business-solutions does NOT contain Forms at all; api-reference.md root searched for 'automation'/'notification' -> business-management/automations and business-management/notifications. business-management/automations/automations/automations-v2/create-automation.md: POST https://www.wixapis.com/automations-service/v2/automations, scope SCOPE.CRM.SETUP-AUTOMATIONS, and its own worked example uses triggerKey 'wix_form_app-form_submitted' with an APP_DEFINED send-email action (actionKey 'send-email', appId 0217a814-bf20-4c08-9da9-e14545da7e2f, inputMapping contactId + messageId). Synonyms tried: notification template, triggered email, autoresponder, form notification, automation.",
      "suspected": "target-exists",
      "plannedTarget": "automations/automation — a NEW domain (none exists today), via Create Automation bound to triggerKey wix_form_app-form_submitted with a send-email action. Caveat for the human: the send-email action references a pre-existing messageId (a Triggered Email template), so recreating a CF7 mail body verbatim may need a second surface. This is a new-domain decision, not just a new entity.",
      "note": "Authored 2026-08-16 with the forms vertical (contact-form-7 + wpforms-lite profiles, forms domain)."
    },
    {
      "capability": "commerce.form-payments",
      "reason": "WPForms Lite 2.0.0.4 ships real payment storage — src/Db/Payments/Payment.php and Meta.php create wp_wpforms_payments / wp_wpforms_payment_meta for Stripe, Square and PayPal Commerce form payments (VERIFIED IN SOURCE 2026-08-16). These are money records, not form answers, they have no REST surface in either tier, and Wix's Form Submissions object exposes orderDetails only as read-only fields tied to a Wix Payments checkout. Deliberately left out of the wpforms-lite profile rather than folded into content.form-submissions.",
      "searched": "api-reference/crm/forms/form-submissions/submission-object.md (orderDetails: orderId/number/currency/itemSubtotal/checkoutId, ALL read-only, 'only applicable when submitting a form in the Wix Payments app'); form-submissions/create-submission.md (orderDetails accepted only as a container of read-only fields); about-submission-values.md PAYMENT section (productId must reference a product declared in the field's paymentOptions.validation.products, i.e. a live purchase, not a historical record). Not yet searched: the ecom/orders and Wix Payments trees for a standalone historical-payment write path — that is the next step for whoever picks this up.",
      "suspected": "no-target",
      "plannedTarget": null,
      "note": "Authored 2026-08-16 with the forms vertical. The recorded search is deliberately incomplete (ecom/orders + Wix Payments trees unsearched) — finish it before any human signs a verdict."
    },
    {
      "capability": "commerce.service-availability-rules",
      "reason": "Per-service daily window, holidays, slot table and booking horizon (mwb_mbfw_daily_calendar_start_time/_end_time, mwb_mbfw_choose_holiday, wps_mbfw_time_slots, wps_mbfw_set_availability_upto). bookings/service carries only session durations, so a migrated service has no working hours and is effectively unbookable until an owner reconfigures.",
      "searched": "Menu walk of dev.wix.com api-reference/business-solutions/bookings and business-management/calendar, 2026-08-16 (.md forms). Terms: availability, business hours, working hours, schedule, time slots, time frames.",
      "suspected": "target-exists",
      "plannedTarget": "bookings/<new entity> on Schedules V3 (+ Schedule Time Frames V3, Availability Time Slots Config SPI)",
      "note": "Authored 2026-08-16 with the bookings vertical (mwb-bookings-for-woocommerce profile + new bookings domain); tracked by a `gap` verdict in domains/bookings/docs-survey.json. Deliberately NOT declared in the profile's capabilities[] — classifyCoverage unions capabilities across all of a plugin's entities, so a declared-but-unplaced capability on a profile whose other entities carry refs would misclassify as migration-planned (the pw-woocommerce-gift-cards precedent)."
    },
    {
      "capability": "commerce.service-sessions",
      "reason": "Create Booking requires bookedEntity.slot.eventId for CLASS bookings, so any source with class or course schedules must create sessions before bookings. WPS Bookings has no session concept, so nothing maps from THIS source — the capability is recorded because the next booking source will need it.",
      "searched": "Menu walk of dev.wix.com api-reference/business-solutions/bookings and business-management/calendar, 2026-08-16 (.md forms). Terms: session, class session, calendar event, recurring event.",
      "suspected": "target-exists",
      "plannedTarget": "bookings/<new entity> on Events V3 (Create Event / Bulk Create Event, recurrencePattern MASTER/INSTANCE)",
      "note": "Authored 2026-08-16 with the bookings vertical (mwb-bookings-for-woocommerce profile + new bookings domain); tracked by a `gap` verdict in domains/bookings/docs-survey.json. Deliberately NOT declared in the profile's capabilities[] — classifyCoverage unions capabilities across all of a plugin's entities, so a declared-but-unplaced capability on a profile whose other entities carry refs would misclassify as migration-planned (the pw-woocommerce-gift-cards precedent)."
    },
    {
      "capability": "commerce.booking-policies",
      "reason": "mwb_mbfw_cancellation_allowed, mwb_bfwp_order_statuses_to_cancel and mwb_mbfw_minimum_no_days_booking are per-service cancellation and advance-notice rules with a real Wix home. Only mwb_mbfw_admin_confirmation has a target today (service.onlineBooking.requireManualApproval); the rest silently vanish.",
      "searched": "Menu walk of dev.wix.com api-reference/business-solutions/bookings and business-management/calendar, 2026-08-16 (.md forms). Terms: cancellation policy, booking window, advance notice, reschedule policy.",
      "suspected": "target-exists",
      "plannedTarget": "bookings/<new entity> on Booking Policies (full CRUD)",
      "note": "Authored 2026-08-16 with the bookings vertical (mwb-bookings-for-woocommerce profile + new bookings domain); tracked by a `gap` verdict in domains/bookings/docs-survey.json. Deliberately NOT declared in the profile's capabilities[] — classifyCoverage unions capabilities across all of a plugin's entities, so a declared-but-unplaced capability on a profile whose other entities carry refs would misclassify as migration-planned (the pw-woocommerce-gift-cards precedent)."
    },
    {
      "capability": "commerce.service-providers",
      "reason": "Every APPOINTMENT service requires a staffMemberIds resource GUID, so a provider must exist before ANY service import — this is a hard prerequisite, not an optional fidelity item. WPS Bookings does not model providers, but sources that do (Amelia, Bookly, BookingPress) map directly.",
      "searched": "Menu walk of dev.wix.com api-reference/business-solutions/bookings and business-management/calendar, 2026-08-16 (.md forms). Terms: staff, provider, resource, employee, room, equipment.",
      "suspected": "target-exists",
      "plannedTarget": "bookings/<new entity> on Staff Members + Resources V2",
      "note": "Authored 2026-08-16 with the bookings vertical (mwb-bookings-for-woocommerce profile + new bookings domain); tracked by a `gap` verdict in domains/bookings/docs-survey.json. Deliberately NOT declared in the profile's capabilities[] — classifyCoverage unions capabilities across all of a plugin's entities, so a declared-but-unplaced capability on a profile whose other entities carry refs would misclassify as migration-planned (the pw-woocommerce-gift-cards precedent)."
    },
    {
      "capability": "commerce.bookable-service-categories",
      "reason": "A Wix service without category.id is invisible on the live site (documented on Create Service), so this is a correctness prerequisite rather than a nicety. Source product_cat terms map directly. Currently only a setupRequirement note on bookings/service.",
      "searched": "Menu walk of dev.wix.com api-reference/business-solutions/bookings and business-management/calendar, 2026-08-16 (.md forms). Terms: service category, catalog category.",
      "suspected": "target-exists",
      "plannedTarget": "bookings/<new entity> on Categories V2",
      "note": "Authored 2026-08-16 with the bookings vertical (mwb-bookings-for-woocommerce profile + new bookings domain); tracked by a `gap` verdict in domains/bookings/docs-survey.json. Deliberately NOT declared in the profile's capabilities[] — classifyCoverage unions capabilities across all of a plugin's entities, so a declared-but-unplaced capability on a profile whose other entities carry refs would misclassify as migration-planned (the pw-woocommerce-gift-cards precedent)."
    },
    {
      "capability": "commerce.bookable-service-variants",
      "reason": "Per-person and per-duration pricing (mwb_mbfw_is_booking_unit_cost_per_people, _is_booking_base_cost_per_people, min/max people) is a real source capability currently ledgered as fidelity loss; Wix has a matching construct.",
      "searched": "Menu walk of dev.wix.com api-reference/business-solutions/bookings and business-management/calendar, 2026-08-16 (.md forms). Terms: service variant, service option, price by duration, price per person.",
      "suspected": "target-exists",
      "plannedTarget": "bookings/<new entity> on Service Options And Variants",
      "note": "Authored 2026-08-16 with the bookings vertical (mwb-bookings-for-woocommerce profile + new bookings domain); tracked by a `gap` verdict in domains/bookings/docs-survey.json. Deliberately NOT declared in the profile's capabilities[] — classifyCoverage unions capabilities across all of a plugin's entities, so a declared-but-unplaced capability on a profile whose other entities carry refs would misclassify as migration-planned (the pw-woocommerce-gift-cards precedent)."
    },
    {
      "capability": "commerce.appointment-attendance",
      "reason": "Check-in and no-show state per session. WPS Bookings 3.12.0 has none (only _item_cancelled), so nothing maps from this source, but the write path is real and any booking source with check-in lands here.",
      "searched": "Menu walk of dev.wix.com api-reference/business-solutions/bookings and business-management/calendar, 2026-08-16 (.md forms). Terms: attendance, check-in, no-show.",
      "suspected": "target-exists",
      "plannedTarget": "bookings/<new entity> on Attendance (Set / Bulk Set Attendance)",
      "note": "Authored 2026-08-16 with the bookings vertical (mwb-bookings-for-woocommerce profile + new bookings domain); tracked by a `gap` verdict in domains/bookings/docs-survey.json. Deliberately NOT declared in the profile's capabilities[] — classifyCoverage unions capabilities across all of a plugin's entities, so a declared-but-unplaced capability on a profile whose other entities carry refs would misclassify as migration-planned (the pw-woocommerce-gift-cards precedent)."
    },
    {
      "capability": "content.url-redirects",
      "reason": "Source-authored redirect maps are durable data needed to preserve inbound links. Wix publicly documents the SEO Redirects API in Developer Preview. The remaining gap is RePlatform integration: source-rule extraction, safe application and verification on the actual destination frontend. Wix-internal slug auto-redirects do not replace a source-to-target migration map. Current import execution records plans only.",
      "searched": "Public SEO Redirects Create Redirect and Bulk Create Redirects references: https://dev.wix.com/docs/api-reference/business-management/seo/redirects/redirect-v1/create-redirect and https://dev.wix.com/docs/api-reference/business-management/seo/redirects/redirect-v1/bulk-create-redirects . These manage URL rules, unlike Headless Redirect Sessions.",
      "suspected": "target-exists",
      "plannedTarget": "SEO Redirects API (Developer Preview); target entity and safe writer still to be authored",
      "note": "Keep this capability pending until application and frontend verification are confirmed by a live acceptance run. Source-rule extraction (lib/wp-redirect-sources.js) and the deterministic plan/apply/verify helper (scripts/url-redirects.js) exist but are not live-verified. Do not classify it as supported from API availability alone. Report outstanding link-preservation work to the operator. The source route classifier excludes /redirection/* REST routes; rules are read from the plugins' tables instead, never treated as absent."
    },
    {
      "capability": "commerce.shipping-free-per-product",
      "reason": "Free shipping for specific products (WooCommerce shipping class + a zone method that is free when every cart item is in the class). Wix delivery options are rated per region; no per-product free-shipping rule is chosen.",
      "searched": "rp-target-wix shipping-build.js classifyMethod and the delivery-profile/shipping-option entities (2026-10-31): rates take order-level conditions only.",
      "suspected": "no-target",
      "note": "Pending, never a verdict; reported only when the site has live data (dataPresence)."
    },
    {
      "capability": "commerce.quantity-limits",
      "reason": "Per-product or per-category minimum/maximum order quantity rules. No Wix Stores product field or eCom validation target chosen yet.",
      "searched": "rp-target-wix stores and ecom domains (2026-10-31): no quantity-limit entity authored.",
      "suspected": "no-target",
      "note": "A custom eCom validation extension may fit; a human decides."
    },
    {
      "capability": "commerce.product-ribbons",
      "reason": "Product badges/labels (e.g. Sale, New) shown on product cards.",
      "searched": "Wix Stores product ribbon (Catalog V3 product `ribbon`), not authored as a target entity (2026-10-31).",
      "suspected": "target-exists",
      "plannedTarget": "stores/product ribbon field — author the ribbon mapping on the product target",
      "note": "Added with the product-data plugin profiles (2026-10-31)."
    }
  ],
  "resolved": [
    {
      "capability": "commerce.free-gift-rules",
      "resolvedOn": "2026-08-31",
      "resolution": "NATIVE TARGET FOUND — ecom/discount-rule, via targetType BUY_X_GET_Y + buyXGetYInfo. Profile routing updated in plugins/free-gifts-for-woocommerce.json.",
      "why": "The pending reason said Wix DiscountRule's QUANTITY_BASED form discounts only the items its own trigger counted, so a different-product gift had no target. QUANTITY_BASED was the wrong axis to read: BOGO lives on `targetType`, whose live enum is [SPECIFIC_ITEMS, BUY_X_GET_Y]. It looked absent because buyXGetYInfo appears nowhere in the published Create Discount Rule schema and the docs' own Buy-X-Get-Y example returns HTTP 500; the shape is only visible in the API spec's component schemas.",
      "note": "This file's own preamble says an agent may never conclude that Wix cannot do something, because two such conclusions (gift cards, events) were already wrong. This was the third — the preamble was right.",
      "stillNotMappable": "A cart COUPON CODE gate. Wix has no coupon trigger, so a coupon-gated gift rule imported `active` gives the gift to every shopper. Import inactive and flag it, or rebuild it as a Wix coupon."
    }
  ]
}