@wix/agent-skills 1.35.1 → 1.36.1

package/skills/wix-replatform/resources/rp-source-wordpress/plugins/woocommerce-progressive-discounts.json

@@ -1,54 +0,0 @@
-{
-  "schemaVersion": 1,
-  "plugin": "woocommerce-progressive-discounts",
-  "displayName": "Progressive Discounts for WooCommerce",
-  "profileVersion": "2026-08",
-  "sourceOfTruth": "https://woocommerce.com/products/progressive-discounts/",
-  "distribution": "premium-or-unlisted",
-  "capabilities": [
-    "commerce.discount-rules"
-  ],
-  "detect": {
-    "pluginFileIds": [
-      "progressive-discounts/progressive-discounts.php"
-    ]
-  },
-  "entities": [
-    {
-      "entity": "discount-rule-definition",
-      "channel": "admin-page-only",
-      "candidateTargetRefs": ["ecom/discount-rule"],
-      "pitfalls": [
-        {
-          "code": "slug-does-not-match-any-known-distributable-plugin",
-          "severity": "warning",
-          "summary": "The literal slug `woocommerce-progressive-discounts` was checked against wordpress.org, the WordPressPluginDirectory GitHub mirror, and legacy wp-plugins mirrors — none carry it, and an org-scoped repo search for 'progressive-discounts' returned zero results. The nearest real product matching the described use case (quantity-tiered, buy-more-pay-less discounts) is 'Progressive Discounts' by Kestrel (ex-SkyVerge), a paid extension sold exclusively on the WooCommerce.com Marketplace — closed-source, no public mirror, so nothing here is source-verified. `detect.pluginFileIds` is a conventional dir/dir.php guess (`progressive-discounts/progressive-discounts.php`), NOT observed against a real `/wp/v2/plugins` response — treat detection as unreliable until confirmed live. If the actual installed plugin turns out to be a different vendor entirely, re-author this profile against its real identity instead of patching this one.",
-          "unverified": true
-        },
-        {
-          "code": "applied-discount-mechanism-inferred-not-verified",
-          "severity": "warning",
-          "summary": "Vendor documentation states the plugin requires WooCommerce's native coupon system to be enabled, and that the discount appears 'as a specific line item in the cart' reflected in the order summary — read together, this suggests the plugin auto-generates a real WooCommerce coupon under the hood rather than a proprietary meta key, which would mean applied-discount history already rides on the generic, already-covered WooCommerce coupon path (`coupon_lines[]` on `/wc/v3/orders`, via ecom/order-applied-discount's `coupon` one-of variant and stores/coupon) with nothing plugin-specific to profile. This is inferred from marketing/doc language only — no source code was reachable to confirm the actual hook or meta key. Deliberately NOT declared as a second entity or a distinct capability here until verified; if a live run finds a plugin-specific marker instead, add a core-meta entity for it.",
-          "unverified": true
-        },
-        {
-          "code": "admin-page-not-reachable-with-application-password",
-          "severity": "blocker",
-          "summary": "No REST route, CSV export, or other automated read path was found in any reachable documentation for the tier/rule definitions themselves (percent/fixed amount per quantity or subtotal breakpoint, storewide or scoped to products/categories) — per vendor docs they are configured only under a WooCommerce > Progressive Discounts admin screen. Absent contrary evidence, treat this the same as every other admin-page-only settings screen: Application Passwords do not authenticate wp-admin page renders.",
-          "blocked": [
-            {
-              "kind": "user-file",
-              "resolution": "Ask the site owner to open the plugin's settings screen in wp-admin and transcribe or screenshot each discount step (quantity/subtotal breakpoint and its percent or fixed discount), plus whether it is storewide or scoped to specific products/categories.",
-              "declined": false
-            }
-          ]
-        }
-      ]
-    }
-  ],
-  "quirks": [
-    "Authored 2026-08 from WebSearch-summarized vendor documentation only (woocommerce.com/products/progressive-discounts/, woocommerce.com/document/progressive-discounts/) — every field on this profile should be treated as lower-confidence than a source-verified profile (e.g. woo-discount-rules, pricing-deals-for-woocommerce) until a live site or a downloaded copy of the actual plugin is available to check against.",
-    "Same rule-model family as woo-discount-rules and pricing-deals-for-woocommerce (a conditional-pricing engine) but scoped specifically to quantity/subtotal tiers rather than general trigger/effect combinations — worth flagging for consolidation at the mapping review if a site runs more than one of these three.",
-    "Combined with the slug-does-not-match-any-known-distributable-plugin pitfall above, this profile has not been verified against a running installation and should be corrected as soon as one is available."
-  ]
-}

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

@@ -1,158 +0,0 @@
-{
-  "schemaVersion": 1,
-  "plugin": "wordpress-seo",
-  "displayName": "Yoast SEO",
-  "profileVersion": "2026-08",
-  "sourceOfTruth": "https://wordpress.org/plugins/wordpress-seo/",
-  "distribution": "wordpress-org",
-  "capabilities": [
-    "content.seo-meta"
-  ],
-  "detect": {
-    "pluginFileIds": [
-      "wordpress-seo/wp-seo"
-    ],
-    "recordProperties": [
-      "yoast_head_json",
-      "yoast_head",
-      "_yoast_wpseo_title",
-      "_yoast_wpseo_metadesc",
-      "_yoast_wpseo_focuskw"
-    ],
-    "assetPathSlugs": [
-      "wordpress-seo"
-    ]
-  },
-  "entities": [
-    {
-      "entity": "post-seo-meta",
-      "channel": "core-embedded",
-      "embeddedIn": [
-        "/wp/v2/posts"
-      ],
-      "propertyPath": "yoast_head_json",
-      "candidateTargetRefs": [
-        "seo/item-seo-tags",
-        "blog/post"
-      ],
-      "pitfalls": [
-        {
-          "code": "head-json-is-resolved-output-not-the-override",
-          "severity": "blocker",
-          "summary": "yoast_head_json is Yoast's RENDERED output for the record, not the values the author typed. Every key is populated for every post whether or not anyone edited its SEO: `title` falls back to the site title template, `og_description` falls back to the excerpt/content, `og_title` mirrors the title. [VERIFIED LIVE 2026-08-16: every sampled post returned a fully populated yoast_head_json while every one had EMPTY _yoast_wpseo_title and _yoast_wpseo_metadesc, i.e. zero genuine per-post overrides.] Importing it wholesale into Wix Item SEO Tags converts inherited/templated values into hard per-item overrides on every record - the exact anti-pattern the Wix SEO docs warn about. Pair it with the post-seo-override-signal entity and import per-item tags only where the source proves an override."
-        },
-        {
-          "code": "head-json-key-set-varies-by-record",
-          "severity": "warning",
-          "summary": "Keys are present only when Yoast emits them, so absence is normal and is not profile drift. [VERIFIED LIVE 2026-08-16: across sampled posts the constant keys were title, robots, og_locale, og_type, og_title, og_description, og_url, og_site_name, article_published_time, author, twitter_card, twitter_misc, schema; on pages og_description and twitter_misc appeared only on some records; on wc/v3 products og_image and article_modified_time appeared on most and twitter_misc on a minority.] Notably ABSENT on a noindex site with no meta descriptions: `canonical` and `description` - `description` because no post has a meta description, and `canonical` because the whole site is noindex (blog_public = 0), which makes Yoast drop the canonical presenter. On a production source both normally appear. [NEEDS-VERIFICATION on an indexed production site: the exact shape of `canonical` and `description`.]"
-        },
-        {
-          "code": "robots-noindex-is-a-source-artefact",
-          "severity": "blocker",
-          "summary": "[VERIFIED LIVE 2026-08-16] on a WordPress site that discourages search engines every record reports robots {index: noindex, follow: follow, ...}. Carrying a robots meta tag across without checking would de-index the new Wix site. Indexability is a launch decision (see seo/site-seo-tags pitfall site-noindex-is-writable-here), never a migrated field."
-        },
-        {
-          "code": "schema-graph-is-source-shaped",
-          "severity": "warning",
-          "summary": "yoast_head_json.schema is a full JSON-LD @graph whose @id values are absolute SOURCE URLs (https://<source-host>/... plus #article, #primaryimage, #/schema/person/<hash> fragments) and whose image URLs point at the source CDN. Copying it into a Wix script tag republishes structured data that references the old domain. Either drop it (Wix generates its own structured data) or rewrite every @id and URL through the URL/media crosswalks - never pass it through verbatim."
-        }
-      ]
-    },
-    {
-      "entity": "post-seo-override-signal",
-      "channel": "core-meta",
-      "embeddedIn": [
-        "/wp/v2/posts"
-      ],
-      "propertyPath": "_yoast_wpseo_title",
-      "context": "view",
-      "candidateTargetRefs": [
-        "seo/item-seo-tags"
-      ],
-      "pitfalls": [
-        {
-          "code": "three-registered-keys-only-and-auth-gated",
-          "severity": "warning",
-          "summary": "Yoast registers exactly three meta keys into the REST `meta` object - _yoast_wpseo_title, _yoast_wpseo_metadesc, _yoast_wpseo_focuskw - and they are visible only to an authenticated caller. [VERIFIED LIVE 2026-08-16 on a /wp/v2/posts record: the authenticated response carried those three keys and the unauthenticated response carried none of them, with all other meta keys identical.] This entity's propertyPath names the title key; the other two travel with it and must be read from the same `meta` object. An unauthenticated run therefore cannot tell an override from a default and must fall back to post-seo-meta alone, recorded as reduced fidelity rather than as absent data."
-        },
-        {
-          "code": "registered-only-for-post-not-page-or-product",
-          "severity": "warning",
-          "summary": "[VERIFIED LIVE 2026-08-16] the three keys appeared on every sampled /wp/v2/posts record but on NONE of the sampled /wp/v2/pages records and none of /wp/v2/product (authenticated in every case). So the override signal exists for blog posts only; for pages, products and CPTs there is no REST-visible way to distinguish a genuine Yoast override from Yoast's computed default. [NEEDS-VERIFICATION: whether this is a Yoast registration scope per post type or a host/config effect.]"
-        },
-        {
-          "code": "canonical-and-social-overrides-are-not-registered",
-          "severity": "warning",
-          "summary": "The per-post canonical override (_yoast_wpseo_canonical) and the Open Graph / Twitter overrides (_yoast_wpseo_opengraph-title, -description, -image, _yoast_wpseo_twitter-title, ...) are NOT among the registered keys and never appear in `meta`. [VERIFIED LIVE 2026-08-16: only the three keys above were present.] Their VALUES are still readable, because Yoast folds them into yoast_head_json - but there is no REST-visible way to tell an authored canonical from Yoast's computed one. Migrating a computed canonical would point the new Wix page at the old domain, so a canonical is only safe to carry after it is rewritten through the URL ledger or dropped in favour of Wix's own."
-        }
-      ]
-    },
-    {
-      "entity": "product-seo-meta",
-      "channel": "core-embedded",
-      "embeddedIn": [
-        "/wc/v3/products"
-      ],
-      "propertyPath": "yoast_head_json",
-      "candidateTargetRefs": [
-        "seo/item-seo-tags",
-        "stores/product"
-      ],
-      "pitfalls": [
-        {
-          "code": "woo-products-need-auth-for-any-read",
-          "severity": "warning",
-          "summary": "[VERIFIED LIVE 2026-08-16] yoast_head_json rides on /wc/v3/products (present on every sampled product), but /wc/v3/products itself returns 401 woocommerce_rest_cannot_view unauthenticated, so the whole entity is unreadable without the Application Password. The same product's SEO is ALSO reachable unauthenticated on /wp/v2/product, which can be public and carries yoast_head_json too - a useful fallback for an unauthenticated survey, though it exposes no Woo commerce fields."
-        },
-        {
-          "code": "no-yoast-keys-in-woo-meta-data",
-          "severity": "info",
-          "summary": "[VERIFIED LIVE 2026-08-16] no _yoast_* key appeared in the meta_data array of any sampled product, and the three registered keys were absent from /wp/v2/product meta. The raw override meta can still exist in postmeta when REST shows none (read outside ordinary REST), and a rendered yoast_head_json.title can be present on every product while no raw title override exists. Read it per field through lib/yoast-product-seo-evidence.js: REST meta when it carries the key, else a wix-wp-plugin-v2 key-scoped postmeta read of exactly the three keys. When neither is available the evidence is unknown and product SEO is held for an owner decision."
-        },
-        {
-          "code": "prefer-seodata-on-the-product-create",
-          "severity": "info",
-          "summary": "Catalog V3 products carry their own `seoData` (SeoSchema: tags[] plus settings.preventAutoRedirect) on create/update, so product SEO rides the product import. That is the ONLY product write path; never route Stores products through the generic Item SEO bulk writer (2026-08-27: per-entry success, nothing persisted), and write only proven per-field overrides."
-        },
-        {
-          "code": "rendered-product-seo-is-not-an-override",
-          "severity": "blocker",
-          "summary": "Product yoast_head_json.title/description are rendered template output unless the raw override meta proves otherwise, field by field. A nonblank raw title authorizes only the title and a nonblank raw description only the description; the value then comes from the matching resolved yoast_head_json field (the raw value may hold %%variables%%). og_description, og_title and excerpt text are never a fallback. Unknown evidence is held for the owner (acquire evidence, omit, or materialize); no default is chosen. Canonical, robots, schema, social tags and focus keyphrases are not written."
-        }
-      ]
-    },
-    {
-      "entity": "term-seo-meta",
-      "channel": "core-embedded",
-      "embeddedIn": [
-        "/wp/v2/categories",
-        "/wp/v2/tags",
-        "/wc/v3/products/categories"
-      ],
-      "propertyPath": "yoast_head_json",
-      "candidateTargetRefs": [],
-      "pitfalls": [
-        {
-          "code": "no-verified-wix-item-type-for-terms",
-          "severity": "warning",
-          "summary": "[VERIFIED LIVE 2026-08-16] taxonomy terms carry yoast_head_json too - present on every sampled /wp/v2/categories and /wc/v3/products/categories record - so archive-page SEO is real, readable source data. But Wix Item SEO Tags documents item types by example only (STATIC_PAGE, BLOG_POST, STORES_PRODUCT, WIX_DATA_PAGE_ITEM-{pageId}) and says the real list is per site, discoverable from the UNSUPPORTED_ITEM_TYPE error message. No item type for a blog category, blog tag or store category has been confirmed, and neither blog/category nor stores/category exposes a seoData field. candidateTargetRefs is deliberately empty rather than pointing at a target that may reject the write: probe the supported item types at setup and resolve this at the mapping review."
-        },
-        {
-          "code": "wp-users-also-carry-it",
-          "severity": "info",
-          "summary": "[VERIFIED LIVE 2026-08-16] /wp/v2/users records carry yoast_head_json as well (author-archive SEO, on every sampled user). Author archives have no Wix counterpart at all, so this is noted for completeness and is not proposed for migration."
-        }
-      ]
-    }
-  ],
-  "quirks": [
-    "Plugin file id is `wordpress-seo/wp-seo` - the main-file basename differs from the directory and the /wp/v2/plugins id carries no .php suffix [VERIFIED LIVE 2026-08-16 active, version 28.2, textdomain wordpress-seo]. Never construct dir/dir.php.",
-    "Storage model: BOTH resolved-output-on-the-record and registered meta, and they answer different questions. The values are read as `yoast_head_json` injected into core and WooCommerce REST records (channel core-embedded); whether a value was actually authored is read from three registered meta keys (channel core-meta). Unregistered Yoast meta - the canonical and Open Graph/Twitter overrides - is invisible to REST as raw meta but is folded into yoast_head_json, so nothing is lost, only the provenance. [VERIFIED LIVE 2026-08-16.]",
-    "core-embedded VERIFICATION - this profile is the first user of the channel and it is now confirmed against a live site. [VERIFIED LIVE 2026-08-16] yoast_head_json is a top-level key on every sampled record of: /wp/v2/posts, /wp/v2/pages, /wp/v2/product, /wp/v2/podcast, /wp/v2/tribe_events, /wp/v2/categories, /wp/v2/users, /wc/v3/products, /wc/v3/products/categories. It is present with and without authentication and in context=edit, identically. It is ABSENT on /wp/v2/media - attachments get no Yoast head. So the channel's probe (declared key present in a sampled record) fires from an ordinary unauthenticated sample and needs no special context.",
-    "`yoast/v1` is DELIBERATELY NOT declared in detect.restNamespaces, even though the namespace is real and public. Two reasons. (1) It buys nothing: an authenticated run already matches pluginFileIds against /wp/v2/plugins, and an unauthenticated run that samples any record sees `yoast_head_json`, which is a stronger signal because it proves the SEO data is actually there. (2) Claiming the namespace would suppress the fingerprinted tier for Yoast - `yoast` is the alias map's canonical entry (fingerprint-aliases.json: yoast -> Yoast SEO / wordpress-seo), and the public URL-scan funnel depends on an unauthenticated, unsampled run still naming Yoast from the namespace alone. A profile claiming the namespace turns that row off. If this profile ever needs the namespace as a signal, the fingerprint alias and its contract tests have to be reconsidered in the same change.",
-    "Registers dozens of REST routes under /yoast/v1 and NOT ONE of them is a data collection [VERIFIED LIVE 2026-08-16, identical authenticated and unauthenticated]: they are AI generation (ai_generator/*, ai_content_planner/*), indexing jobs (indexing/*, link-indexing/*), setup wizard state (configuration/*), dashboards (statistics, seo_scores, readability_scores, time_based_seo_metrics, workouts), integrations (semrush/*, wincher/*, site_kit_*) and UI dismissals. This is the live evidence behind the rule that `/yoast/*` must never be opened wholesale, and behind the classifier's existing wp.integration.yoast exclusion - the per-record SEO data does not live there, it rides the core records. The one route that might tempt an author, /yoast/v1/get_head, is a URL-to-head helper, not a collection.",
-    "Yoast's head can be NOT visible in the rendered front-end HTML [VERIFIED LIVE 2026-08-16]: the homepage and a post permalink both contained no `Yoast SEO plugin` comments, no og: meta tags, and no wp-content/plugins/wordpress-seo asset path - a host caching layer served a head without them, while the REST yoast_head / yoast_head_json fields are fully populated. Two consequences: assetPathSlugs will not fire for Yoast on such a host (so the fingerprinted tier cannot see it), and a public HTML scrape is not a substitute for the REST read.",
-    "Plugin CONFIGURATION is not data. Yoast's sitemap settings (Wix generates its own sitemap), its per-post-type title/description templates, breadcrumbs, social profile URLs and knowledge-graph organisation data all live in the wpseo_* wp_options rows, which WordPress REST does not expose at all. They are reconfigure-in-wix; the templates have a real Wix home if the user supplies them (seo/seo-pattern), and the search-engine verification tags have one too (seo/site-seo-tags).",
-    "Redirects are a Yoast Premium feature; determine whether source redirect data exists from the active source inventory. Other redirect plugins may hold independent maps. Wix publicly documents the SEO Redirects API in Developer Preview, but this migration capability remains pending until extraction, safe application and frontend verification are integrated (seo/domain.json pitfall url-redirect-api-not-yet-integrated)."
-  ]
-}

package/skills/wix-replatform/resources/rp-source-wordpress/plugins/wpc-composite-products.json

@@ -1,97 +0,0 @@
-{
-  "schemaVersion": 1,
-  "plugin": "wpc-composite-products",
-  "displayName": "WPC Composite Products for WooCommerce",
-  "profileVersion": "2026-08",
-  "sourceOfTruth": "https://wordpress.org/plugins/wpc-composite-products/",
-  "distribution": "wordpress-org",
-  "capabilities": [
-    "commerce.composite-products"
-  ],
-  "detect": {
-    "pluginFileIds": [
-      "wpc-composite-products/wpc-composite-products"
-    ],
-    "recordProperties": [
-      "wooco_components",
-      "wooco_ids",
-      "wooco_parent_id"
-    ],
-    "assetPathSlugs": [
-      "wpc-composite-products"
-    ]
-  },
-  "entities": [
-    {
-      "entity": "composite-definition",
-      "channel": "core-meta",
-      "embeddedIn": ["/wc/v3/products"],
-      "propertyPath": "wooco_components",
-      "candidateTargetRefs": [],
-      "pitfalls": [
-        {
-          "code": "no-wix-target-decided",
-          "severity": "warning",
-          "summary": "A WPC composite is a WooCommerce product of custom type `composite` whose component definition rides in unregistered product meta `wooco_components` inside the wc/v3/products meta_data array. The composite product itself (name, price, media, SEO) 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 [VERIFIED LIVE 2026-08-16 against dev.wix.com catalog-v3/products-v3/product-object.md: `productType` enum reads exactly `PHYSICAL, DIGITAL`; the nearest structural fields are `options`/`modifiers` (variant-generating customizations, not references to other products) and `purchaseEligibility.userCriteria: MEMBERS_ONLY`]. See capabilities-pending-decision.json: this is NOT automatically covered by the signed commerce.product-bundles verdict — see the composite-is-not-a-fixed-bundle pitfall — and needs its own human co-signature."
-        },
-        {
-          "code": "composite-is-not-a-fixed-bundle",
-          "severity": "warning",
-          "summary": "Semantically distinct from the sibling woo-product-bundle profile, and the distinction changes which Wix surface is the closest fit. A woosb bundle is a FIXED composition (a set list of child products at set quantities). A `composite` is a CUSTOMER-ASSEMBLED kit: the product defines component groups (a group can be sourced from an explicit product list, or from whole categories/tags via `categories`/`tags`/`other` with `exclude`), each with min/max quantities and an `optional` flag, and the buyer picks one product per group at purchase time [VERIFIED IN PLUGIN SOURCE v8.0.0, includes/class-backend.php component panel fields + includes/class-wooco.php add-to-cart validation, 2026-08-16]. The requires-development.json entry for commerce.product-bundles rejected Wix's mix-and-match precisely because it is 'a category + automatic-discount pattern for customer-assembled combos' with no fixed-bundle SKU — which is the shape a composite actually has. That makes mix-and-match a nearer (though still config-only, non-API) parallel for composites than it was for bundles, so the bundles verdict must not be extended here by inference. A human decides."
-        },
-        {
-          "code": "components-referenced-by-source-id",
-          "severity": "warning",
-          "summary": "`wooco_components` is an associative array keyed by a generated component key; each component carries `name`, `desc`, `type`, `products[]` (WooCommerce product ids), `exclude[]`, `categories[]`, `tags[]` (term ids), `default`, `optional`, `price`, `qty`, `custom_qty`, `min`, `max`, `m_min`, `m_max`, `multiple`, `selector`, `orderby`, `order`, `other` [VERIFIED IN PLUGIN SOURCE v8.0.0, includes/class-backend.php `wooco_components[<key>][<field>]` panel inputs and the `$component['<field>']` reads across includes/, 2026-08-16]. Every product id and term id is a WooCommerce id: any import must remap them through the product and category crosswalks AFTER the referenced products and categories are created. Unlike woosb_ids there is no cached SKU to fall back on, so an unresolved id is an unrecoverable reference, not a soft match."
-        },
-        {
-          "code": "derived-composite-price",
-          "severity": "warning",
-          "summary": "The displayed price is derived at runtime from the buyer's selections plus the composite's own pricing mode (`wooco_pricing`, with `wooco_discount_percent` and `wooco_custom_price`) rather than being a single stored sale price [VERIFIED IN PLUGIN SOURCE v8.0.0, includes/class-product.php get_pricing/get_price and includes/class-wooco.php cart price handling, 2026-08-16]. Migrating the composite as a static stores/product therefore freezes a price that never was a fixed price to begin with — a sharper fidelity loss than the bundle case. Whatever wc/v3/products reports in `price`/`regular_price` at migration time is what carries over; the selection-dependent pricing does not."
-        },
-        {
-          "code": "settings-meta-siblings",
-          "severity": "info",
-          "summary": "Sibling per-composite meta written by the same save handler [VERIFIED IN PLUGIN SOURCE v8.0.0, includes/class-backend.php process_meta_composite, 2026-08-16]: wooco_pricing, wooco_discount_percent, wooco_qty_min, wooco_qty_max, wooco_total_limits (on/off) + wooco_total_limits_min/max, wooco_same_products, wooco_shipping_fee, wooco_custom_price, wooco_before_text, wooco_after_text, wooco_component_layout. Only wooco_components is durable composition data; the rest are pricing/display/behaviour settings (reconfigure-or-drop, decided at mapping review)."
-        }
-      ]
-    },
-    {
-      "entity": "order-item-composite-linkage",
-      "channel": "core-meta",
-      "embeddedIn": ["/wc/v3/orders"],
-      "propertyPath": "wooco_ids",
-      "candidateTargetRefs": [],
-      "pitfalls": [
-        {
-          "code": "no-wix-target-decided",
-          "severity": "warning",
-          "summary": "Historical orders record what the buyer actually assembled, on the line items: the composite's own line item carries `wooco_ids` and `wooco_price`, and each selected child line item carries `wooco_parent_id`, `wooco_qty`, and `wooco_component` (the component name it was chosen for) [VERIFIED IN PLUGIN SOURCE v8.0.0, includes/class-wooco.php add_order_item_meta hooked on woocommerce_checkout_create_order_line_item, plus includes/class-backend.php hidden_order_itemmeta which also lists wooco_pos, 2026-08-16]. Child items are real WooCommerce line items, so an order import that copies line items loses nothing sellable — only the parent/child grouping and the which-component-was-this-chosen-for label. No Wix eCom order-line-item field for that grouping has been verified; until one is, the linkage is candidate CMS/ledger data, not silently dropped."
-        },
-        {
-          "code": "parent-id-is-a-product-id-not-a-line-id",
-          "severity": "warning",
-          "summary": "TRAP, and it differs from the sibling bundle plugin. `wooco_parent_id` on a child line item holds the composite PRODUCT id, not the parent line item's id and not its cart key: the cart writes `'wooco_parent_id' => $product_id` where $product_id is the composite being added, and the display code round-trips it through wc_get_product()/get_permalink() [VERIFIED IN PLUGIN SOURCE v8.0.0, includes/class-wooco.php add_to_cart_items() and the cart/order item-name filters, 2026-08-16]. The cart-item key does exist as `wooco_key` / `wooco_parent_key` but is NEVER copied to order item meta (add_order_item_meta writes only wooco_parent_id, wooco_qty, wooco_ids, wooco_price, wooco_component). Consequence: if one order contains the SAME composite product twice with different selections, the child lines cannot be attributed to the right parent line by wooco_parent_id alone — disambiguate by pairing each parent line's parsed wooco_ids against the child lines, and ledger the case as ambiguous when that pairing is not unique."
-        },
-        {
-          "code": "wooco-ids-is-a-packed-string",
-          "severity": "info",
-          "summary": "`wooco_ids` is not JSON: it is a comma-separated list of `id/qty/componentKey` triples, parsed by exploding on ',' then '/' [VERIFIED IN PLUGIN SOURCE v8.0.0, includes/class-helper.php get_items(), 2026-08-16 — `id` = absint, `qty` = float, `key` = sanitize_key]. Sanitization (clean_ids) permits only [,.%/0-9a-zA-Z], so component keys are alphanumeric. A reader must parse the string; treating it as an id list will silently drop quantities."
-        },
-        {
-          "code": "sampling-may-miss-linkage",
-          "severity": "info",
-          "summary": "This meta appears only on orders that contain a composite. A small order sample from a store with few composite sales can legitimately lack the key, which detection then reports as property-absent (blocked: surface-changed) — that reads as profile drift but may simply mean no sampled order had a composite. [NEEDS-VERIFICATION live: no composite product or wooco_* line-item meta has been observed yet.]"
-        }
-      ]
-    }
-  ],
-  "quirks": [
-    "Plugin file id is `wpc-composite-products/wpc-composite-products` — directory and main-file basename happen to match here, unlike the sibling woo-product-bundle/wpc-product-bundles, and the /wp/v2/plugins id carries no .php suffix [VERIFIED LIVE 2026-08-16: plugin active, version 8.0.0, textdomain wpc-composite-products]. Never construct dir/dir.php and assume.",
-    "THE PRODUCT TYPE SLUG IS `composite`, NOT `wooco`. The `wooco_` prefix names the plugin's meta keys, hooks, and assets, but the WooCommerce product type registered in the type selector is the literal string `composite`, backed by class WC_Product_Composite whose get_type() returns 'composite' [VERIFIED IN PLUGIN SOURCE v8.0.0, includes/class-backend.php product_type_selector() → $types['composite'] = 'Smart composite', and includes/class-product.php; the same slug is present in v7.8.9, so this is not a v8 rename — VERIFIED IN PLUGIN SOURCE v7.8.9, 2026-08-16]. Anything keyed on a `wooco` product type will match zero products. [NEEDS-VERIFICATION] whether releases older than 7.8.9 used a different slug — WPClever's wordpress.org tag list no longer serves 6.x, so pre-7.x sites are unchecked.",
-    "THE TYPE IS INVISIBLE TO THE wc/v3 `?type=` FILTER, and this is a plugin bug-shaped behaviour worth planning around, not drift. `product_type_selector` is registered inside class-backend.php, which the bootstrap instantiates only under `is_admin()` [VERIFIED IN PLUGIN SOURCE v8.0.0, wpc-composite-products.php wooco_init(): `if ( is_admin() ) { WPCleverWooco_Backend(); }`], so wc_get_product_types() in a REST request never learns about it. [VERIFIED LIVE 2026-08-16] with the plugin ACTIVE, `GET /wc/v3/products?type=__nope__` returns the enum 'simple, grouped, external, variable, woosb, and pw-gift-card' — woosb and pw-gift-card are present, `composite` is absent — so `?type=composite` is rejected with rest_invalid_param (400) rather than returning composites. Consequence for discovery: composites cannot be filtered server-side; they must be found by scanning /wc/v3/products and matching `type == \"composite\"` or the presence of the `wooco_components` meta key. Do not read a 400 here as 'the plugin is not installed'.",
-    "Registers no REST namespace, no route, and no custom post type: /wp-json advertises no wpclever/wooco/composite namespace among its namespaces, and the authed /wp/v2/types lists no composite type [VERIFIED LIVE 2026-08-16]. Detection therefore rests entirely on the plugin id (authed), the asset path (no-auth — GET /wp-content/plugins/wpc-composite-products/assets/css/frontend.css returned 200 [VERIFIED LIVE 2026-08-16]), and the wooco_* record properties.",
-    "Storage model: unregistered WooCommerce post meta — the plugin calls no register_post_meta / register_meta / show_in_rest / register_rest_route / register_post_type / register_taxonomy anywhere [VERIFIED IN PLUGIN SOURCE v8.0.0, grep across includes/, 2026-08-16] — but WooCommerce surfaces non-internal product meta in the wc/v3/products meta_data array and non-internal order-item meta in wc/v3/orders line_items[].meta_data regardless of registration, so both the composition and the order linkage are REST-visible via the authenticated Woo API, not via /wp/v2. The order-item half of that mechanism is live-proven: a custom underscore-prefixed key (`_reduced_stock`) and attribute keys (`pa_size`, `pa_color`, `pa_scent`, `pa_pack-size`) do appear in line_items[].meta_data [VERIFIED LIVE 2026-08-16]. [NEEDS-VERIFICATION on a real composite payload: no composite product has been read live (a product scan found no product of type 'composite' and no wooco_* meta key), so the exact meta_data value shapes are source-verified but not network-verified.]",
-    "Do not conflate with WooCommerce's own premium 'Composite Products' extension (slug woocommerce-composite-products), which uses the `composite` product type as well but exposes a documented `composite_data` / `composite_layout` structure and its own admin model. This WPC plugin's signal is the `wooco_components` meta key plus the wooco_* order-item meta; a site could in principle run either, and the type value alone does not tell them apart [DOCUMENTED — models compared 2026-08-16]. The same caution the sibling profile records for woosb vs. the official Product Bundles applies here."
-  ]
-}

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

@@ -1,86 +0,0 @@
-{
-  "schemaVersion": 1,
-  "plugin": "wpforms-lite",
-  "displayName": "WPForms Lite",
-  "profileVersion": "2026-08",
-  "sourceOfTruth": "https://wpforms.com/docs/how-to-export-and-import-wpforms/",
-  "distribution": "wordpress-org",
-  "capabilities": [
-    "content.form-definitions"
-  ],
-  "detect": {
-    "pluginFileIds": [
-      "wpforms-lite/wpforms"
-    ],
-    "routes": [
-      "/wpforms/v1/setup-wizard/hydrate"
-    ],
-    "restNamespaces": [
-      "wpforms/v1"
-    ],
-    "assetPathSlugs": [
-      "wpforms-lite"
-    ]
-  },
-  "entities": [
-    {
-      "entity": "form-definition",
-      "channel": "export-file",
-      "candidateTargetRefs": [
-        "forms/form"
-      ],
-      "pitfalls": [
-        {
-          "code": "no-rest-channel-at-all",
-          "severity": "blocker",
-          "summary": "[VERIFIED LIVE 2026-08-16] WPForms form definitions cannot be read over REST. The `wpforms` CPT is absent from /wp/v2/types even with an administrator application password and GET /wp/v2/wpforms returns 404; [DOCUMENTED, source 2.0.0.4 includes/class-form.php register_cpt()] the CPT registers with public=false, show_ui=false and NO `show_in_rest` key, which defaults to false. The `wpforms/v1` namespace that DOES appear in the REST index carries only setup-wizard routes (hydrate, update, install-plugins, complete, stripe/connect-url, license/key, license/verify) — installer plumbing, no form data. So this plugin is detectable without credentials but not readable over any REST channel, at any auth level."
-        },
-        {
-          "code": "wxr-export-does-not-carry-forms",
-          "severity": "blocker",
-          "summary": "[DOCUMENTED, source 2.0.0.4 includes/class-form.php] The CPT sets `'can_export' => false`, so WordPress's own WXR exporter SKIPS WPForms forms entirely. The usual credential-free fallback — ask the operator for a WXR export — silently yields zero forms here rather than failing loudly. This is the single most important fact in this profile: an operator who hands over a full site export in good faith has handed over nothing for this plugin, and nothing in the export says so."
-        },
-        {
-          "code": "use-the-plugins-own-json-export",
-          "severity": "warning",
-          "summary": "[DOCUMENTED, source 2.0.0.4 src/Admin/Tools/Export/Views/Forms/Page.php] The one operator-supplied channel that works is WPForms' OWN exporter: WP Admin → WPForms → Tools → Export → Forms, which downloads `wpforms-form-export-MM-DD-YYYY.json`. It is nonce-guarded and admin-only, so it cannot be fetched by the adapter — it must be requested from the operator as a file, which is why this entity's channel is export-file. Ask for it explicitly during discovery whenever wpforms-lite is detected; the operator will not think to offer it, because every other plugin's data rides along in the WXR."
-        },
-        {
-          "code": "field-choices-are-ordinal-keyed",
-          "severity": "warning",
-          "summary": "[NEEDS-VERIFICATION — not yet read from a real export] WPForms stores a form as a serialized settings blob keyed by numeric field id, with choices keyed by ordinal rather than by a stable slug. forms/form needs a stable `target` per field and a lowercase GUID id per choice option, so codegen must MINT both and record the source-ordinal -> minted-id map in the crosswalk. Confirm the exact shape against a real wpforms-form-export JSON before writing the mapper; nothing in this profile was read from an export file."
-        }
-      ]
-    },
-    {
-      "entity": "entry",
-      "channel": "db-only",
-      "candidateTargetRefs": [
-        "forms/form-submission"
-      ],
-      "pitfalls": [
-        {
-          "code": "lite-stores-no-entries",
-          "severity": "blocker",
-          "summary": "[DOCUMENTED, source 2.0.0.4 — read end to end 2026-08-16] The Lite tier does not store submissions AT ALL. There is no entries table: src/Db/ contains only Analytics and Payments, and the Lite code says so in its own words — 'Lite owns no aggregate metric tables, so it cannot rank by entries and returns an empty list. Pro overrides this against `wp_wpforms_entries`' (src/Integrations/AI/Admin/Chat/Scope/FormsInventory/FormSearcher.php). The ONLY thing Lite persists per submission is a COUNTER: lite/wpforms-lite.php increments the `wpforms_entries_count` post meta on the form's own post (add_post_meta(..., 1) then a direct `UPDATE ... SET meta_value = meta_value + 1`). The Entries admin screen in Lite renders sample data behind an 'Upgrade to Pro to get access to Entries' notice (lite/templates/admin/entries/notice.php). So on a Lite site there is nothing to migrate here — not 'hard to reach', genuinely absent. Report the per-form counter to the operator as the honest measure of what was lost: it is the exact number of submissions that existed and cannot be recovered from this plugin."
-        },
-        {
-          "code": "pro-entries-are-db-only",
-          "severity": "warning",
-          "summary": "[DOCUMENTED, source 2.0.0.4] If the site is later found to run WPForms PRO (a different plugin id, `wpforms/wpforms`), entries DO exist in the custom table `wp_wpforms_entries` with no REST route and no WXR coverage — db-only, out of current scope. That is a separate profile with a separate slug, not a widening of this one. Pro also ships an entries CSV export (in Lite the ExportEntries class lives under src/Admin/Education/, WPForms' upsell namespace, which is itself the confirmation that Lite has none)."
-        }
-      ]
-    }
-  ],
-  "excludeRoutes": [
-    {
-      "route": "/wpforms/v1/setup-wizard/*",
-      "reason": "installer plumbing (hydrate, update, install-plugins, complete, stripe/connect-url, license/key, license/verify) — configuration and license actions, no durable business data. Several are state-changing; kept out of scope so the namespace can never be opted in wholesale."
-    }
-  ],
-  "quirks": [
-    "[VERIFIED LIVE 2026-08-16] Plugin file id `wpforms-lite/wpforms`, version 2.0.0.4, active. Directory and main-file basename differ (`wpforms-lite` vs `wpforms`), so the id must be read from GET /wp/v2/plugins, never constructed.",
-    "The `wpforms/v1` namespace is registered by BOTH tiers, so it identifies WPForms rather than specifically Lite. Tier is decided by the plugin file id: `wpforms-lite/wpforms` (this profile) vs `wpforms/wpforms` (Pro, no profile yet). Detection that leans only on the namespace will label a Pro site as Lite and wrongly report its entries as non-existent — the pluginFileIds signal is what keeps this honest, which is why it is listed first.",
-    "This profile claims the same capability string as contact-form-7 — `content.form-definitions` — by design: one business capability, many source plugins, one Wix target (forms/form). Neither profile claims `content.form-submissions`, and for different reasons: CF7 never stores submissions (Flamingo does, and needs its own profile), while WPForms Lite genuinely has none to store. That capability is already claimed on the Wix side by forms/form-submission, so it is not a pending-register item — it is waiting on source-side reachability, not on a Wix target."
-  ]
-}

package/skills/wix-replatform/resources/rp-source-wordpress/scripts/capture-store-settings.js

@@ -1,90 +0,0 @@
-#!/usr/bin/env node
-'use strict';
-
-// Captures the source store's OWN configuration — business address, currency, which countries
-// it sells to, whether tax is calculated — into the run's data directory.
-//
-//   node capture-store-settings.js <projectDir>
-//   -> <projectDir>/data/store-settings-general.json
-//
-// WHY THIS IS A SCRIPT AND NOT A DISCOVERY RULE. Two independent reasons the generic sweep
-// can never reach this route, each of which looks like a dead end on its own:
-//
-//   1. The REST index advertises only the PARAMETERIZED form `/wc/v3/settings/(?P<group>...)`,
-//      never the literal group route. Nothing in the generic sweep resolves a route template
-//      into its concrete groups, so `/wc/v3/settings/general` is never a candidate. Same shape
-//      as a shipping zone's /locations and /methods sub-resources: parent-scoped, read directly.
-//
-//   2. The WooCommerce consumer key returns 401 `woocommerce_rest_cannot_view` here, while the
-//      WordPress application password returns 200. A reader that tries only the store key gets
-//      a plausible "no permission" and moves on.
-//
-// Together those two are why this route was never sampled on any run, and why every migrated
-// site published with an empty business address without anyone noticing. The fix has to be a
-// deliberate step, not a classifier tweak — hence this file.
-//
-// Reads WP_BASE_URL, WP_USERNAME and WP_APPLICATION_PASSWORD from
-// <projectDir>/config/source.woocommerce.env. Never prints the credential.
-
-const fs = require('node:fs');
-const path = require('node:path');
-
-const GROUP = 'general';
-const ROUTE = `/wp-json/wc/v3/settings/${GROUP}`;
-const OUTPUT_NAME = 'store-settings-general.json';
-
-function readEnvFile(filePath) {
-  const env = {};
-  for (const line of fs.readFileSync(filePath, 'utf8').split('\n')) {
-    const trimmed = line.trim();
-    if (!trimmed || trimmed.startsWith('#')) continue;
-    const eq = trimmed.indexOf('=');
-    if (eq < 1) continue;
-    env[trimmed.slice(0, eq).trim()] = trimmed.slice(eq + 1).trim();
-  }
-  return env;
-}
-
-async function captureStoreSettings(projectDir) {
-  const configPath = path.join(projectDir, 'config', 'source.woocommerce.env');
-  if (!fs.existsSync(configPath)) {
-    throw new Error(`capture-store-settings: source config not found at ${configPath}`);
-  }
-  const env = readEnvFile(configPath);
-  for (const key of ['WP_BASE_URL', 'WP_USERNAME', 'WP_APPLICATION_PASSWORD']) {
-    if (!env[key]) {
-      throw new Error(`capture-store-settings: ${key} is missing from ${configPath} — the store consumer key cannot read this route, only the WordPress application password can`);
-    }
-  }
-
-  const base = env.WP_BASE_URL.replace(/\/+$/, '');
-  const auth = `Basic ${Buffer.from(`${env.WP_USERNAME}:${env.WP_APPLICATION_PASSWORD}`).toString('base64')}`;
-  const response = await fetch(base + ROUTE, { headers: { Authorization: auth } });
-  const body = await response.json().catch(() => null);
-
-  if (!response.ok || !Array.isArray(body)) {
-    const code = body && body.code ? ` (${body.code})` : '';
-    throw new Error(`capture-store-settings: GET ${ROUTE} returned ${response.status}${code}. If this is a 401, the run is using the WooCommerce consumer key — this route needs the WordPress application password.`);
-  }
-
-  const outputDir = path.join(projectDir, 'data');
-  fs.mkdirSync(outputDir, { recursive: true });
-  const outputPath = path.join(outputDir, OUTPUT_NAME);
-  fs.writeFileSync(outputPath, `${JSON.stringify(body, null, 2)}\n`);
-  return { outputPath, count: body.length, settings: body };
-}
-
-async function main() {
-  const projectDir = path.resolve(process.argv[2] || process.cwd());
-  const { outputPath, count } = await captureStoreSettings(projectDir);
-  process.stdout.write(`captured ${count} store settings -> ${outputPath}\n`);
-}
-
-if (require.main === module) {
-  main().catch((error) => {
-    process.stderr.write(`${error.message}\n`);
-    process.exit(1);
-  });
-}
-
-module.exports = { captureStoreSettings, GROUP, ROUTE, OUTPUT_NAME };

package/skills/wix-replatform/resources/rp-source-wordpress/scripts/plugin-knowledge-validate.js

@@ -1,51 +0,0 @@
-#!/usr/bin/env node
-'use strict';
-
-// Repository-health check for the plugin profile knowledge base. Kept separate from
-// plugin-knowledge.js (read access) for the same reason domain-knowledge-validate.js is
-// separate from domain-knowledge.js: validation checks the repo, read access serves lookups.
-
-const path = require('node:path');
-const {
-  pluginsRoot,
-  validateKnowledge,
-  writeJson,
-} = require('../lib/plugin-knowledge.js');
-const {
-  knowledgeRoot: domainsRoot,
-  knowledgeSummary,
-} = require('../../rp-target-wix/lib/domain-knowledge.js');
-
-function main() {
-  const writeIndex = process.argv.includes('--write-index');
-  const pluginsDir = pluginsRoot();
-
-  let targetKnowledge = null;
-  try {
-    targetKnowledge = knowledgeSummary(domainsRoot(path.resolve(__dirname, '..', '..', 'rp-target-wix')));
-  } catch (error) {
-    console.error(`WARNING: could not load Wix target knowledge for cross-adapter checks: ${error.message}`);
-  }
-
-  if (writeIndex) {
-    // Write the index first so the staleness check in validateKnowledge reflects the
-    // regenerated file rather than reporting the state we are about to fix.
-    const { generatedIndex } = validateKnowledge(pluginsDir, { targetKnowledge });
-    writeJson(path.join(pluginsDir, 'index.json'), generatedIndex);
-  }
-
-  const result = validateKnowledge(pluginsDir, { targetKnowledge });
-  if (!result.ok) {
-    console.error(`FAIL: plugin knowledge validation found ${result.errors.length} problem(s)`);
-    for (const error of result.errors) console.error(`  - ${error}`);
-    process.exit(1);
-  }
-
-  console.log(
-    writeIndex
-      ? `OK: plugin knowledge index regenerated and valid (${result.profileCount} profile(s))`
-      : `OK: plugin knowledge valid (${result.profileCount} profile(s))`,
-  );
-}
-
-main();