1{2 "schemaVersion": 1,3 "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.",
7 "reason": "Free Gifts for WooCommerce Automatic Gift and Buy X Get Y rules grant a different catalog item when a threshold or quantity trigger is met. Routing these definitions to Automatic Discounts would misconfigure the migration because Wix DiscountRule's documented QUANTITY_BASED form discounts the same items counted by its trigger.",
8 "searched": "rp-target-wix/domains/ecom/entities/discount-rule.json and research/woocommerce-discount-engines-to-wix-automatic-discounts.md, reviewed 2026-08-19: trigger and discount enums contain no confirmed primitive that grants or discounts a different product. stores/coupon applies only to the plugin's separate Coupon Gift mode; Manual Gift is not standing configuration.",
9 "suspected": "no-target",
10 "plannedTarget": null,
11 "note": "This remains pending rather than a requires-development verdict until a named human signs that conclusion or a native target is found."
12 },
13 {
14 "capability": "commerce.gift-card-activity",
15 "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).",
16 "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.",
17 "suspected": "target-exists",
18 "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).",
19 "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."
23 "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.",
24 "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).",
25 "suspected": "target-exists",
26 "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.",
27 "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."
28 },
29 {
30 "capability": "commerce.composite-products",
31 "reason": "WPC Composite Products defines a CUSTOMER-ASSEMBLED kit: a WooCommerce product of type `composite` whose `wooco_components` meta declares component groups (sourced from explicit product lists or whole categories/tags, with min/max quantities and an optional flag), from which the buyer picks at purchase time. The product shell migrates as a plain stores/product; the component structure has no native Wix Stores target — Catalog V3 productType is PHYSICAL | DIGITAL only, with no composed-product entity, no child-product references and no component-group construct. THIS IS DELIBERATELY NOT FILED AS A VERDICT. It is adjacent to the signed commerce.product-bundles entry in requires-development.json (Spec Owner, 2026-08-16), which explicitly names 'Composite Products' in its scope — but that verdict rejected Wix's mix-and-match on the grounds that it is 'a category + automatic-discount pattern for customer-assembled combos' with no fixed-bundle SKU, and customer-assembled combos is precisely the shape a composite has, not the shape a woosb bundle has. Mix-and-match is therefore a nearer (though still configuration-only, non-API) parallel here than it was for bundles. Extending the bundles verdict by inference would re-run the exact failure mode the human-signature rule exists to prevent, so this stays pending for a human to co-sign — either folded into commerce.product-bundles or decided separately.",
32 "searched": "composite product, product kit, configurable product, component group, mix and match, customer-assembled bundle — dev.wix.com 2026-08-16 (WebSearch + WebFetch): catalog-v3/products-v3/product-object.md read in full — `productType` enum is exactly `PHYSICAL, DIGITAL`; nearest structural fields are `options`/`modifiers` (variant- and free-text customizations that never reference another product) and `purchaseEligibility.userCriteria: MEMBERS_ONLY`; no bundled/composed/child-product field anywhere on the object. Also checked dev.wix.com/docs/velo/articles/velo-package-readmes/wix-stores-bundle-products (Velo site-code pattern: plain product + CMS collection, not a write API) and the business-solutions/stores tree. Inherits the support.wix.com mix-and-match evaluation recorded on the commerce.product-bundles entry (2026-08-16).",
33 "suspected": "no-target",
34 "plannedTarget": null,
35 "note": "Authored 2026-08-16 with the wpc-composite-products profile. Parallel case: requires-development.json[commerce.product-bundles] (decidedBy Spec Owner, 2026-08-16). Interim path is the same as bundles — product migrates plain, composition lands in a CMS collection keyed by the product crosswalk — so per the owner-ask policy this earns no standalone owner task. If a human co-signs, the destination is requires-development.json with decidedBy/decidedOn; validation will reject the entry automatically if Catalog V3 ever gains a composed-product primitive."
39 "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.",
40 "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.",
41 "suspected": "no-target",
42 "plannedTarget": null,
43 "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."
47 "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.",
48 "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.",
49 "suspected": "target-exists",
50 "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.",
51 "note": "Authored 2026-08-16 with the forms vertical (contact-form-7 + wpforms-lite profiles, forms domain)."
52 },
53 {
54 "capability": "commerce.form-payments",
55 "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.",
56 "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.",
57 "suspected": "no-target",
58 "plannedTarget": null,
59 "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."
63 "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.",
64 "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.",
65 "suspected": "target-exists",
66 "plannedTarget": "bookings/<new entity> on Schedules V3 (+ Schedule Time Frames V3, Availability Time Slots Config SPI)",
67 "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)."
68 },
69 {
70 "capability": "commerce.service-sessions",
71 "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.",
72 "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.",
75 "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)."
76 },
77 {
78 "capability": "commerce.booking-policies",
79 "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.",
80 "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.",
81 "suspected": "target-exists",
82 "plannedTarget": "bookings/<new entity> on Booking Policies (full CRUD)",
83 "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)."
84 },
85 {
86 "capability": "commerce.service-providers",
87 "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.",
88 "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.",
89 "suspected": "target-exists",
90 "plannedTarget": "bookings/<new entity> on Staff Members + Resources V2",
91 "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)."
95 "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.",
96 "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.",
97 "suspected": "target-exists",
98 "plannedTarget": "bookings/<new entity> on Categories V2",
99 "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)."
103 "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.",
104 "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.",
105 "suspected": "target-exists",
106 "plannedTarget": "bookings/<new entity> on Service Options And Variants",
107 "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)."
111 "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.",
112 "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.",
113 "suspected": "target-exists",
114 "plannedTarget": "bookings/<new entity> on Attendance (Set / Bulk Set Attendance)",
115 "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)."
116 },
117 {
118 "capability": "content.url-redirects",
119 "reason": "A source site's authored 301 redirect map (the `redirection` plugin has been observed live advertising /redirection/v1/redirect + /redirection/v1/group as real collections; Rank Math uses rank_math_redirections custom tables; Yoast Premium also stores redirects) is durable data with a clear business meaning: preserve inbound links and search rankings across the platform switch. Wix exposes no public API to author a redirect rule. Wix DOES auto-redirect an item's old URL to its new one when the slug changes (seoData.settings.preventAutoRedirect, default false), but that covers only Wix-internal renames, not a source-to-target map. Spec 0010 already parks concrete redirect plans in state/url-preservation/redirects.ndjson and explicitly does not apply them, so this entry is the mapping-side twin of that deferral.",
120 "searched": "2026-08-16, all dev.wix.com and .md: llms.txt grep 'redirect|seo|sitemap|robots' -> 3 hits, all SEO tag surfaces, zero redirect API; api-reference.md full 62KB menu, all 11 top-level trees, grep 'redirect' -> ONE hit, business-management/headless/redirects; that page = Redirect Session Object / Create Redirect Session, i.e. auth & checkout redirect SESSIONS for headless clients, NOT URL rules; business-management/site-urls.md = Editor URLs + Published Site URLs, both read-only; business-solutions.md (94KB menu) grep 'redirect|seo|url|sitemap' -> zero hits; llms-full.txt (38MB) synonyms 'url redirect', 'url-redirect', 'urlRedirect', '301', heading-scan '^#{1,3}.*[Rr]edirect' -> only auth/checkout redirect flows and Velo tutorials, no wixapis.com URL-redirect service; business-management/seo/introduction.md + full SEO menu -> three levels (site/pattern/item), no redirect level.",
121 "suspected": "no-target",
122 "plannedTarget": null,
123 "note": "Authored 2026-08-16 with the SEO vertical. NOT a requires-development verdict — that needs a named human. Also not blocked work: the redirect map is at worst Migration planned via CMS, and the redirects.ndjson ledger is already its home. Related classifier note: lib/wp-route-classifier.js excludes /redirection/* as `wp.integration.redirection`, but live those routes are genuine durable collections, so that rule's stated reason is now inaccurate — revisit the rule and this entry together, in one change."