@wix/agent-skills 1.33.1 → 1.34.0

package/skills/wix-replatform/resources/rp-source-wordpress/plugins/capabilities-pending-decision.json

@@ -0,0 +1,128 @@
+{
+  "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.composite-products",
+      "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 (signed 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.",
+      "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).",
+      "suspected": "no-target",
+      "plannedTarget": null,
+      "note": "Authored 2026-08-16 with the wpc-composite-products profile. Parallel case: requires-development.json[commerce.product-bundles] (decidedBy Product 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 a working workaround means this earns no standalone operator 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."
+    },
+    {
+      "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."
+    }
+  ],
+  "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."
+    }
+  ]
+}

package/skills/wix-replatform/resources/rp-source-wordpress/plugins/cms-fallback-eligible.json

@@ -0,0 +1,18 @@
+{
+  "schemaVersion": 1,
+  "description": "The CMS-fallback eligibility register: recognized plugin capabilities for which a NAMED HUMAN has determined that nothing native in Wix fits, so a Wix CMS (Wix Data) collection is an acceptable place to keep the records. Eligibility alone never plans a write: each migration keeps the capability pending until the merchant approves or declines that specific fallback at the mapping review, recorded in that project's orchestration/decisions.json under pluginCmsFallback:<capability> (written only by `orchestration-state.js decide-cms-fallback`). CMS keeps the records; it does not bring back what the plugin did, and `featureLoss` says what the merchant loses, verbatim, at the approval ask and in reports.\n\nRules (enforced by plugin-knowledge-validate.js): every entry is signed (`decidedBy`, `decidedOn`); `targetRefsByEntity` keys cover exactly the profile entities of the capability, and only a capability whose every declaring profile declares exactly one capability may appear; every ref starts with cms/ and is a known target ref; a capability may not also appear in requires-development.json or no-migration-needed.json capabilities[]; and an entry is rejected once a Wix target entity claims the capability. Plugin profiles never name cms/* refs in candidateTargetRefs.",
+  "capabilities": [
+    {
+      "capability": "content.podcast",
+      "targetRefsByEntity": {
+        "seriously-simple-podcasting/episode": ["cms/collection", "cms/data-item"]
+      },
+      "reason": "Wix has no native podcast entity: no Wix target entity claims content.podcast, so episodes can only be kept as CMS data (a collection of episodes, with audio files referenced as media).",
+      "nativeAlternativesChecked": "Bundled Wix target knowledge (rp-target-wix domains capabilityIndex) has no entity claiming content.podcast and no podcast, episode or feed target; reviewed with the original 2026-08-16 signature, which recorded CMS as the migration model for this capability.",
+      "featureLoss": "Episodes arrive as CMS data; no podcast player or RSS feed is recreated.",
+      "decidedBy": "Product Owner",
+      "decidedOn": "2026-08-16",
+      "note": "Replaces the CMS refs formerly declared in seriously-simple-podcasting.json's episode entity and the signature recorded in its no-native-podcast-target pitfall; the signature is scoped to this capability only."
+    }
+  ]
+}

package/skills/wix-replatform/resources/rp-source-wordpress/plugins/contact-form-7.json

@@ -0,0 +1,104 @@
+{
+  "schemaVersion": 1,
+  "plugin": "contact-form-7",
+  "displayName": "Contact Form 7",
+  "profileVersion": "2026-08",
+  "sourceOfTruth": "https://contactform7.com/rest-api/",
+  "distribution": "wordpress-org",
+  "capabilities": [
+    "content.form-definitions"
+  ],
+  "detect": {
+    "pluginFileIds": [
+      "contact-form-7/wp-contact-form-7"
+    ],
+    "routes": [
+      "/contact-form-7/v1/contact-forms"
+    ],
+    "restNamespaces": [
+      "contact-form-7/v1"
+    ],
+    "assetPathSlugs": [
+      "contact-form-7"
+    ]
+  },
+  "entities": [
+    {
+      "entity": "contact-form",
+      "channel": "plugin-rest",
+      "route": "/contact-form-7/v1/contact-forms",
+      "context": "edit",
+      "recordKeyField": "id",
+      "candidateTargetRefs": [
+        "forms/form"
+      ],
+      "pitfalls": [
+        {
+          "code": "collection-is-a-stub",
+          "severity": "blocker",
+          "summary": "[VERIFIED LIVE 2026-08-16] The collection returns only an index row per form — `{id, hash, slug, title, locale}` — and NO field data at all. Reading this route alone yields a list of form names with nothing to build a Wix schema from. The definition lives on the per-form route; see the contact-form-definition entity, which is why this profile declares a plugin-rest-child alongside the collection instead of treating the list as the record."
+        },
+        {
+          "code": "route-is-admin-gated",
+          "severity": "warning",
+          "summary": "[VERIFIED LIVE 2026-08-16] Anonymous GET returns 403 `wpcf7_forbidden` ('You are not allowed to access contact forms.'); the same GET with an administrator application password returns 200. Discovery must therefore treat an empty/failed CF7 read as a CREDENTIALS problem, not as 'the site has no forms'. The route is nonetheless listed in the public REST index (both authed and anonymous), so DETECTION works with no credentials even though READING does not."
+        },
+        {
+          "code": "collection-also-accepts-post",
+          "severity": "warning",
+          "summary": "[VERIFIED LIVE 2026-08-16] OPTIONS on /contact-form-7/v1/contact-forms reports methods GET and POST — POST on this route CREATES a contact form. This is a read-only source adapter: never issue anything but GET here. Recorded because the route's own shape is the trap, not the profile."
+        }
+      ]
+    },
+    {
+      "entity": "contact-form-definition",
+      "channel": "plugin-rest-child",
+      "route": "/contact-form-7/v1/contact-forms/{parentId}",
+      "parentRoute": "/contact-form-7/v1/contact-forms",
+      "requiresParent": "contact-form",
+      "recordKeyField": "id",
+      "candidateTargetRefs": [
+        "forms/form"
+      ],
+      "pitfalls": [
+        {
+          "code": "form-tag-syntax-is-the-real-schema",
+          "severity": "blocker",
+          "summary": "[VERIFIED LIVE 2026-08-16] The durable definition is `properties.form.content` — CF7's own form-tag markup, e.g. `[text* your-name autocomplete:name]` interleaved with raw HTML labels. CF7 also ships a PARSED view at `properties.form.fields[]`, each entry `{type, basetype, name, options[], raw_values[], labels[], values[], pipes[], content}`. Consume `fields[]`, not the markup: a trailing `*` on `type` (`text*` vs `text`) is how CF7 encodes REQUIRED, `basetype` is the type without it, `name` is the stable machine key that becomes the Wix field `target`, and `values`/`labels`/`pipes` carry the choices for select/radio/checkbox tags. The surrounding HTML labels are NOT in fields[] — a field's human label lives in the markup, so a definition read that ignores `content` produces Wix fields with machine names and no captions."
+        },
+        {
+          "code": "mail-templates-are-not-form-fields",
+          "severity": "warning",
+          "summary": "[VERIFIED LIVE 2026-08-16] `properties` carries five keys: `form`, `mail`, `mail_2`, `messages`, `additional_settings`. Only `form` is field data. `mail` / `mail_2` are the notification email templates (subject, sender, body, recipient, additional_headers, attachments, use_html, exclude_blank — with CF7 mail-tags like `[_site_admin_email]` and `[your-subject]` interpolated), `messages` is the 23 validation/status strings, `additional_settings` is free-form config. None of these map to a Wix Form Schema create input: Wix notification behaviour is Automations, and the confirmation text is `submitSettings.submitSuccessAction`. Treat mail_* as reconfigure-in-wix and ledger it — do not attempt to translate a mail template into anything on forms/form."
+        },
+        {
+          "code": "cf7-does-not-store-submissions",
+          "severity": "blocker",
+          "summary": "[VERIFIED LIVE 2026-08-16] CF7 persists NOTHING a visitor submits. Its delivery model is email-only: on submit it renders `mail` / `mail_2` and sends them. There is no submissions collection on this route, no submissions table, and no submissions CPT belonging to this plugin. On sites that also run Flamingo, the messages are stored by FLAMINGO, under Flamingo's own plugin id and CPTs — a different plugin owning different data, so it is deliberately NOT covered by this profile. See quirks for the ownership decision and what Flamingo needs."
+        }
+      ]
+    }
+  ],
+  "excludeRoutes": [
+    {
+      "route": "/contact-form-7/v1/contact-forms/{parentId}/feedback",
+      "reason": "runtime submit endpoint — a POST here SUBMITS the form for real, firing CF7's mail templates to the site owner. Must never be touched by a read-only source adapter."
+    },
+    {
+      "route": "/contact-form-7/v1/contact-forms/{parentId}/feedback/schema",
+      "reason": "client-side validation schema for the live form widget; derivable from the definition we already read, and carries no durable business data."
+    },
+    {
+      "route": "/contact-form-7/v1/contact-forms/{parentId}/refill",
+      "reason": "runtime helper that refreshes CAPTCHA/quiz values for a rendered form; ephemeral, no durable data."
+    }
+  ],
+  "quirks": [
+    "[VERIFIED LIVE 2026-08-16, CF7 6.1.6] The plugin file id is `contact-form-7/wp-contact-form-7` — directory and main-file basename DIFFER. Constructing it as `contact-form-7/contact-form-7` (the obvious guess) yields a signal that never matches. Read from GET /wp/v2/plugins, never assemble.",
+    "[VERIFIED LIVE 2026-08-16] The `wpcf7_contact_form` CPT is NOT REST-visible: it is absent from /wp/v2/types even with an administrator application password, and GET /wp/v2/wpcf7_contact_form returns 404. [DOCUMENTED, source 6.1.6 includes/contact-form.php] register_post_type() is called with public=false and no `show_in_rest`, which defaults to false. So core-cpt is not a channel here and the plugin's own namespace is the only REST way in.",
+    "[DOCUMENTED, source 6.1.6] The CPT does NOT set `can_export`, so it defaults to true and CF7 form definitions ARE carried in a standard WXR export. That is a viable credential-free fallback channel if the operator can supply an export but not an admin application password; not declared as an entity because the live REST channel is present and richer (it hands back CF7's own parsed fields[], where WXR hands back raw post_content the adapter would have to parse itself).",
+    "OWNERSHIP DECISION 2026-08-16 — Flamingo is a separate profile, not entities here. Flamingo ships as its own plugin (`flamingo/flamingo`, 2.6.3) and stores CF7 submissions in ITS OWN CPTs (`flamingo_inbound` for messages, `flamingo_contact` for the derived address book). It also stores messages from senders other than CF7. Folding those into contact-form-7.json would attribute one plugin's data to another and would break the moment a site runs Flamingo without CF7 or CF7 without Flamingo — so `content.form-submissions` is deliberately NOT claimed by this profile, and CF7's submissions capability is UNREACHABLE WITHOUT A FLAMINGO PROFILE.",
+    "[VERIFIED LIVE 2026-08-16] Flamingo is not reachable over REST at all: no `flamingo` namespace appears in the REST index, `flamingo_inbound`/`flamingo_contact` are absent from authed /wp/v2/types, and GET /wp/v2/flamingo_inbound returns 404. [DOCUMENTED, source 2.6.3 includes/class-inbound-message.php + class-contact.php] both CPTs register with an explicit `'show_in_rest' => false`, as do their taxonomies. A future flamingo.json therefore cannot use plugin-rest or core-cpt — its channels are `export-file` (the CPTs do not set can_export, so WXR carries them; Flamingo also ships an admin CSV export, includes/csv.php) or `db-only`. Stored per message: `_fields` (the submitted values map), `_subject`, `_from`, `_from_name`, `_from_email`, `_meta`, `_akismet`, `_recaptcha`, `_spam_log`, `_consent`, `_hash`, plus post_date as the original timestamp — and a dedicated `flamingo-spam` post status that a migration must filter out rather than recreate.",
+    "The Wix side of the submissions path already exists and is NOT the blocker: forms/form-submission claims content.form-submissions, accepts a backdated `createdDate`, and is authored and ready. The gap is purely source-side reachability. Because a Wix target entity already claims that capability, this cannot be filed in capabilities-pending-decision.json (the validator rejects a pending entry once a target claims it) — the correct next action is a flamingo.json profile, not a pending register entry."
+  ]
+}

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

@@ -0,0 +1,44 @@
+{
+  "schemaVersion": 1,
+  "plugin": "facebook-for-woocommerce",
+  "displayName": "Meta for WooCommerce",
+  "profileVersion": "2026-08",
+  "sourceOfTruth": "https://woocommerce.com/products/facebook/",
+  "distribution": "wordpress-org",
+  "capabilities": [
+    "commerce.facebook-catalog-sync"
+  ],
+  "detect": {
+    "pluginFileIds": [
+      "facebook-for-woocommerce/facebook-for-woocommerce.php"
+    ],
+    "recordProperties": [
+      "_wc_facebook_sync_enabled",
+      "fb_visibility",
+      "_wc_facebook_google_product_category"
+    ],
+    "assetPathSlugs": [
+      "facebook-for-woocommerce"
+    ]
+  },
+  "entities": [
+    {
+      "entity": "facebook-catalog-sync",
+      "channel": "core-meta",
+      "embeddedIn": ["/wc/v3/products"],
+      "propertyPath": "_wc_facebook_sync_enabled",
+      "candidateTargetRefs": ["sales-channels/meta-catalog-connect"],
+      "pitfalls": [
+        {
+          "code": "manual-mapping-per-product-settings-not-portable",
+          "severity": "warning",
+          "summary": "Migration-planned via manual-mapping, superseding the earlier reconfigure-in-wix/no-need-to-migrate verdict (2026-08-16) now that rp-target-wix/domains/sales-channels/entities/meta-catalog-connect.json exists: the sync outcome is a real, numbered merchant runbook (connect the native Meta catalog feed), not just a one-line reason. The per-product settings in wc/v3/products meta_data — including _wc_facebook_google_product_category — still do not carry over; see that entity's per-product-settings-not-portable pitfall for the live-verified reason (no facebookProductOverrides arm in wix.stores_channels.marketplace_overrides.v1.product_override)."
+        }
+      ]
+    }
+  ],
+  "quirks": [
+    "No REST route at all — data is only visible as meta_data entries on wc/v3/products (verified in source, includes/Products.php, 2026-08-11: not directly network-verified against a live site's actual meta_data payload; confirm on next live run).",
+    "sync-enabled/visibility/category fields are per-product configuration for the Facebook/Instagram/WhatsApp shops integration, not customer-facing commerce data like orders or reviews."
+  ]
+}

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

@@ -0,0 +1,49 @@
+{
+  "schemaVersion": 1,
+  "description": "Alias map for the fingerprinted tier: public evidence tokens — a wp-content/plugins/<slug> asset path or the first segment of an unrecognized REST namespace — resolved to a plugin display name. No entities, no channels, no target refs: carrying a name never requires authoring a migration profile. The tier makes no completeness claim and never feeds route selection; it exists so an unauthenticated run stops understating what it can plainly see. Entries grow from real runs, like the no-migration-needed list.",
+  "aliases": {
+    "cky": { "displayName": "CookieYes", "slug": "cookie-law-info" },
+    "nextend-social-login": { "displayName": "Nextend Social Login", "slug": "nextend-facebook-connect" },
+    "fgf": { "displayName": "Free Gifts for WooCommerce", "slug": "free-gifts-for-woocommerce" },
+    "mc4wp": { "displayName": "MC4WP: Mailchimp for WordPress", "slug": "mailchimp-for-wp" },
+    "mailpoet": { "displayName": "MailPoet", "slug": "mailpoet" },
+    "ai1wm": { "displayName": "All-in-One WP Migration and Backup", "slug": "all-in-one-wp-migration" },
+    "dinekit": { "displayName": "DineKit", "slug": "dinekit" },
+    "zprint": { "displayName": "BizPrint Print Manager for WooCommerce", "slug": "print-google-cloud-print-gcp-woocommerce" },
+    "syncee": { "displayName": "Syncee Premium Dropshipping & Wholesale", "slug": "syncee-global-dropshipping" },
+    "wc-facebook": { "displayName": "Meta for WooCommerce", "slug": "facebook-for-woocommerce" },
+    "fb_api": { "displayName": "Meta for WooCommerce", "slug": "facebook-for-woocommerce" },
+    "google-site-kit": { "displayName": "Site Kit by Google", "slug": "google-site-kit" },
+    "regenerate-thumbnails": { "displayName": "Regenerate Thumbnails", "slug": "regenerate-thumbnails" },
+    "wp-rollback": { "displayName": "WP Rollback", "slug": "wp-rollback" },
+    "meow-mailer": { "displayName": "Meow Mailer", "slug": "meow-mailer" },
+    "jetpack-boost": { "displayName": "Jetpack Boost", "slug": "jetpack-boost" },
+    "jetpack": { "displayName": "Jetpack", "slug": "jetpack" },
+    "crowdsignal-forms": { "displayName": "Crowdsignal Forms", "slug": "crowdsignal-forms" },
+    "newspack-blocks": { "displayName": "Newspack Blocks", "slug": "newspack-blocks" },
+    "health-check": { "displayName": "Health Check & Troubleshooting", "slug": "health-check" },
+    "woocommerce_aliexpress_dropship": { "displayName": "ALD - Dropshipping and Fulfillment for AliExpress", "slug": "woo-alidropship" },
+    "woocommerce-products-filter": { "displayName": "HUSKY - Products Filter Professional for WooCommerce", "slug": "woocommerce-products-filter" },
+    "sharemypost": { "displayName": "ShareMyPost", "slug": "sharemypost" },
+    "npcink-ad": { "displayName": "Npcink Ad", "slug": "npcink-ad" },
+    "itboffins-live-opening-hours": { "displayName": "ITBoffins Live Opening Hours Banner & Table", "slug": "itboffins-live-opening-hours" },
+    "disclaimer-popup": { "displayName": "Disclaimer Popup", "slug": "disclaimer-popup" },
+    "contact-form-7": { "displayName": "Contact Form 7", "slug": "contact-form-7" },
+    "wordpress-seo": { "displayName": "Yoast SEO", "slug": "wordpress-seo" },
+    "yoast": { "displayName": "Yoast SEO", "slug": "wordpress-seo" },
+    "elementor": { "displayName": "Elementor", "slug": "elementor" },
+    "wpforms": { "displayName": "WPForms", "slug": "wpforms-lite" },
+    "gravityforms": { "displayName": "Gravity Forms", "slug": "gravityforms" },
+    "gf": { "displayName": "Gravity Forms", "slug": "gravityforms" },
+    "buddypress": { "displayName": "BuddyPress", "slug": "buddypress" },
+    "tribe": { "displayName": "The Events Calendar", "slug": "the-events-calendar" },
+    "ssp": { "displayName": "Seriously Simple Podcasting", "slug": "seriously-simple-podcasting" },
+    "gutenberg": { "displayName": "Gutenberg", "slug": "gutenberg" },
+    "akismet": { "displayName": "Akismet Anti-spam", "slug": "akismet" },
+    "my-jetpack": { "displayName": "Jetpack", "slug": "jetpack" },
+    "jetpack-global-styles": { "displayName": "Jetpack", "slug": "jetpack" },
+    "videopress": { "displayName": "Jetpack VideoPress", "slug": "jetpack-videopress" },
+    "wpjm-internal": { "displayName": "WP Job Manager", "slug": "wp-job-manager" },
+    "pw-woocommerce-gift-cards": { "displayName": "PW WooCommerce Gift Cards", "slug": "pw-woocommerce-gift-cards" }
+  }
+}

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

@@ -0,0 +1,94 @@
+{
+  "schemaVersion": 1,
+  "plugin": "free-gifts-for-woocommerce",
+  "displayName": "Free Gifts for WooCommerce",
+  "profileVersion": "2026-08",
+  "sourceOfTruth": "https://woocommerce.com/products/free-gifts-for-woocommerce/",
+  "distribution": "premium-or-unlisted",
+  "capabilities": [
+    "commerce.coupons",
+    "commerce.free-gift-rules"
+  ],
+  "detect": {
+    "pluginFileIds": [
+      "free-gifts-for-woocommerce/free-gifts-for-woocommerce.php"
+    ],
+    "assetPathSlugs": [
+      "free-gifts-for-woocommerce"
+    ]
+  },
+  "entities": [
+    {
+      "entity": "coupon-gift-rule-definition",
+      "capability": "commerce.coupons",
+      "channel": "admin-page-only",
+      "candidateTargetRefs": [
+        "stores/coupon"
+      ],
+      "pitfalls": [
+        {
+          "code": "plugin-identity-ambiguous",
+          "severity": "warning",
+          "summary": "Two distinct plugins both document an install folder literally named `free-gifts-for-woocommerce`: the closed-source WooCommerce.com Marketplace extension 'Free Gifts for WooCommerce' (woocommerce.com/products/free-gifts-for-woocommerce/, active development through v12.8.0 as of 2025-12-19 per wpspring.com's changelog mirror), and the free wordpress.org plugin now listed under a DIFFERENT current slug, `free-gifts-product-for-woocommerce` ('Free Gift Product For WooCommerce'). This profile assumes the WooCommerce.com Marketplace extension, matching both the requested slug and the existing `fgf` alias in fingerprint-aliases.json — but neither plugin's source was reachable (closed/paid, not GitHub-mirrored; wordpress.org network fetches failed in the research pass behind this profile). Re-verify plugin identity against the live site's `GET /wp/v2/plugins` name/description before trusting this profile's specifics.",
+          "unverified": true
+        },
+        {
+          "code": "rest-crud-added-2025-unverified-route",
+          "severity": "warning",
+          "summary": "Per the vendor's own changelog (v12.2.0, released 2025-07-02, mirrored at wpspring.com/free-gifts-for-woocommerce-changelog/): 'REST API endpoints support was added to enable full CRUD operation for Free Gift rule(s) and Master Log', with a response-key rename in the same release. This means current installs (v12.2.0+) may have a genuine plugin-rest channel for rule definitions — a materially better position than woo-discount-rules ever had. No route path, namespace, or auth requirement was discoverable without source access (closed-source, no live site to probe). Classified admin-page-only here as the conservative default; the highest-value follow-up for this profile is a live `GET /wp-json` route-index check on an actual install running v12.2.0+ before assuming no REST path.",
+          "unverified": true
+        },
+        {
+          "code": "gift-is-not-auto-added-on-wix",
+          "severity": "warning",
+          "summary": "A rebuilt Wix coupon does NOT reproduce this plugin's central behaviour, and the loss is easy to miss because the mapping otherwise looks clean. On the source, applying the Coupon Gift code ADDS the gift product to the cart. The Wix equivalent — `percentOffRate: 100` scoped to that product — only discounts the gift if the buyer has already put it in the cart, so a buyer who enters the code and adds nothing receives nothing. There is no platform fallback: no Wix service plugin mutates a cart (every extension returns a decision — eligible triggers, rates, fees, validations, tax — and none can insert a line item). So the outcome is either the lossy coupon plus an explicit note to the merchant, or custom storefront/app development outside the migration. Surface this at mapping review rather than after go-live. See rp-target-wix/domains/stores/entities/coupon.json's free-gift-coupons-are-a-lossy-mapping-the-gift-is-not-auto-added."
+        },
+        {
+          "code": "admin-page-not-reachable-with-application-password",
+          "severity": "blocker",
+          "summary": "Coupon Gift is standing configuration and maps to a product-scoped Wix coupon, not an Automatic Discount. The source rule is still admin-page-only unless the unverified REST CRUD route is present; Application Passwords cannot authenticate a wp-admin settings-page render.",
+          "blocked": [
+            {
+              "kind": "user-file",
+              "resolution": "First check whether the live site's REST index exposes a Free Gifts namespace (v12.2.0+ may have one). If not, ask the site owner to transcribe or screenshot each Coupon Gift rule, including its code, trigger threshold, and eligible gift product. Rebuild it as a product-scoped Wix coupon — and see the gift-is-not-auto-added-on-wix pitfall below before telling anyone the rebuild is equivalent.",
+              "declined": false
+            }
+          ]
+        }
+      ]
+    },
+    {
+      "entity": "automatic-or-bogo-gift-rule-definition",
+      "capability": "commerce.free-gift-rules",
+      "channel": "admin-page-only",
+      "candidateTargetRefs": [
+        "ecom/discount-rule"
+      ],
+      "pitfalls": [
+        {
+          "code": "different-product-gift-maps-to-buy-x-get-y",
+          "severity": "warning",
+          "summary": "CORRECTED 2026-08-31 — this pitfall previously said no native Wix target existed for granting a DIFFERENT product, and that was WRONG. Automatic Gift and Buy X Get Y both map natively: DiscountRule `discounts.values[].targetType` accepts BUY_X_GET_Y with a `buyXGetYInfo` payload ({customerBuys: {scopes[], minimumQuantity|minimumSpend}, customerGets: {scopes[], quantity}, limit?}). Set customerBuys to the threshold scope and customerGets to the gift product with discountType FIXED_PRICE / fixedPrice '0'. So route these definitions to ecom/discount-rule rather than keeping the capability pending. The old conclusion came from reading QUANTITY_BASED, which is the wrong axis — BOGO lives on targetType, not discountType — and from buyXGetYInfo being absent from the published method schema while the docs' own Buy-X-Get-Y example returns HTTP 500. WHAT STILL DOES NOT MAP is a gate Wix has no trigger for, a cart COUPON CODE being the common one: such a rule imported `active` applies to every shopper unconditionally, so import it inactive and flag it, or rebuild it as a Wix coupon. See rp-target-wix/domains/ecom/entities/discount-rule.json's buy-x-get-y-is-supported-but-undocumented pitfall."
+        },
+        {
+          "code": "admin-page-not-reachable-with-application-password",
+          "severity": "blocker",
+          "summary": "The rule definitions are admin-page-only unless the vendor's unverified v12.2.0+ REST CRUD route is present. Application Passwords cannot authenticate a wp-admin settings-page render.",
+          "blocked": [
+            {
+              "kind": "user-file",
+              "resolution": "First check whether the live site's REST index exposes a Free Gifts namespace. If not, ask the site owner to transcribe or screenshot each Automatic Gift and Buy X Get Y rule so the unsupported behavior is visible at mapping review.",
+              "declined": false
+            }
+          ]
+        }
+      ]
+    }
+  ],
+  "quirks": [
+    "Functional scope (vendor docs, woocommerce.com/document/free-gifts/): Coupon Gift is standing configuration mapped to stores/coupon; Automatic Gift and Buy X Get Y are tracked separately as the commerce.free-gift-rules capability, which routes to ecom/discount-rule via targetType BUY_X_GET_Y (corrected 2026-08-31; it was recorded as pending until then). The rule DEFINITIONS are still admin-page-only, so having a target does not make them readable; Manual Gift is a merchant action on an individual order, not standing configuration or an entity to migrate.",
+    "Vendor docs and third-party summaries consistently describe the applied gift as landing on the order as a real $0.00 line item for the gift product (either via a zero-price line or a $0 coupon restricted to that product) — this is NOT a distinct entity here because a $0 product line item already migrates generically through the existing commerce.order-line-items capability (ecom/order-line-item, sourceEntity woocommerce:order_line_item, confidence high) with no plugin-specific channel required. What is NOT captured anywhere in this profile is a marker distinguishing 'this $0 line was a promotional gift' from 'the merchant manually priced this product at $0' — no meta key was found (no source access); if a future live run finds one (search sampled order line_items[].meta_data for anything gift-related), add it here as a core-meta entity under a new applied-discount-style capability rather than folding it into commerce.order-line-items.",
+    "fingerprint-aliases.json already maps the observed `fgf` asset-path token to `free-gifts-for-woocommerce`, promoting that otherwise named-only signal to this profile's deterministic detection path.",
+    "This profile has not been verified against a running installation of the assumed WooCommerce.com Marketplace extension. Every behavioral claim above is vendor-documentation-tier, not source- or live-verified."
+  ]
+}