@wix/agent-skills 1.36.0 → 1.36.1

package/skills/wix-replatform/resources/rp-source-wordpress/plugins/advanced-custom-fields.json

@@ -1,101 +0,0 @@
-{
-  "schemaVersion": 1,
-  "plugin": "advanced-custom-fields",
-  "displayName": "Advanced Custom Fields",
-  "profileVersion": "2026-08",
-  "sourceOfTruth": "https://wordpress.org/plugins/advanced-custom-fields/",
-  "distribution": "wordpress-org",
-  "capabilities": [
-    "content.custom-fields",
-    "content.custom-field-schema"
-  ],
-  "detect": {
-    "pluginFileIds": [
-      "advanced-custom-fields/acf"
-    ],
-    "recordProperties": [
-      "acf",
-      "_acf_changed"
-    ],
-    "assetPathSlugs": [
-      "advanced-custom-fields"
-    ]
-  },
-  "entities": [
-    {
-      "entity": "field-values",
-      "channel": "core-embedded",
-      "embeddedIn": [
-        "/wp/v2/posts",
-        "/wp/v2/media",
-        "/wp/v2/categories",
-        "/wp/v2/tags",
-        "/wp/v2/users"
-      ],
-      "propertyPath": "acf",
-      "candidateTargetRefs": [],
-      "pitfalls": [
-        {
-          "code": "acf-key-rides-every-wp-v2-object-type",
-          "severity": "info",
-          "summary": "ACF registers a single REST field named `acf` per request, against whichever object sub type the request resolves to - post type, taxonomy or user. [VERIFIED IN PLUGIN SOURCE v6.8.7, includes/rest-api/class-acf-rest-api.php register_field(), 2026-08-16.] [VERIFIED LIVE 2026-08-16] the key is present on every sampled record of /wp/v2/posts, /wp/v2/pages, /wp/v2/media, /wp/v2/product, /wp/v2/podcast, /wp/v2/tribe_events, /wp/v2/categories and /wp/v2/users. embeddedIn lists the core routes; any plugin CPT the classifier accepts through wp.data.registered-type carries it too, so an extraction step must look for `acf` on every wp/v2 record it fetches rather than only on the listed routes. /wp/v2/pages is listed nowhere because pages are excluded from backend-data scope by wp.frontend.pages."
-        },
-        {
-          "code": "absent-from-woocommerce-rest",
-          "severity": "warning",
-          "summary": "[VERIFIED LIVE 2026-08-16] the `acf` key does NOT appear on any sampled /wc/v3/products or /wc/v3/products/categories record - ACF only extends the wp/v2 controllers. Custom field values on a WooCommerce product are therefore readable only through /wp/v2/product, which returns no commerce fields, so a product import that wants both must join the two by post id."
-        },
-        {
-          "code": "empty-array-means-no-groups-not-no-plugin",
-          "severity": "warning",
-          "summary": "[VERIFIED LIVE 2026-08-16] a site with no field groups defined returns `acf: []` on every sampled record - an empty ARRAY, not an object. Detection must treat presence of the key as the signal and must not require a truthy value; and a run that finds only empty acf keys should report 'ACF installed, no field data' rather than a failed read. [NEEDS-VERIFICATION on a site with real field groups: the populated shape (a {fieldName: value} object) and the per-field-type value shapes.]"
-        },
-        {
-          "code": "value-shapes-are-field-type-dependent",
-          "severity": "warning",
-          "summary": "ACF returns typed values, not strings: a relationship or post-object field returns post IDs (or embedded objects when ACF's rest_api_embed_links setting is on), an image/file field returns an attachment ID or an object, a repeater returns an array of row objects, a flexible-content field returns rows tagged with acf_fc_layout, and a taxonomy field returns term IDs. Every ID-bearing value must be remapped through the relevant crosswalk after its target exists, exactly like any other reference. A CMS collection column type cannot be chosen without knowing the field type, which is why field-group-definitions is a prerequisite rather than a nice-to-have. [DOCUMENTED - ACF field-type reference; not exercised live.]"
-        },
-        {
-          "code": "rest-visibility-is-opt-in-per-field-group",
-          "severity": "warning",
-          "summary": "The `acf` property only carries a group's fields when that field group has Show in REST API enabled, and the whole integration can be switched off site-wide (acf_get_setting('rest_api_enabled')). Accordion, tab and message field types are never exposed (show_in_rest = false on those classes). [VERIFIED IN PLUGIN SOURCE v6.8.7, includes/rest-api/class-acf-rest-api.php and includes/fields/class-acf-field-{accordion,tab,message}.php, 2026-08-16.] So an empty or partial acf object can mean 'not exposed' rather than 'not set', and the run cannot tell the two apart from REST alone - reconcile against the field-group definitions before reporting completeness."
-        }
-      ]
-    },
-    {
-      "entity": "field-group-definitions",
-      "channel": "export-file",
-      "candidateTargetRefs": [],
-      "pitfalls": [
-        {
-          "code": "acf-field-group-cpt-is-not-rest-visible",
-          "severity": "blocker",
-          "summary": "Field group definitions are stored as posts of the `acf-field-group` post type, registered with 'show_in_rest' => false. [VERIFIED IN PLUGIN SOURCE v6.8.7, includes/post-types/class-acf-field-group.php:104, 2026-08-16.] [VERIFIED LIVE 2026-08-16: acf-field-group is absent from /wp/v2/types, identical authenticated and unauthenticated, and GET /wp/v2/acf-field-group returns 404, as do acf-field, acf-post-type, acf-taxonomy and acf-ui-options-page.] There is no REST read path, authenticated or otherwise, so this entity is Blocked - recoverable (kind: user-file) until the user supplies an export."
-        },
-        {
-          "code": "the-export-the-user-must-produce",
-          "severity": "warning",
-          "summary": "ACF ships its own exporter - ACF > Tools > Export Field Groups, which emits a JSON file (or generates PHP) - and many themes keep the same JSON checked in under an acf-json/ directory. Either is the file to ask for. That JSON carries the field key, name, label, type, per-type settings (choices, sub_fields, layouts, return_format) and the location rules that say which post types the group applies to; the WXR export does NOT reliably carry it, because the definitions are posts plus their own acf-field child posts. Ask for the ACF JSON specifically, not for a WXR."
-        },
-        {
-          "code": "definitions-are-the-cms-schema",
-          "severity": "warning",
-          "summary": "This entity does not migrate as records - it is the input that decides the shape of the Wix CMS collection that field-values lands in: one column per ACF field, with the column type derived from the ACF field type, and one collection per (post type x field group) grouping. cms/collection is setup-config: the collection must exist before any item import, and creating it is not automated. Import ordering is therefore definitions (setup) -> owning records -> field values."
-        },
-        {
-          "code": "group-definitions-are-not-lost-if-unavailable",
-          "severity": "info",
-          "summary": "If the user cannot supply the export, the field VALUES are still fully readable from the `acf` key and can land in a CMS collection whose columns are inferred from the observed values. That is reduced fidelity - inferred types, no labels, no choice lists, repeaters flattened or stored as JSON - and it must be ledgered as such, but it is never a reason to drop the data."
-        }
-      ]
-    }
-  ],
-  "quirks": [
-    "Plugin file id is `advanced-custom-fields/acf` - the main-file basename is `acf`, not the directory name, and the /wp/v2/plugins id carries no .php suffix [VERIFIED LIVE 2026-08-16: active, version 6.8.7, textdomain acf]. Never construct dir/dir.php. ACF PRO is a separate directory (advanced-custom-fields-pro/acf) and would appear as its own row.",
-    "Storage model: two different ones in one plugin, which is why it has two entities. Field VALUES are ordinary post/term/user meta that ACF re-exposes as a computed REST property (`acf`), so they are REST-visible without being registered meta - channel core-embedded. Field GROUP DEFINITIONS are a post type deliberately hidden from REST - channel export-file. Reading the values without the definitions is possible but lossy; reading the definitions without a user-supplied file is impossible.",
-    "Registers NO REST namespace of its own [VERIFIED LIVE 2026-08-16: the site's REST index advertises no namespace such as acf/* or acf/v3]. ACF is a textbook route-less plugin: nothing about it appears in the REST index, and the only way to see it is the payload-key pass over sampled records - the 'record payload keys' tier, and the reason detection is split into two passes.",
-    "Enqueues no front-end asset [VERIFIED LIVE 2026-08-16: no wp-content/plugins/advanced-custom-fields path in the homepage or a post permalink], so assetPathSlugs will not fire and the fingerprinted tier cannot see ACF from public HTML. It is listed anyway because a theme that enqueues an ACF-provided script would expose it.",
-    "ACF also leaves a registered meta key `_acf_changed` on every post [VERIFIED LIVE 2026-08-16: present in the `meta` object of /wp/v2/posts, /wp/v2/pages, /wp/v2/product and /wp/v2/categories records, authenticated AND unauthenticated, value false]. It is an editor bookkeeping flag with no migration value, but it is a reliable secondary detection signal that survives when a site has zero field groups and every `acf` value is empty.",
-    "ACF's newer builders - ACF Post Types, ACF Taxonomies and ACF Options Pages - are stored as the acf-post-type / acf-taxonomy / acf-ui-options-page post types, all equally hidden from REST [VERIFIED LIVE 2026-08-16: all 404]. The custom post types they CREATE are normal registered types and are discovered by the classifier's wp.data.registered-type rule as usual, so their records are never missed; only the builder definitions are invisible. Options-page values are wp_options rows and are not readable at all."
-  ]
-}

package/skills/wix-replatform/resources/rp-source-wordpress/plugins/back-in-stock-notifier-for-woocommerce.json

@@ -1,81 +0,0 @@
-{
-  "schemaVersion": 1,
-  "plugin": "back-in-stock-notifier-for-woocommerce",
-  "displayName": "Back In Stock Notifier for WooCommerce | WooCommerce Waitlist Pro",
-  "profileVersion": "2026-08",
-  "sourceOfTruth": "https://wordpress.org/plugins/back-in-stock-notifier-for-woocommerce/",
-  "distribution": "wordpress-org",
-  "capabilities": [
-    "commerce.back-in-stock-notifications"
-  ],
-  "detect": {
-    "pluginFileIds": [
-      "back-in-stock-notifier-for-woocommerce/cwginstocknotifier"
-    ],
-    "restNamespaces": [
-      "back-in-stock/v1",
-      "wc-instocknotifier/v3"
-    ],
-    "assetPathSlugs": [
-      "back-in-stock-notifier-for-woocommerce"
-    ]
-  },
-  "entities": [
-    {
-      "entity": "back-in-stock-subscriber",
-      "channel": "plugin-rest",
-      "route": "/wc-instocknotifier/v3/list_subscriber",
-      "recordKeyField": "id",
-      "requestMethod": "POST",
-      "requestBody": {
-        "p_ids": "$SAMPLED_IDS:/wc/v3/products",
-        "status": "cwg_subscribed"
-      },
-      "responseFragmentGroupSize": 4,
-      "candidateTargetRefs": [
-        "stores/back-in-stock-request"
-      ],
-      "pitfalls": [
-        {
-          "code": "two-namespaces-live-simultaneously",
-          "severity": "warning",
-          "summary": "[VERIFIED LIVE 2026-08-19] The installed build (v7.3.3, a paid/CodeCanyon-tier release) advertises BOTH `back-in-stock/v1` (new; only a GET namespace-self-description at `/subscriber` and a POST-only `/subscriber/create` with an undocumented body) AND the legacy `wc-instocknotifier/v3` namespace matching the free wordpress.org v5.6.1 codebase. Use the legacy namespace -- it is the one with a working read path."
-        },
-        {
-          "code": "list-endpoint-is-post-not-get",
-          "severity": "info",
-          "summary": "[VERIFIED LIVE 2026-08-19] The read/list endpoint is `POST /wc-instocknotifier/v3/list_subscriber` with a JSON body, not a GET collection route. This entity declares `requestMethod`/`requestBody` so `wp-discovery.js` samples it automatically like any other candidate -- no `--include-route` override needed, and no plugin-specific sampler code. The `$SAMPLED_IDS:/wc/v3/products` placeholder resolves to the product ids already sampled earlier in the same run; at discovery time this is only the small sample page (schema learning, not bulk extraction) -- `rp-import-codegen` must pass the FULL catalog id list at execution time, not rely on the discovery-time sample."
-        },
-        {
-          "code": "status-any-returns-nothing",
-          "severity": "blocker",
-          "summary": "[VERIFIED LIVE 2026-08-19] Passing `status: \"any\"` in the request body returns an empty array -- WordPress's `any` magic value excludes custom post statuses registered as excluded-from-search, which this plugin's statuses are. Pass the literal status string instead, e.g. `{\"p_ids\": [<all catalog product ids as strings>], \"status\": \"cwg_subscribed\"}`. `p_ids` uses a meta_query `IN` comparison, so an empty or omitted array also returns nothing -- pass the real product id list."
-        },
-        {
-          "code": "response-shape-is-flattened-and-buggy",
-          "severity": "info",
-          "summary": "[VERIFIED LIVE 2026-08-19, matches free v5.6.1 source `includes/class-rest-api.php` format_subscriber_data_schema()] The plugin's own multi-record response is malformed: each subscriber is emitted as 4 SEPARATE single-key array entries (`{id}`, `{last_modified_date}`, `{status}`, `{meta_data}`) in sequence, not one merged object. This entity declares `responseFragmentGroupSize: 4` so `wp-discovery.js` reassembles the flat array back into one record per subscriber automatically -- generically across any entity, no plugin-specific sampler code. Record count = flat array length / 4."
-        },
-        {
-          "code": "storage-is-a-custom-post-type",
-          "severity": "info",
-          "summary": "[DOCUMENTED, free v5.6.1 source `includes/class-api.php`] Each subscriber is a `cwginstocknotifier` custom post (not `show_in_rest`, invisible to `/wp/v2/types`). post_status encodes state: `cwg_subscribed` / `cwg_unsubscribed` / `cwg_doubleoptin` / `cwg_mailsent` / `cwg_mailnotsent` -- only `cwg_subscribed` rows are live/current signups worth importing. Meta keys: `cwginstock_subscriber_email`, `cwginstock_pid` (product-or-variation id used for matching), `cwginstock_product_id`, `cwginstock_variation_id`, `cwginstock_subscriber_name`, `cwginstock_subscriber_phone`, `cwginstock_custom_quantity`, `cwginstock_user_id`, `cwginstock_created_via`."
-        },
-        {
-          "code": "write-endpoint-also-exists-and-was-used-for-seed-data",
-          "severity": "info",
-          "summary": "[VERIFIED LIVE 2026-08-19] `POST /wc-instocknotifier/v3/create_subscriber` accepts and creates real subscriber records. Required fields: `subscriber_name`, `email`, `product_id`, `status`, `subscriber_phone`, `custom_quantity`; optional `variation_id`. Duplicate (email, pid) pairs are rejected 403 by the plugin's own dedup, not a bug to work around."
-        },
-        {
-          "code": "no-admin-csv-export-on-this-site",
-          "severity": "info",
-          "summary": "The plugin ships an admin UI at wp-admin -> Instock Notifier -> All Subscribers, but its one-click CSV export is a SEPARATE paid add-on, not part of the base plugin (checked 2026-08-19) -- do not assume the Discount-Rules-style admin-export escape path is available without checking first."
-        }
-      ]
-    }
-  ],
-  "quirks": [
-    "Vendor: CodeWooGeek (`codewoogeek`). Free tier on wordpress.org tops out at v5.6.1 (namespace `wc-instocknotifier/v3`); the CodeCanyon/paid tier (verified here at v7.3.3) additionally registers a `back-in-stock/v1` namespace but keeps the legacy namespace and its REST controller working unchanged -- confirmed by calling both live against the same install.",
-    "wp-admin menu: **Instock Notifier -> Settings** / **Instock Notifier -> All Subscribers** (left sidebar top-level menu, not under WooCommerce)."
-  ]
-}

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

@@ -1,128 +0,0 @@
-{
-  "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

@@ -1,18 +0,0 @@
-{
-  "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

@@ -1,104 +0,0 @@
-{
-  "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

@@ -1,44 +0,0 @@
-{
-  "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

@@ -1,49 +0,0 @@
-{
-  "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" }
-  }
-}