@wix/agent-skills 1.33.0 → 1.34.0

package/skills/wix-replatform/resources/rp-source-wordpress/plugins/mailpoet.json

@@ -0,0 +1,52 @@
+{
+  "schemaVersion": 1,
+  "plugin": "mailpoet",
+  "displayName": "MailPoet",
+  "profileVersion": "2026-08",
+  "sourceOfTruth": "https://kb.mailpoet.com/",
+  "distribution": "wordpress-org",
+  "capabilities": [
+    "crm.email-subscription"
+  ],
+  "detect": {
+    "pluginFileIds": [
+      "mailpoet/mailpoet.php"
+    ],
+    "routes": [
+      "/mailpoet/v1/subscribers"
+    ],
+    "restNamespaces": [
+      "mailpoet/v1"
+    ],
+    "assetPathSlugs": [
+      "mailpoet"
+    ]
+  },
+  "entities": [
+    {
+      "entity": "subscriber",
+      "channel": "plugin-rest",
+      "route": "/mailpoet/v1/subscribers",
+      "recordKeyField": "id",
+      "responseEnvelope": {
+        "itemsPath": "data.items",
+        "countPath": "data.meta.count"
+      },
+      "candidateTargetRefs": [
+        "crm/email-subscription"
+      ],
+      "pitfalls": [
+        {
+          "code": "consent-status-per-record",
+          "severity": "blocker",
+          "summary": "VERIFIED LIVE 2026-08-11: each subscriber carries status (subscribed / unconfirmed / unsubscribed — MailPoet's double opt-in flow) both at the top level and per entry in subscriptions[] (one per list/segment). Only a status of 'subscribed' is consent evidence; writing an unconfirmed or unsubscribed record as a Wix subscribed contact is a consent violation, not a data-quality nuance — see crm/email-subscription's own consent-proof-required pitfall."
+        }
+      ]
+    }
+  ],
+  "quirks": [
+    "The REST route wraps its records as { data: { items: [...], meta: { count, pages } } } instead of a flat array, and advertises no X-WP-Total/X-WP-TotalPages headers — responseEnvelope (itemsPath/countPath) is what makes this readable at all; without it the whole envelope would sample as a single opaque record with recordCount 1.",
+    "VERIFIED LIVE 2026-08-11: the subscriber list is genuinely paginated (page/per_page args), so read it page by page rather than assuming one response holds every subscriber.",
+    "MailPoet exposes /segments, /tags, /newsletters, /forms, /automations, /dynamic-segments, and /custom-fields under the same namespace and the same responseEnvelope shape (all VERIFIED LIVE 2026-08-11) — not profiled here. Each subscriber record already embeds its own segment_id/status pairs (subscriptions[]) and tags[], so a segment/tag NAME lookup is only needed if a migration wants human-readable list/tag names rather than ids; add /segments and /tags as additional entities if that lookup becomes necessary."
+  ]
+}

package/skills/wix-replatform/resources/rp-source-wordpress/plugins/membership-for-woocommerce.json

@@ -0,0 +1,161 @@
+{
+  "schemaVersion": 1,
+  "plugin": "membership-for-woocommerce",
+  "displayName": "Membership For WooCommerce",
+  "profileVersion": "2026-08",
+  "sourceOfTruth": "https://wordpress.org/plugins/membership-for-woocommerce/",
+  "distribution": "wordpress-org",
+  "capabilities": [
+    "commerce.subscription-plans",
+    "commerce.subscription-contracts"
+  ],
+  "detect": {
+    "pluginFileIds": [
+      "membership-for-woocommerce/membership-for-woocommerce"
+    ],
+    "routes": [
+      "/wps-mfw/get-membership-offers",
+      "/wps-mfw/get-user-membership"
+    ],
+    "restNamespaces": [
+      "wps-mfw"
+    ],
+    "recordProperties": [
+      "wps_membership_plan_with_product",
+      "_wps_plan_id"
+    ],
+    "assetPathSlugs": [
+      "membership-for-woocommerce"
+    ]
+  },
+  "credentials": [
+    {
+      "key": "wps_membership_api_consumer_secret_keys",
+      "description": "Plugin-specific API secret for the wps-mfw namespace, passed as a `consumer_secret` request parameter. Generated in the plugin's own settings and stored in the wps_membership_api_consumer_secret_keys option; the API must ALSO be switched on there (wps_membership_enable_api_settings option = 'on') or the routes are never registered at all. The admin Application Password does NOT authorize these routes — the permission callback hash_equals()-compares consumer_secret and nothing else, and returns false outright when no secret has been generated [DOCUMENTED: plugin source 3.1.2, package/rest-api/class-membership-for-woocommerce-rest-api.php wps_mfw_default_permission_check, read 2026-08-16]. Collecting this credential is nevertheless LOW VALUE for migration — see the post-only-plugin-api quirk: every route is POST, so a read-only discovery pass cannot use them regardless."
+    }
+  ],
+  "entities": [
+    {
+      "entity": "membership-plan",
+      "channel": "export-file",
+      "candidateTargetRefs": ["pricing-plans/plan"],
+      "pitfalls": [
+        {
+          "code": "not-rest-readable-export-required",
+          "severity": "blocker",
+          "summary": "Membership plans are posts of the custom type `wps_cpt_membership`, registered WITHOUT show_in_rest [VERIFIED IN PLUGIN SOURCE v3.1.2, admin/class-membership-for-woocommerce-admin.php register_post_type('wps_cpt_membership', ...) — the args set public/publicly_queryable/show_ui but never show_in_rest, so it defaults to false, 2026-08-16]. [VERIFIED LIVE 2026-08-16] the authed /wp/v2/types lists neither wps_cpt_membership nor wps_cpt_members, and GET /wp-json/wp/v2/wps_cpt_membership returns 404. With the plugin's own namespace also absent (see quirks), there is NO REST read for plan records: the channel is a user-supplied WXR export, which does carry the CPT and its postmeta because register_post_type leaves can_export at its true default. Treat a missing export as Blocked — recoverable (kind: user-file), not as an empty plan set."
+        },
+        {
+          "code": "plan-field-map-to-pricing-plans",
+          "severity": "warning",
+          "summary": "Plan settings live in unregistered postmeta on the plan post [DOCUMENTED: plugin source 3.1.2, admin/class-membership-for-woocommerce-admin.php get_plans_default_value(), read 2026-08-16]. The fields that map onto pricing-plans/plan: post_title → plan.name (Wix caps it at 50 chars); post_content / wps_membership_plan_info → plan.description; wps_membership_plan_price → pricingVariants[0].pricingStrategies[0].flatRate.amount; wps_membership_plan_name_access_type ('lifetime' | 'limited') → billingTerms.endType (UNTIL_CANCELLED for lifetime; CYCLES_COMPLETED for limited); wps_membership_plan_duration + wps_membership_plan_duration_type ('days'|'weeks'|'months'|'years') → the billingCycle period/count pair, subject to that entity's billing-cycle-minimum-7-days pitfall; wps_sfw_subscription_free_trial_number + wps_sfw_subscription_free_trial_interval → freeTrialDays (convert to days); wps_sfw_subscription_initial_signup_price → pricingVariants[].fees[] FIXED_AMOUNT / FIRST_PAYMENT. NOTE the plugin reuses its sibling's wps_sfw_* prefix for the trial/signup keys — those are membership plan meta here, not Subscriptions-For-WooCommerce product meta."
+        },
+        {
+          "code": "content-access-gating-has-no-plan-field",
+          "severity": "warning",
+          "summary": "The largest half of a WooCommerce membership plan does NOT fit pricing-plans/plan at all: the access rules. A 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), plus member-benefit rules — wps_membership_plan_offer_price_type + wps_memebership_plan_discount_price (member discount, note the plugin's own 'memebership' typo in those two keys), 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 'immediate_type', wps_membership_plan_time_duration/_type) [DOCUMENTED: plugin source 3.1.2 get_plans_default_value(), read 2026-08-16]. A Wix Pricing Plan is a paid offer; what it unlocks is configured on the page/blog/group side in the Editor and dashboard, not carried on the plan object. Recorded as a separate pending capability rather than declared in this profile's capabilities[] — see capabilities-pending-decision.json (commerce.membership-content-access) and the deliberately-undeclared-capability quirk."
+        },
+        {
+          "code": "deduplicate-and-do-not-import-the-placeholder",
+          "severity": "info",
+          "summary": "Import one Wix plan per source plan post, and use pricing-plans/plan's idempotencyKey (GUID, derived deterministically from the source plan post id) so a retried import does not duplicate. Separately: skip the plugin's auto-generated 'Membership Product' — see the auto-created-placeholder-product quirk — it is scaffolding, not catalog."
+        }
+      ]
+    },
+    {
+      "entity": "member-enrollment",
+      "channel": "export-file",
+      "candidateTargetRefs": ["pricing-plans/plan-order"],
+      "relations": [
+        {
+          "relatedEntity": "membership-plan",
+          "via": "plan_obj"
+        }
+      ],
+      "pitfalls": [
+        {
+          "code": "not-rest-readable-export-required",
+          "severity": "blocker",
+          "summary": "Enrollments are posts of the custom type `wps_cpt_members`, registered without show_in_rest exactly as the plan type is [VERIFIED IN PLUGIN SOURCE v3.1.2, admin/class-membership-for-woocommerce-admin.php; VERIFIED LIVE 2026-08-16: absent from the authed /wp/v2/types, GET /wp-json/wp/v2/wps_cpt_members returns 404]. The full enrollment set is readable only from a user-supplied WXR export. A partial, REST-only reconstruction IS possible for purchase-created enrollments — see the membership-purchase-order-linkage entity — but it silently omits manually assigned members, so it is a fallback with a known hole, never a substitute."
+        },
+        {
+          "code": "enrollment-record-shape",
+          "severity": "warning",
+          "summary": "The record is thin and mostly denormalized into meta [VERIFIED IN PLUGIN SOURCE v3.1.2, includes/class-membership-for-woocommerce-global-functions.php create_membership_for_customer() and wps_msfw_assigned_membership_by_user_id(), plus admin/class-membership-for-woocommerce-admin.php manual-add handler, 2026-08-16]: post_author is the WP user id (this, not a meta field, is the reliable member link on purchase-created records), post_title is a display user name, and the meta carries member_status ('pending' | 'complete' | 'hold' | 'cancelled', derived from the WooCommerce order status), member_expiry, member_order_id (the source WooCommerce order), member_actions, billing_details (an array of membership_billing_* fields), wps_member_user (the user id, written on the MANUAL assignment path only), and plan_obj. The reverse link also exists as user meta mfw_membership_id (an array of member post ids) on the WP user — also not REST-exposed."
+        },
+        {
+          "code": "plan-obj-is-a-frozen-snapshot",
+          "severity": "warning",
+          "summary": "`plan_obj` is not a plan id: it is a full array merge of the plan post row (get_post ARRAY_A) with every one of the plan's postmeta values, snapshotted at enrollment time [VERIFIED IN PLUGIN SOURCE v3.1.2, same functions as above, 2026-08-16]. Two consequences. (1) The plan id must be recovered from plan_obj['ID'] and crosswalked to the Wix plan — do not create a Wix plan per enrollment. (2) Long-lived members can hold TERMS THAT DIFFER from the plan's current terms; if the snapshot's price/duration disagrees with the live plan post, that divergence is real historical fact, and grandfathered terms cannot be expressed on a Wix plan-order (which inherits the plan's terms). Ledger the divergence rather than silently re-pricing the member."
+        },
+        {
+          "code": "status-and-lifecycle-mapping",
+          "severity": "warning",
+          "summary": "Per pricing-plans/plan-order: only ACTIVE-equivalent enrollments recreate natively via POST /pricing-plans/v2/checkout/orders/offline. member_status 'complete' → create the offline order with paid:true; 'pending'/'hold' → paid:false or hold for review; 'cancelled', and any record whose member_expiry is in the past, cannot be recreated in that state (status/endDate/cancellation are all read-only at create) and belong in CMS-only history. memberId is a hard dependency — the Wix members import must run first (400 MEMBER_DOESNT_EXIST) — and it is resolved from post_author via the member crosswalk, not from post_title."
+        },
+        {
+          "code": "content-access-fidelity-caveat",
+          "severity": "warning",
+          "summary": "THE HEADLINE FIDELITY CAVEAT for this plugin. A WooCommerce membership is an ACCESS-CONTROL grant: the plan's target ids/categories/tags gate specific products, posts and pages and apply member-only discounts and free shipping, enforced per request. A Wix Pricing Plans order is a BENEFIT ENTITLEMENT: it records that a member holds a paid plan, and what that unlocks is configured separately on the page/blog/group being protected. Recreating enrollments as plan-orders therefore preserves WHO is entitled and to WHICH plan, and preserves nothing about WHAT that entitlement opens until the gating is reconfigured on the Wix side. Migrating enrollments without also reconfiguring gating leaves members holding plans that unlock nothing — surface this at the review gate, do not let it read as a clean subscription migration."
+        }
+      ]
+    },
+    {
+      "entity": "plan-grant-product-linkage",
+      "channel": "core-meta",
+      "embeddedIn": ["/wc/v3/products"],
+      "propertyPath": "wps_membership_plan_with_product",
+      "candidateTargetRefs": [],
+      "pitfalls": [
+        {
+          "code": "no-wix-target-decided",
+          "severity": "warning",
+          "summary": "A WooCommerce product can be configured to grant a membership plan when purchased; the chosen plan post id is stored in unregistered product meta `wps_membership_plan_with_product` [VERIFIED IN PLUGIN SOURCE v3.1.2, admin/class-membership-for-woocommerce-admin.php product-tab save handler, 2026-08-16]. Wix has no equivalent: a Pricing Plan is bought as a plan, and buying a Stores product does not confer one. There is no automation-writable rule connecting the two, so the linkage itself is unplaceable — the product migrates normally, the plan migrates normally, and the grant relationship is reportable loss or a CMS note. Also folded into the commerce.membership-content-access pending entry."
+        },
+        {
+          "code": "the-only-rest-visible-plan-signal",
+          "severity": "info",
+          "summary": "Worth reading even though it has no target: this key is the ONLY REST-visible evidence of the plugin's plan data. When the user supplies no WXR export, scanning /wc/v3/products meta_data for wps_membership_plan_with_product yields the set of plan post ids that are purchasable, which is enough to report 'N membership plans exist and cannot be read' concretely instead of reporting nothing. It is a lower bound only — plans sold through the plugin's own plans page, and plans assigned manually, leave no product meta at all."
+        }
+      ]
+    },
+    {
+      "entity": "membership-purchase-order-linkage",
+      "channel": "core-meta",
+      "embeddedIn": ["/wc/v3/orders"],
+      "propertyPath": "_wps_plan_id",
+      "candidateTargetRefs": ["pricing-plans/plan-order"],
+      "pitfalls": [
+        {
+          "code": "partial-rest-fallback-for-enrollments",
+          "severity": "warning",
+          "summary": "When a membership is purchased, the plugin writes `_wps_plan_id` (the plan post id) and `_member_id` (the wps_cpt_members post id) onto the FIRST line item of the order [VERIFIED IN PLUGIN SOURCE v3.1.2, public/class-membership-for-woocommerce-public.php wps_msfw_membership_update_meta_data(), wc_add_order_item_meta on $keys[0], 2026-08-16]. Both keys ride in wc/v3/orders line_items[].meta_data, which makes this the one REST-readable path to enrollment facts: order.customer_id gives the member, _wps_plan_id gives the plan, order.date_created gives the start date, and order.status approximates member_status. That is the full input set pricing-plans/plan-order needs (planId + memberId + startDate + paid). Use it as the fallback when no WXR export is supplied."
+        },
+        {
+          "code": "fallback-omits-manual-and-lifecycle-data",
+          "severity": "warning",
+          "summary": "Two holes that make this a fallback, not a source of truth. (1) Manually assigned memberships — created from the admin Members screen or by wps_msfw_assigned_membership_by_user_id() — never touch an order, so they are invisible here entirely. (2) The order records the PURCHASE, not the current state: member_expiry, later status changes (admin cancellation, expiry sweeps, pause) and renewals live only on the wps_cpt_members record, so an order-derived enrollment can be stale — importing an expired membership as ACTIVE is the concrete failure mode. Cross-check member_expiry from the export whenever one exists; when it does not, ledger every order-derived enrollment as unverified state."
+        },
+        {
+          "code": "first-line-item-only",
+          "severity": "info",
+          "summary": "The meta lands on the first line item of the order regardless of which line actually was the membership product [VERIFIED IN PLUGIN SOURCE v3.1.2: `$keys = array_keys( $items ); wc_add_order_item_meta( $keys[0], ... )`]. Do not infer the membership product from the line item carrying the key, and do not expect the key on every line of a mixed order — read it as an order-level fact that happens to be stored on one line."
+        },
+        {
+          "code": "sampling-may-miss-linkage",
+          "severity": "info",
+          "summary": "Present only on orders that bought a membership. [VERIFIED LIVE 2026-08-16] orders carry _wps_plan_id or _member_id only when a membership was bought, so absence here is genuinely 'no membership sales', not surface drift. The channel mechanism itself is live-proven: custom underscore-prefixed line-item meta (`_reduced_stock`) does appear in wc/v3/orders line_items[].meta_data [VERIFIED LIVE 2026-08-16]."
+        }
+      ]
+    }
+  ],
+  "quirks": [
+    "Plugin file id is `membership-for-woocommerce/membership-for-woocommerce` [VERIFIED LIVE 2026-08-16: plugin active, version 3.1.2, textdomain membership-for-woocommerce, vendor WP Swings]. Asset path detection works with no credentials: GET /wp-content/plugins/membership-for-woocommerce/public/css/membership-for-woocommerce-public.css returned 200 [VERIFIED LIVE 2026-08-16] while the directory's readme.txt returned 403, so probe a real asset, not the readme.",
+    "STORAGE MODEL — everything durable is core WordPress posts + UNREGISTERED postmeta, and almost none of it is REST-visible. (a) Plans: CPT wps_cpt_membership, no show_in_rest. (b) Enrollments: CPT wps_cpt_members, no show_in_rest, member linked by post_author. (c) Plan and member settings: plain postmeta, with zero register_post_meta / register_meta / show_in_rest calls anywhere in the plugin [VERIFIED IN PLUGIN SOURCE v3.1.2, grep across the package, 2026-08-16 — the only register_meta_box_cb hits are admin metaboxes, not REST registration]. (d) The two REST-visible crumbs are WooCommerce-side: product meta wps_membership_plan_with_product and order-line-item meta _wps_plan_id / _member_id, both surfaced by WooCommerce's own meta_data arrays rather than by anything this plugin registers. There are no custom database tables (no CREATE TABLE in the source), so a WXR export is a complete read — which is what makes export-file the right channel here rather than db-only.",
+    "THE PLUGIN'S OWN REST API IS OFF BY DEFAULT AND POST-ONLY. It registers namespace `wps-mfw` (no version segment — the routes are /wps-mfw/mfw-dummy-data/, /wps-mfw/get-membership-offers/, /wps-mfw/get-user-membership) but only when the option wps_membership_enable_api_settings === 'on' [DOCUMENTED: source 3.1.2, package/rest-api/class-membership-for-woocommerce-rest-api.php wps_mfw_add_endpoint(), read 2026-08-16]. [VERIFIED LIVE 2026-08-16] with the toggle off, `wps-mfw` is absent from the namespaces the REST index advertises and all three routes GET 404 — so restNamespaces/routes here are real but frequently-absent detection signals, and their absence must NOT be read as the plugin being missing. Even when enabled they are unusable by this system's read-only discovery: every route is registered as WP_REST_Server::CREATABLE (POST), so there is no GET form to sample. Their payloads are thin projections anyway — get-membership-offers returns {plan_name, plan_type, plan_price, plan_duration} per plan and get-user-membership returns one user's plan summary [DOCUMENTED: package/rest-api/version1/class-membership-for-woocommerce-api-process.php, read 2026-08-16] — carrying none of the access rules, expiry, or billing state a migration needs.",
+    "AUTO-CREATED PLACEHOLDER PRODUCT — the activator inserts a WooCommerce product named 'Membership Product' (slug membership-product, simple, virtual, price 0, description 'Auto generated product for membership please do not delete or update.') and stores its id in the wps_membership_default_product option; it is the cart vehicle for plan purchases, not catalog [VERIFIED IN PLUGIN SOURCE v3.1.2, includes/class-membership-for-woocommerce-activator.php]. [VERIFIED LIVE 2026-08-16] it is created with status publish and virtual true — i.e. it is publicly listed, not private, so a naive product migration WILL carry a junk product across. Exclude it by slug/option id at mapping time and report the exclusion rather than dropping it silently.",
+    "DELIBERATELY UNDECLARED CAPABILITY — the content-access half of this plugin (plan-gated products/posts/pages, member-only discounts, member free shipping) is proposed as `commerce.membership-content-access` in capabilities-pending-decision.json and is intentionally NOT listed in this profile's capabilities[]. Reason, per the precedent recorded on the commerce.gift-card-activity pending entry: classifyCoverage unions a plugin's capabilities across ALL its entities, so an unplaced capability declared on a profile whose other entities do carry target refs would misclassify as migration-planned via api instead of pending. The pitfalls above are where that gap stays visible.",
+    "VENDOR FAMILY OVERLAP — WP Swings ships this alongside Subscriptions For WooCommerce, and the two share code lineage: this plugin's meta helper wps_membership_get_meta_data() branches on OrderUtil::get_order_type() and has an explicit `wps_subscriptions` branch constructing a WPS_Subscription object, and its plan field registry reuses the wps_sfw_* prefix for trial/signup keys [VERIFIED IN PLUGIN SOURCE v3.1.2, membership-for-woocommerce.php lines 353-400 and admin get_plans_default_value(), 2026-08-16]. Both plugins can be active together on one site. Consequence for detection and for reading: a wps_sfw_* key found on a MEMBERSHIP PLAN post belongs to this plugin, while the same-named key on a PRODUCT belongs to subscriptions-for-woocommerce — do not attribute by prefix alone. This plugin registers no custom order type of its own (no wc_register_order_type call anywhere in the source), so `wps_subscriptions` records seen on a site come from the sibling plugin.",
+    "[NEEDS-VERIFICATION] every payload-shape claim above rests on the published 3.1.2 source, not on a live record: a store with the plugin active but no membership plans, no member records and no membership sales was checked (no product carries wps_membership_plan_with_product, no order carries _wps_plan_id / _member_id, both CPTs 404 over REST) [VERIFIED LIVE 2026-08-16]. Re-verify against a store with real membership data — in particular the plan_obj snapshot shape and the member_expiry format — before promoting this profile's field lists to a contract."
+  ]
+}

package/skills/wix-replatform/resources/rp-source-wordpress/plugins/mwb-bookings-for-woocommerce.json

@@ -0,0 +1,180 @@
+{
+  "schemaVersion": 1,
+  "plugin": "mwb-bookings-for-woocommerce",
+  "displayName": "WPS Bookings for WooCommerce",
+  "profileVersion": "2026-08",
+  "sourceOfTruth": "https://wordpress.org/plugins/mwb-bookings-for-woocommerce/",
+  "distribution": "wordpress-org",
+  "capabilities": [
+    "commerce.bookable-services",
+    "commerce.bookings",
+    "commerce.bookable-service-add-ons"
+  ],
+  "detect": {
+    "pluginFileIds": [
+      "mwb-bookings-for-woocommerce/mwb-bookings-for-woocommerce"
+    ],
+    "routes": [
+      "/wps-bfw/v1/bookings",
+      "/wp/v2/mwb_booking_cost",
+      "/wp/v2/mwb_booking_service"
+    ],
+    "restNamespaces": [
+      "wps-bfw/v1"
+    ],
+    "restBases": [
+      "mwb_booking_cost",
+      "mwb_booking_service"
+    ],
+    "recordProperties": [
+      "wps_mbfw_booking_type",
+      "mwb_mbfw_booking_criteria",
+      "mwb_order_type",
+      "_wps_single_cal_date_time_from",
+      "_mwb_bfwp_date_time_from"
+    ],
+    "assetPathSlugs": [
+      "mwb-bookings-for-woocommerce"
+    ]
+  },
+  "excludeRoutes": [
+    {
+      "route": "/wps-bfw/v1/bookings",
+      "reason": "[VERIFIED LIVE 2026-08-16] The plugin's only REST route is a MY-ACCOUNT projection, not a collection: its callback is wc_get_orders(['customer' => get_current_user_id(), 'limit' => -1]) and its permission_callback is just is_user_logged_in(), so an authed admin gets the ADMIN'S OWN bookings and nobody else's ([DOCUMENTED] source 3.12.0, package/rest-api/class-mwb-bookings-for-woocommerce-rest-api.php, read 2026-08-16). It also returns display strings rather than data - total is HTML-decoded wc_price() output, booking is a pre-formatted 'from To to' string, plus image/calendar_url/view_order_url. Reading it during discovery would produce a confidently wrong record count. It returned 200 with [] to the admin app password and 401 rest_forbidden unauthenticated."
+    }
+  ],
+  "entities": [
+    {
+      "entity": "booking-service-product",
+      "channel": "core-meta",
+      "embeddedIn": [
+        "/wc/v3/products"
+      ],
+      "propertyPath": "wps_mbfw_booking_type",
+      "candidateTargetRefs": [
+        "bookings/service"
+      ],
+      "pitfalls": [
+        {
+          "code": "product-type-is-the-real-discriminator",
+          "severity": "warning",
+          "summary": "A bookable service is a WooCommerce product of type mwb_booking (class WC_Product_Mwb_Booking, get_type() returns 'mwb_booking' - [DOCUMENTED] source 3.12.0 includes/class-wc-product-mwb-booking.php). Two live-verified traps. (1) [VERIFIED LIVE 2026-08-16] mwb_booking is NOT in the /wc/v3/products `type` enum advertised by the REST index (the enum is simple, grouped, external, variable, woosb, pw-gift-card) - the enum comes from wc_get_product_types(), fed by the product_type_selector filter, which the plugin registers only in its admin hooks (the whole admin class is behind is_admin(), so a REST request never sees it). ?type=mwb_booking is therefore rejected; filter client-side on the payload's type field instead. (2) The woocommerce_product_class filter that makes get_type() return 'mwb_booking' is registered only when the plugin's own master switch is on (option mwb_mbfw_is_plugin_enable === 'yes'); with it off, a booking product resolves to WC_Product_Simple and reports type 'simple' while its meta keys stay put - which is exactly why this entity's channel probe is a meta key, not the type."
+        },
+        {
+          "code": "settings-are-unregistered-postmeta",
+          "severity": "warning",
+          "summary": "STORAGE MODEL: every booking setting is unregistered post meta. [DOCUMENTED] source 3.12.0 calls register_meta/register_post_meta ZERO times (grep 2026-08-16; the only show_in_rest occurrences are the two taxonomies and the admin-only wps_global_booking CPT). The keys are REST-visible only because WooCommerce surfaces non-internal post meta in /wc/v3/products meta_data[]. The save handler (admin/class-mwb-bookings-for-woocommerce-admin.php mbfw_save_custom_product_meta_boxes_data, lines ~1300-1390) writes the whole set on every save, so expect all of them: wps_mbfw_booking_type (dual_cal|single_cal), mwb_mbfw_booking_criteria (customer_selected_unit|fixed_unit), mwb_mbfw_booking_count, mwb_mbfw_booking_unit, mwb_mbfw_booking_unit_cost, mwb_mbfw_booking_base_cost, mwb_mbfw_is_booking_unit_cost_per_people, mwb_mbfw_is_booking_base_cost_per_people, mwb_mbfw_is_people_option, mwb_mbfw_minimum_people_per_booking, mwb_mbfw_maximum_people_per_booking, mwb_mbfw_max_bookings, mwb_mbfw_maximum_booking_per_unit, mwb_mbfw_minimum_no_days_booking, mwb_mbfw_enable_calendar, mwb_mbfw_enable_time_picker, mwb_mbfw_show_date_with_time, mwb_mbfw_booking_time_fromat (sic), mwb_mbfw_admin_confirmation, mwb_mbfw_cancellation_allowed, mwb_bfwp_order_statuses_to_cancel, mwb_mbfw_daily_calendar_start_time, mwb_mbfw_daily_calendar_end_time, mwb_mbfw_choose_holiday, wps_mbfw_set_availability, wps_mbfw_set_availability_upto, wps_mbfw_time_slots, wps_mbfw_night_slots_enabled, mwb_mbfw_is_add_extra_services, mwb_mbfw_booking_hide_or_diable_slot (sic). The venue lives in mwb_mbfw_booking_location. Note the plugin also mirrors its unit cost into WooCommerce's internal _price, which WooCommerce excludes from meta_data[] - read the price from the product's own price field. [NEEDS-VERIFICATION] none of these keys has been seen in a live payload: no scanned product (2026-08-16) was a booking product, so every key above rests on the published 3.12.0 source."
+        },
+        {
+          "code": "second-booking-product-flavour",
+          "severity": "warning",
+          "summary": "[DOCUMENTED source 3.12.0] There is a SECOND kind of bookable product that is not of type mwb_booking: the 'Global Booking' calendar-form flow marks an ordinary product with post meta _is_calendar_booking_product = 'yes' (public/class-mwb-bookings-for-woocommerce-public.php lines 1604-1625) and books it through a wps_global_booking form. A scan that keys only on type === 'mwb_booking' misses these. Their appointments are also stored differently - see the booking-appointment entity's dual-key-shape pitfall."
+        },
+        {
+          "code": "availability-rules-have-no-authored-target",
+          "severity": "info",
+          "summary": "The daily window, holiday list, per-day slot table and 'available up to' horizon (mwb_mbfw_daily_calendar_start_time/_end_time, mwb_mbfw_choose_holiday, wps_mbfw_time_slots, wps_mbfw_set_availability_upto) describe WHEN the service can be booked. bookings/service carries only session durations; the writable Wix homes are Schedules V3 and Schedule Time Frames V3 (bookings domain docs-survey, verdict gap, 2026-08-16). Until an entity exists, treat these keys as reported fidelity loss on the service row - never as a Wix limitation."
+        },
+        {
+          "code": "cancellation-rules-have-no-authored-target",
+          "severity": "info",
+          "summary": "mwb_mbfw_cancellation_allowed plus the allowed-status list mwb_bfwp_order_statuses_to_cancel, and the advance-notice floor mwb_mbfw_minimum_no_days_booking, are per-service booking policy. Wix's Booking Policies API is the matching surface (create/update cancellation and early/late booking windows) but no entity claims it yet (bookings docs-survey verdict gap, 2026-08-16). Only mwb_mbfw_admin_confirmation has a home today - it maps to service.onlineBooking.requireManualApproval."
+        }
+      ]
+    },
+    {
+      "entity": "booking-appointment",
+      "channel": "core-embedded",
+      "embeddedIn": [
+        "/wc/v3/orders"
+      ],
+      "propertyPath": "_wps_single_cal_date_time_from",
+      "context": "view",
+      "requiresParent": "booking-service-product",
+      "candidateTargetRefs": [
+        "bookings/booking"
+      ],
+      "pitfalls": [
+        {
+          "code": "no-booking-record-exists",
+          "severity": "blocker",
+          "summary": "There is NO booking entity on the source. The plugin registers no booking post type and no booking order type - [VERIFIED LIVE 2026-08-16] the authed /wp/v2/types lists no mwb_/wps_ booking type at all, and the only CPT the plugin does register (wps_global_booking, show_in_rest true) is declared inside the admin class, which is loaded only under is_admin(), so REST never sees it. A booked appointment is therefore an ORDER LINE ITEM: one Wix booking per line item whose product is a booking product, read from /wc/v3/orders line_items[].meta_data. Order-level meta mwb_order_type = 'booking' is written on every order containing one (common/class-mwb-bookings-for-woocommerce-common.php mwb_bfwp_set_order_as_mwb_booking) and is the cheap filter for finding them."
+        },
+        {
+          "code": "dual-key-shape-and-fallback-order",
+          "severity": "warning",
+          "summary": "[DOCUMENTED source 3.12.0, public/class-mwb-bookings-for-woocommerce-public.php lines ~1195-1210] The appointment window is written under one of three shapes and the plugin's own reader tries them in this order: (1) _wps_single_cal_booking_dates - a single-calendar date list; (2) _wps_single_cal_date_time_from + _wps_single_cal_date_time_to; (3) the legacy _mwb_bfwp_date_time_from + _mwb_bfwp_date_time_to. Alongside them: _wps_booking_slot (chosen time slot), _mwb_mbfw_people_number (participant count, default 1), _mwb_mbfw_service_and_count (map of mwb_booking_service term id -> quantity), _mwb_mbfw_booking_extra_costs (array of mwb_booking_cost term ids), _item_cancelled ('yes') and _cancel_reason. Global-calendar products (_is_calendar_booking_product) use neither shape - they write the human-readable order item meta 'Booking Date' and 'Form Data' (wc_add_order_item_meta, same file line ~1576). Read every shape; a reader that knows only the _wps_ keys silently drops the legacy and global-calendar bookings."
+        },
+        {
+          "code": "dates-are-site-local-strings",
+          "severity": "warning",
+          "summary": "The date/time values are formatted strings in the SITE's timezone with no offset attached - the plugin recovers the zone from WordPress's timezone_string / gmt_offset options at read time (wps_mbfw_get_timezone in the REST class, [DOCUMENTED] 3.12.0). Wix Bookings wants ISO-8601 YYYY-MM-DDThh:mm:ss plus an IANA timezone (400 INVALID_DATE_FORMAT / INVALID_TIME_ZONE otherwise), so the importer must fetch the source site timezone once and stamp it on every booking. Do not assume UTC."
+        },
+        {
+          "code": "line-item-meta-visibility",
+          "severity": "warning",
+          "summary": "The booking keys are underscore-prefixed and the plugin adds most of them to woocommerce_hidden_order_itemmeta (admin/class-mwb-bookings-for-woocommerce-admin.php mbfw_hide_order_item_meta_data), which hides them in wp-admin but does NOT hide them from REST. [VERIFIED LIVE 2026-08-16] /wc/v3/orders does return underscore-prefixed non-internal line-item meta (sampled orders returned _reduced_stock among the line-item keys), so the read is expected to work. [NEEDS-VERIFICATION] no booking order was available to sample - none of the sampled orders carried an mwb_/wps_ key - so the shape has not been confirmed against a real record. Note /wc/v3/orders also supports include_meta / order_item_display_meta query args if a future run needs to trim the payload."
+        },
+        {
+          "code": "status-lives-on-the-order-not-the-booking",
+          "severity": "warning",
+          "summary": "A booking has no status of its own: it inherits the WooCommerce order status (the plugin's own listing filters on wc-processing / wc-on-hold / wc-pending / wc-completed and marks per-item cancellation with _item_cancelled). Mapping to Wix is NOT a straight status copy - bookings/booking documents that Create Booking discards any paymentStatus you send and that Confirm Booking, the only way to set one, refuses a booking that is already CONFIRMED. So a PAID source order must be created as CREATED and then confirmed (pitfalls payment-status-is-ignored-at-create and created-is-invisible-confirmed-needs-permission), an unpaid/pending order maps to PENDING, and a cancelled order or an _item_cancelled line item CANNOT be recreated in its terminal state at all - the post-create Cancel Booking call is the notification-firing path we are avoiding. Land cancelled appointments as CMS history."
+        },
+        {
+          "code": "past-appointments-unproven-on-the-target",
+          "severity": "blocker",
+          "summary": "Most of a real store's booking history is in the past, and the Wix side is NOT documented as accepting it - see bookings/booking pitfall past-dated-bookings-unverified (403 BOOKING_POLICY_VIOLATION and 428 SLOT_NOT_AVAILABLE are both live gates, skipAvailabilityValidation covers only availability and itself demands a resource). Plan historical appointments as CMS archive rows until a live probe proves the native path, and never report this as 'Wix cannot do bookings'."
+        },
+        {
+          "code": "sms-reminder-fires-on-future-bookings",
+          "severity": "blocker",
+          "summary": "Carried from the target: Wix's Create Booking sends an SMS 24 hours before the session unless sendSmsReminder:false is set on every call (the parameter's documented default is TRUE). A booking import of FUTURE appointments that omits the flag texts real customers. The generated importer must set it explicitly, and the run must hold the site-wide notification mute."
+        }
+      ]
+    },
+    {
+      "entity": "booking-additional-service",
+      "channel": "core-cpt",
+      "route": "/wp/v2/mwb_booking_service",
+      "candidateTargetRefs": [
+        "bookings/service-add-on"
+      ],
+      "pitfalls": [
+        {
+          "code": "term-meta-prices-are-invisible-to-rest",
+          "severity": "blocker",
+          "summary": "[VERIFIED LIVE 2026-08-16] the taxonomy is registered with show_in_rest:true and is served at /wp/v2/mwb_booking_service (authed and unauthenticated; X-WP-Total 0 when no terms have been created - the taxonomy exists). What comes back is only name/slug/description/count: the plugin stores every pricing rule as TERM META and calls register_meta nowhere ([DOCUMENTED] 0 occurrences in source 3.12.0), and term meta without show_in_rest is not exposed. The unreachable keys are mwb_mbfw_service_cost, mwb_mbfw_is_service_cost_multiply_people, mwb_mbfw_is_service_cost_multiply_duration, mwb_mbfw_is_service_optional, mwb_mbfw_is_service_hidden, mwb_mbfw_is_service_has_quantity, mwb_mbfw_service_minimum_quantity, mwb_mbfw_service_maximum_quantity (admin/partials/mwb-bookings-for-woocommerce-taxonomy-inline.php). Treat the price as Blocked - recoverable (user-supplied export or a source-side bridge), never as a Wix gap: bookings/service-add-on has a working write path and is waiting for the value."
+        },
+        {
+          "code": "attached-to-products-not-services",
+          "severity": "info",
+          "summary": "The taxonomy is registered on the `product` object type, so the association between a booking product and its additional services is the ordinary product term list. On the Wix side that association is a two-step on a different API (Create Add On Group on Services V2, then Set Add Ons For Group), and it is capped at 3 groups per service and 7 add-ons per group - see bookings/service-add-on pitfalls add-on-is-invisible-until-grouped and group-limits-cap-the-catalog. A source product carrying more than 21 optional extras cannot be recreated in full. Also note the plugin auto-includes every NON-optional term of the product at checkout (_mwb_mbfw_service_and_count is built from the terms whose mwb_mbfw_is_service_optional is not 'yes'), so optionality matters and is itself one of the unreadable term-meta keys."
+        }
+      ]
+    },
+    {
+      "entity": "booking-additional-cost",
+      "channel": "core-cpt",
+      "route": "/wp/v2/mwb_booking_cost",
+      "candidateTargetRefs": [
+        "bookings/service-add-on"
+      ],
+      "pitfalls": [
+        {
+          "code": "same-term-meta-blindness",
+          "severity": "blocker",
+          "summary": "[VERIFIED LIVE 2026-08-16] served at /wp/v2/mwb_booking_cost (labelled 'Additional Costs', registered on `product`, X-WP-Total 0 when no terms exist). Same storage model as booking-additional-service: names are readable, prices are not. Unreachable term meta: mwb_mbfw_booking_cost, mwb_mbfw_is_booking_cost_multiply_people, mwb_mbfw_is_booking_cost_multiply_duration, mwb_bfwp_booking_people_unit_cost, mwb_bfwp_booking_people_base_cost, mwb_mbfw_minimum_people_per_booking, mwb_bfwp_booking_people_maximum_quantity. Both taxonomies collapse onto the single Wix Add On object (bookings/service-add-on), which carries name + price plus a REQUIRED one-of durationInMinutes | maxQuantity - so the multiply-by-people and multiply-by-duration modifiers still have no Wix field and stay reported fidelity loss even once the prices are recovered, and each source extra must be forced into either the duration or the quantity kind at import time."
+        }
+      ]
+    }
+  ],
+  "quirks": [
+    "[VERIFIED LIVE 2026-08-16] plugin file id is mwb-bookings-for-woocommerce/mwb-bookings-for-woocommerce, taken verbatim from the authed /wp/v2/plugins list (name 'WPS Bookings for WooCommerce', version 3.12.0, status active, textdomain mwb-bookings-for-woocommerce, author WP Swings). The plugin is the former MakeWebBetter 'Bookings for WooCommerce'; the mwb_ prefix and the directory name are the fossil, while newer code and the REST namespace use wps_/wps-bfw. Expect BOTH prefixes on the same install - never normalise one into the other.",
+    "[VERIFIED LIVE 2026-08-16] the REST index advertises namespace wps-bfw/v1 with exactly one route (/wps-bfw/v1/bookings, GET, no args) plus the two taxonomy route pairs /wp/v2/mwb_booking_cost and /wp/v2/mwb_booking_service. All of them are present in the UNAUTHENTICATED index too, so this plugin is fully detectable with no credentials - namespace, routes and rest_bases all carry the plugin-specific mwb_/wps- prefix and none of them is a shared platform namespace. Do not confuse a separate plugin's dinekit/v1 namespace, which also serves /dinekit/v1/bookings/* (restaurant table reservations, a different plugin).",
+    "STORAGE MODEL, in one line: service definitions = unregistered post meta on a mwb_booking product (REST-visible via /wc/v3/products meta_data[]); appointments = unregistered order-ITEM meta on /wc/v3/orders line_items[], flagged by order meta mwb_order_type='booking'; add-ons = two REST-exposed product taxonomies whose prices sit in REST-invisible term meta; the plugin's own route is a per-user my-account projection. No custom database tables ([DOCUMENTED] no dbDelta/CREATE TABLE in source 3.12.0), so nothing here is db-only.",
+    "[DOCUMENTED source 3.12.0] The entire plugin is behind one option, mwb_mbfw_is_plugin_enable. When it is not 'yes' the product-type class filter, the two taxonomies and every checkout hook are all unregistered, while the stored meta stays in the database. Corollary used as evidence here: seeing the two taxonomies in the REST index proves the switch is on. On a source site where it is off, expect booking products to report type 'simple', the taxonomy routes to be absent from the REST index, and the plugin to be detectable only by its plugin file id or asset path - a live plugin list matters more than usual for this one.",
+    "[VERIFIED LIVE 2026-08-16] a store with the plugin active but no booking data of any kind was checked: no sampled product of type mwb_booking and none carrying an mwb_/wps_ meta key, no sampled order with mwb_order_type or booking line-item meta, no terms in either taxonomy, and /wps-bfw/v1/bookings returns []. Every payload-shape claim in this profile therefore rests on the published 3.12.0 source read from downloads.wordpress.org on 2026-08-16, not on an observed record. Re-verify against a store with real bookings before promoting any field list to a contract.",
+    "[DOCUMENTED source 3.12.0] Two adjacent surfaces that look like migration targets and are not: the wps_global_booking CPT (a booking-form/calendar definition, admin-only so invisible to REST) and the iCal export at /wps_global_calendar/{id}.ics and /export/ical/{id} (a rewrite-rule endpoint that emits only the BLOCKED dates from the _non_available_days meta of a global-calendar post - availability, not bookings). Neither carries appointment records.",
+    "A Pro edition exists (bookings-for-woocommerce-pro), and the free plugin branches on it - e.g. it skips force-assigning the 'booking' product_cat term when Pro is active with its category setting enabled. [NEEDS-VERIFICATION] the Pro edition's own meta keys and any extra REST surface have not been examined; a source site running Pro may carry keys this profile does not list."
+  ]
+}