@wix/agent-skills 1.35.1 → 1.36.1

package/skills/wix-replatform/resources/rp-target-wix/domains/ecom/entities/pickup-location.json

@@ -1,122 +0,0 @@
-{
-  "schemaVersion": 1,
-  "domain": "ecom",
-  "entity": "pickup-location",
-  "displayName": "Wix Pickup Location",
-  "capability": "commerce.pickup-location",
-  "target": {
-    "classification": "native",
-    "nativeEntity": "PickupLocation",
-    "verifiedFqdn": "wix.ecom.v1.pickup_location",
-    "idPolicy": "server-assigned",
-    "crosswalkRequired": true
-  },
-  "dependsOn": [
-    "ecom/delivery-profile"
-  ],
-  "sourceAliases": [
-    {
-      "sourceSystem": "woocommerce",
-      "sourceEntity": "shipping-zone.method[local_pickup|pickup_location]",
-      "routes": [
-        "/wc/v3/shipping/zones/{id}/methods"
-      ],
-      "confidence": "high",
-      "note": "shipping-build.js's classifyMethod returns kind:'pickup' for these two method_ids. That classification produces a PickupLocation and NEVER a ShippingOption. It does NOT mean no carrier: the Pickup DeliveryCarrier must still be attached, with backupRate {amount '0', active FALSE}, or the collection point does not render at checkout at all -- see the attach-the-pickup-carrier blocker pitfall. What the classification is terminal about is the SHIPPING side: no ShippingOption, and no delivery carrier of any other role."
-    },
-    {
-      "sourceSystem": "woocommerce",
-      "sourceEntity": "settings.pickup_locations",
-      "routes": [
-        "/wp/v2/settings"
-      ],
-      "confidence": "high",
-      "note": "WooCommerce Blocks Local Pickup stores its locations as WordPress options surfaced on the core settings route -- NOT under /wc/v3/. This route is already part of the default discovery sweep, so a Blocks source's pickup addresses are already captured; they just had no consumer until now."
-    }
-  ],
-  "preferredWrite": {
-    "surface": "Pickup Locations",
-    "endpoint": "POST https://manage.wix.com/_api/pickup-locations/v1/pickup-locations (the public www.wixapis.com host 404s — see the host pitfall)",
-    "writerId": "createPickupLocation",
-    "verification": "verified-live",
-    "importSafe": true,
-    "bulk": true,
-    "releaseStatus": "beta",
-    "decision": "Collection points are their own entity on their own service host. Bulk create/update/delete exist (max 100 per call) but a migration rarely has more than a handful of collection points, so the single create is the default path."
-  },
-  "reliability": {
-    "status": "reliable",
-    "flags": []
-  },
-  "pitfalls": [
-    {
-      "code": "pickup-is-not-a-shipping-option",
-      "severity": "blocker",
-      "summary": "A source local_pickup method must NEVER be written as a ShippingOption. A ShippingOption has no app/carrier/role field, so a 0-amount collection option renders at checkout as a free DELIVERY sitting next to the real paid delivery -- buyers pick it expecting their order shipped for nothing. Observed live: collection rendered as a 0-priced shipping choice beside a paid one. The classification is terminal: kind:'pickup' produces a PickupLocation and no shipping option."
-    },
-    {
-      "code": "attach-the-pickup-carrier-but-never-with-an-active-backup-rate",
-      "severity": "blocker",
-      "summary": "Two facts that look contradictory and are not. (a) A Pickup carrier whose backupRate is ACTIVE renders as a 0-priced DELIVERY row beside the paid one -- live-observed, alongside a duplicate 0-priced shipping option for the same collection point. (b) But removing the Pickup carrier ENTIRELY made the collection point stop appearing at all, even though the PickupLocation still existed, was active, and was bound to the region -- observed live after exactly that removal. The correct shape is therefore: attach the Pickup carrier so the region can render collection, with backupRate {amount '0', active FALSE} so the carrier itself never becomes a delivery row -- and create the PickupLocation for the actual collection point. Never an active backupRate, never no carrier at all. resolvePickupAppId is how the Pickup app's installation-scoped appId is resolved; it IS a write path after all, just a carefully constrained one."
-    },
-    {
-      "code": "address-is-required-and-only-one-source-shape-has-one",
-      "severity": "blocker",
-      "summary": "`address` (with at least `country`) is required by the create call, and whether the source has one depends entirely on WHICH pickup implementation it uses. BLOCKS Local Pickup (`pickup_location` method) keeps real locations WITH addresses in WordPress options, exposed on GET /wp/v2/settings as `pickup_locations[]` = {name, address:{address_1, city, state, postcode, country}, details, enabled} plus `pickup_location_settings` = {enabled, title, tax_status, cost}. LEGACY `local_pickup` (a shipping-zone method) carries only {title, tax_status, cost} -- no address, no linked record, nothing to read; its town is often named inside the method's own TITLE text, which is a label and must never be parsed as an address. So check the Blocks locations FIRST (shipping-build.js's resolvePickupAddressSource): a Blocks source needs no human input at all, while a legacy source can only be answered by the merchant. buildPickupLocationInput throws without an address either way, because the server-side failure carries far less context than the local one."
-    },
-    {
-      "code": "blocks-global-settings-gate-the-locations-and-carry-the-fee",
-      "severity": "blocker",
-      "summary": "BLOCKS Local Pickup splits its configuration in two, and the GLOBAL half owns things no individual location carries: `pickup_location_settings` = {enabled, title, tax_status, cost}. (1) `enabled` is the MASTER SWITCH. Every location can be individually `enabled: true` while pickup as a whole is off, so reading only the per-location flag re-enables a fulfillment method the merchant deliberately turned off, and Wix checkout starts offering collection. Both gates must pass: a location is active only when the global switch is not explicitly off AND the location itself is not `enabled: false`. WooCommerce writes this as the strings yes/no on some routes and as a real boolean on others, and ABSENT means \"not configured\", which for a feature switch reads as ON -- only an explicit no/false/0/off turns it off. (2) `cost` is the collection FEE, set ONCE for all locations. Blocks pickup has no per-zone cost field, so the zone method's own `settings.cost` -- which is where the LEGACY local_pickup method correctly keeps its fee -- is absent for this shape and the classification reads 0. Read the fee from the global settings and pass it to buildPickupLocationInput's `amount`, or every pickup order silently charges nothing. shipping-build.js's pickupLocationsFromWpSettings returns both the resolved `active` and the `amount` per location, so a caller never has to know which half of the config they came from."
-    },
-    {
-      "code": "shipping-rule-id-is-deprecated-and-internal",
-      "severity": "warning",
-      "summary": "`shippingRuleId` is deprecated, marked internal, and replaced by `deliveryRegionIds`, with a removal target already in the past. Wix's own dashboard front-end still sends it; that is not a reason for a migration to. Send `deliveryRegionIds` only."
-    },
-    {
-      "code": "delivery-regions-are-not-updatable-through-update",
-      "severity": "warning",
-      "summary": "The Update call cannot change region membership -- the service says so explicitly. Use the dedicated Add Delivery Region / Remove Delivery Region calls on the pickup location (each takes pickupLocationId + deliveryRegionId + revision). Note the name collision with the Delivery Profiles API's own addDeliveryRegion, which adds a REGION TO A PROFILE; this one adds a PICKUP LOCATION TO A REGION."
-    },
-    {
-      "code": "create-failed-precondition-limits",
-      "severity": "warning",
-      "summary": "Create can fail FAILED_PRECONDITION with LOCATIONS_IN_SHIPPING_RULE_LIMIT_EXCEEDED or LIMIT_OF_OPTIONS_PER_DELIVERY_REGION_EXCEEDED. Caps: deliveryRegionIds max 50 per location, rates max 50, name 1-100 chars, deliveryTime max 500, instructions max 1000."
-    },
-    {
-      "code": "documented-public-host-404s-use-the-dashboard-proxy",
-      "severity": "blocker",
-      "summary": "LIVE-VERIFIED 2026-09-01, and NOT what the service's own documentation says. Its documentation.yaml declares `host: www.wixapis.com/pickup-locations`, but EVERY path under that host returns 404 with a valid site token -- both the hyphenated and camelCase spellings, and the /ecom/ prefix too. The service is BETA and is not exposed on the public gateway yet. The route that works is the dashboard proxy, `https://manage.wix.com/_api/pickup-locations/v1/pickup-locations`, which accepts the same CLI-minted site token. wix-writers.js's resolvePickupLocationsBase probes the public host first and falls back to the proxy on 404 (rethrowing anything else, so a 401/403 is never hidden behind a fallback), so this starts using the public host by itself once Wix exposes it. Permission scopes are unchanged: ECOM.PICKUP_LOCATION_CREATE / _READ / _UPDATE / _DELETE."
-    },
-    {
-      "code": "a-blank-address-is-a-real-choice-but-cannot-mean-absent",
-      "severity": "warning",
-      "summary": "Plenty of merchants coordinate collection by phone and deliberately do not publish a street -- the source method's own title usually says exactly that. That is a legitimate configuration, NOT missing data, and must not be treated as a failure to migrate. But `address` is required by the create call, so 'blank' cannot mean omitted. The honest minimum is the one part actually known: the country, DERIVED from the delivery region the location is bound to (shipping-build.js's buildMinimalPickupAddress), with no street, city or postcode invented to fill the gap. The location's `name` is then what tells buyers where and how to collect. Two guards: a region spanning more than one country has no single answer and throws rather than picking one; and a country-plus-city collection point (no street) was CREATED AND READ BACK LIVE 2026-09-01, address {country, city} preserved exactly as sent. How it renders at checkout is still worth one look."
-    }
-  ],
-  "mappingGuidance": [
-    "Two source shapes, checked in this order. (1) BLOCKS: `pickup_locations[]` on /wp/v2/settings already holds real locations -- map name -> name, address.address_1 -> addressLine (whole line, unparsed), address.city -> city, address.state -> subdivision, address.postcode -> postalCode, address.country -> country, details -> instructions, enabled -> active. Note `state` is a SEPARATE field here, unlike the store address's COUNTRY:STATE packing. (2) LEGACY `local_pickup` zone method: one PickupLocation per method, bound to the delivery region built from that method's zone via deliveryRegionIds[]; the method's title becomes `name` and its cost the single rate (a non-numeric cost falls back to 0 and is flagged).",
-    "`address` cannot be derived from a LEGACY method -- resolve it from the store address as a proposal the merchant confirms, or ask. `deliveryTime` has no WooCommerce counterpart in either shape; leave it unset rather than inventing a value. `instructions` maps from a Blocks location's `details`, and has no legacy counterpart.",
-    "Never also create a ShippingOption for the same method -- that re-creates the 0-priced-delivery defect this entity exists to avoid. The Pickup DeliveryCarrier is the opposite case and must NOT be omitted: attach it with backupRate {amount '0', active FALSE}. An ACTIVE backup rate re-creates the same 0-priced-delivery row, and no carrier at all makes the collection point vanish from checkout even though the PickupLocation exists and is bound to the region -- both were observed live. See the two blocker pitfalls above.",
-    "A zone whose only enabled method is pickup is NOT a checkout dead end -- collection is a real way to receive an order -- so it does not get delivery-profile.json's missing-rates alert even though it offers no DELIVERY rate. It still carries the Pickup carrier; that carrier's backup rate is inactive by design, so the zone has a carrier and no deliverable rate at the same time, which is the correct shape here rather than the gap the alert looks for.",
-    "A merchant who declines to publish a street address gets a country-only address derived from the delivery region, and the full source method title as `name`. Reach that branch only through an explicit decline (resolvePickupAddressSource's `addressDeclined`) -- never as a silent fallback when an address could not be found, because those two states need different follow-ups."
-  ],
-  "setupRequirements": [
-    "Wix Stores app (eCommerce checkout) — the site's default delivery profile must exist so a delivery region id is available to bind to."
-  ],
-  "objectPageException": "The public API-reference tree for shipping and delivery exposes Delivery Profiles only; there is no PickupLocations subsection and no '…-object' page for this entity anywhere in it. The field shape, limits, deprecations, error codes, host and permission names are taken from Wix's own service contract for the resource instead.",
-  "evidence": [
-    {
-      "type": "service-definition",
-      "path": "wix-internal-service-definition",
-      "note": "Wix's own PickupLocations service contract and its shipped create/query examples: entity fields and limits, the required-on-create set, the shippingRuleId deprecation and its replacement, the Add/Remove Delivery Region calls, the FAILED_PRECONDITION application codes, the public REST host, and the permission names. Read directly from the service definition rather than from a documentation page."
-    },
-    {
-      "type": "service-definition",
-      "path": "wix-internal-service-definition",
-      "note": "PickupLocation.rates is the same ConditionalRates type as ShippingOption.rates, so the conditional-rate shape documented on ecom/shipping-option applies here unchanged."
-    }
-  ],
-  "notes": "Authored to close the pickup half of the shipping phase-2 work: phase 1 wrote collection points as shipping options, which is what put a 0-priced delivery next to a paid one. Create and read-back VERIFIED LIVE 2026-09-01, through the dashboard proxy host (the documented public host 404s -- see its pitfall). A country+city address with no street round-tripped exactly. What is still unverified is purely cosmetic: how a street-less collection point renders at checkout."
-}

package/skills/wix-replatform/resources/rp-target-wix/domains/ecom/entities/shipping-option.json

@@ -1,98 +0,0 @@
-{
-  "schemaVersion": 1,
-  "domain": "ecom",
-  "entity": "shipping-option",
-  "displayName": "Wix Shipping Option",
-  "capability": "commerce.shipping-rate",
-  "target": {
-    "classification": "native",
-    "nativeEntity": "ShippingOption",
-    "verifiedFqdn": null,
-    "idPolicy": "server-assigned",
-    "crosswalkRequired": true
-  },
-  "dependsOn": [
-    "ecom/delivery-profile"
-  ],
-  "sourceAliases": [
-    {
-      "sourceSystem": "woocommerce",
-      "sourceEntity": "shipping-zone.method",
-      "routes": [
-        "/wc/v3/shipping/zones/{id}/methods"
-      ],
-      "confidence": "high",
-      "note": "Same source data shipping-build.js's classifyMethod already classifies for delivery-profile.json's deliveryCarrier.backupRate -- but ONLY a kind:'carrier' classification produces BOTH a DeliveryCarrier.backupRate AND a ShippingOption from the same classified method; for that kind they are not alternatives. The other kinds produce no shipping option at all: 'pickup' becomes a PickupLocation (see ecom/pickup-location), 'threshold' folds onto a sibling paid option as a conditional rate, and 'coupon-domain' produces nothing here."
-    }
-  ],
-  "preferredWrite": {
-    "surface": "Shipping Options",
-    "endpoint": "POST /ecom/v1/shipping-options",
-    "writerId": "createShippingOptionVerified",
-    "verification": "verified-live",
-    "importSafe": true,
-    "bulk": false,
-    "decision": "Verified live: creating a ShippingOption that matches a region's DeliveryCarrier.backupRate populates the dashboard rate table where the carrier write alone does not. The write counts only when its read-back matches (createShippingOptionVerified); createShippingOption stays as the raw call."
-  },
-  "reliability": {
-    "status": "reliable",
-    "flags": []
-  },
-  "pitfalls": [
-    {
-      "code": "not-derived-from-backup-rate-a-separate-required-write",
-      "severity": "blocker",
-      "summary": "DeliveryCarrier.backupRate does not create a ShippingOption and does not clear Wix's missing-rates dashboard warning. Live verification showed that a carrier-only region can write and read back successfully while remaining non-functional at checkout. Always create a matching ShippingOption for every imported DeliveryRegion from the same classified method used for DeliveryCarrier.backupRate; see shipping-build.js's buildShippingOptionInput."
-    },
-    {
-      "code": "delivery-region-ids-plural-is-the-live-field",
-      "severity": "warning",
-      "summary": "CORRECTED. An earlier reading of this API said to use the singular `deliveryRegionId` and treat the plural as decoration; that is inverted. Per the service contract, the singular `deliveryRegionId` is DEPRECATED and replaced by `deliveryRegionIds`, with a removal target already in the past -- the plural is the live field, which is also why the singular-only observation showed an empty plural array on read-back. Write BOTH: the plural is what is honoured going forward, the singular keeps older reads and tooling working until it is actually removed. The original observation was real; the conclusion drawn from a doc page that predated the deprecation was not."
-    },
-    {
-      "code": "estimated-delivery-time-is-the-field-not-the-translatable-name",
-      "severity": "blocker",
-      "summary": "CORRECTED; the earlier rule had the two names exactly reversed. The request field is `estimatedDeliveryTime` (proto field 12, `estimated_delivery_time`, max 500 characters; wix-private/ecom shipping_option.proto at ed73ff24). `estimate_delivery_time` is only the `translatable` annotation's `name` -- a key in the translation system, not something a request can set -- which is why it looks like a second spelling. Wix accepts the misspelled `estimateDeliveryTime` in a create body with a 200 and silently drops it, so every option created with it read back with no delivery time. Live 2026-10-08: POST with `estimateDeliveryTime` returned 200 and GET showed no estimate; PATCH with `{shippingOption:{id, revision, estimatedDeliveryTime}}` stored it and it read back. shipping-build.js's buildShippingOptionInput emits only `estimatedDeliveryTime`, throws above 500 characters (never truncates), and has no default; createShippingOptionVerified reads every create back and repairs only a blank estimate with one estimate-only PATCH."
-    },
-    {
-      "code": "rates-support-conditions-and-the-lowest-valid-one-wins",
-      "severity": "warning",
-      "summary": "`rates[]` is the ConditionalRates type: each entry is {conditions[0..10], amount (decimal string), multiplyByQuantity}, and each Condition is {type: BY_TOTAL_WEIGHT|BY_TOTAL_PRICE|BY_TOTAL_QUANTITY, value, operator: EQ|GT|GTE|LT|LTE}. Conditions AND together; an empty conditions[] means always-applies. The runtime rule, verbatim from the service contract: 'at runtime for a given shipment input, up to one rate (price) should be returned in an option. If more than one rate is valid then we return the lowest one.' A source minimum-order free-shipping threshold is therefore fully expressible and is NOT a gap. What the contract does NOT settle is whether BY_TOTAL_PRICE is measured before or after cart discounts -- WooCommerce has an explicit ignore_discounts setting for exactly this, so the two can disagree. Ship the threshold as written, flag it, confirm at the first live checkout, and never report such a rate as verified until then."
-    },
-    {
-      "code": "explicit-two-band-partition-breaks-the-dashboard-editor",
-      "severity": "blocker",
-      "summary": "LIVE-VERIFIED 2026-09-16: a paid-flat-rate-plus-threshold fold has TWO API-valid encodings, and only one of them is dashboard-editable. Writing it as an explicit two-way partition -- one rate LT the threshold at the paid amount, one rate GTE the threshold at 0 (shipping-build.js's priceThresholdRates) -- is accepted by Create Shipping Option (200, correct read-back, verifyShippingEconomics reports zero violations) but the Wix dashboard's own rate editor renders it as 'Rate by price' mode with invalid, unfillable 'From'/'Up to' boundary fields -- a merchant opening this rate sees validation errors on a rate that works fine at checkout. LEANING ON the service's own lowest-wins tiebreak instead -- one UNCONDITIONAL rate at the paid amount plus one separate GTE-threshold rate at 0 (unconditionalRate + freeAboveThresholdRates, both already in shipping-build.js) -- renders correctly as the dashboard's simpler 'Flat rate' mode with its 'Offer free shipping when customers purchase a certain amount' checkbox, confirmed live against the actual dashboard editor. resolveZoneMethods now builds this combination by default; do not switch it back to the explicit-partition shape without re-verifying the dashboard editor first, and do not reach for priceThresholdRates directly for anything a merchant will open in the dashboard."
-    },
-    {
-      "code": "one-option-per-buyer-choice-not-per-source-method",
-      "severity": "blocker",
-      "summary": "CORRECTED, and the correction matters more than the original. An earlier version of this rule said each carrier-classified method becomes its own ShippingOption and to never collapse several methods into one. That produces a store where the same delivery is listed two or three times, because a source zone lists every shipping BEHAVIOUR as its own method row -- a minimum-order threshold and a coupon-gated free shipping are both rows, and neither is something a buyer picks. Observed live: one source zone with five methods produced four options, two of them byte-identical unconditional zeroes. Resolve the zone's methods to buyer-facing choices first (shipping-build.js's resolveZoneMethods: fold thresholds onto paid options, drop coupon-gated rows, route pickup to its own entity, then collapse identical survivors) and create one option per surviving choice. Every collapse is reported as a resolved source defect -- a silent collapse is indistinguishable from never having noticed."
-    }
-  ],
-  "mappingGuidance": [
-    "For every WooCommerce shipping-zone method that shipping-build.js's classifyMethod resolves to kind:'carrier', create BOTH a DeliveryCarrier (backupRate, on the delivery profile) AND a ShippingOption (rates[], standalone resource keyed by deliveryRegionId) from the same classified result -- shipping-build.js's buildDeliveryCarrierInput and buildShippingOptionInput. Creating only the former leaves the region looking fully configured via the API (and even via a plain Query Delivery Profiles read-back) while Wix's own checkout and dashboard still treat it as missing rates.",
-    "amount is a plain decimal string ('8', '0'), same convention as backupRate.amount -- no separate currency/format handling needed.",
-    "A source minimum-order free-shipping threshold is CARRIED, not dropped: write the paid option with two rates -- an UNCONDITIONAL rate at the source price plus a separate GTE band at 0 on BY_TOTAL_PRICE at the source's minimum (shipping-build.js's unconditionalRate + freeAboveThresholdRates), relying on the service's own lowest-valid-rate tiebreak. Do NOT use the explicit LT/GTE two-way partition (priceThresholdRates) for this -- see the explicit-two-band-partition-breaks-the-dashboard-editor pitfall below: it is schema-valid but renders as a broken, unfillable 'Rate by price' mode in the Wix dashboard's own rate editor. priceThresholdRates still exists and is schema-valid; it is discouraged specifically for anything a merchant will open in the dashboard, which is the normal case here.",
-    "An unconditional 0-amount rate is correct in exactly one case: a source free-shipping method with NO condition attached at all. Anywhere else it means a condition was dropped, which does not half-migrate the rule -- it inverts it, makes every paid option unreachable, and costs the merchant its shipping revenue. shipping-build.js's verifyShippingEconomics fails a region that has an unconditional free option alongside a paid one, for exactly this reason.",
-    "Delivery estimate: resolve it per option with shipping-build.js's resolveDeliveryEstimate -- a merchant-confirmed `shipping-delivery-estimate:<zoneId>` decision (`source: \"user\"` only) wins, then a delivery time the source states, then the reviewed '5-7 business days' default in the DESTINATION site's language (DEFAULT_ESTIMATE_BY_LANGUAGE; Hebrew gets '5–7 ימי עסקים'). A language with no reviewed row gets NO estimate and a `shipping-estimate-missing` merchant item; English is never written on a non-English site. Every default is flagged `shipping-estimate-default` for the merchant to confirm. A non-empty estimate the migration did not write is the merchant's and is never overwritten. Options created by earlier (pre-fix) migrations are reported (`shipping-estimate-legacy-blank`), never edited."
-  ],
-  "setupRequirements": [],
-  "objectPageException": "The standard API reference menu (dev.wix.com/docs/api-reference/business-solutions/e-commerce/shipping-delivery, checked 2026-08-15) has exactly one subsection, 'Delivery Profiles' -- no 'Shipping Options' subsection and no dedicated ShippingOption '…-object' page exist anywhere in that tree. The entire resource is undocumented there; the only place it's described at all is the 'Shipping: API Reference' skills article (a distilled, AI-agent-oriented reference in a completely separate doc tree, business-solutions/e-commerce/skills/) plus its sibling 'Fix Shipping Coverage Gaps' article. The full field shape is sourced from those two pages' request/response examples instead.",
-  "evidence": [
-    {
-      "type": "wix-docs",
-      "url": "https://dev.wix.com/docs/api-reference/business-solutions/e-commerce/skills/shipping-fix-coverage-gaps",
-      "note": "the article that surfaced ShippingOption's existence and its role in clearing a checkout coverage gap; not linked from or mentioned on any shipping-delivery/delivery-profiles/* page"
-    },
-    {
-      "type": "wix-docs",
-      "url": "https://dev.wix.com/docs/api-reference/business-solutions/e-commerce/skills/shipping-api-reference",
-      "note": "full Query/Create/Get/Update/Delete Shipping Option + Add/Remove Delivery Region (on a shipping option) schema and the singular-vs-plural deliveryRegionId gotcha, confirmed 2026-08-15"
-    },
-    {
-      "type": "live-verification",
-      "path": "anonymized-live-verification"
-    }
-  ]
-}

package/skills/wix-replatform/resources/rp-target-wix/domains/ecom/entities/wishlist-item.json

@@ -1,86 +0,0 @@
-{
-  "schemaVersion": 1,
-  "domain": "ecom",
-  "entity": "wishlist-item",
-  "displayName": "Wishlist Item",
-  "capability": "commerce.wishlists",
-  "target": {
-    "classification": "native",
-    "nativeEntity": "Wishlist",
-    "verifiedFqdn": "wix.platform.v1.wishlist",
-    "idPolicy": "server-assigned",
-    "crosswalkRequired": true
-  },
-  "dependsOn": ["stores/product"],
-  "blockedSourceDependencies": [
-    {
-      "sourceEntityRef": "plugin.ti-woocommerce-wishlist.wishlist-definition",
-      "degradedField": "items",
-      "pitfallCode": "no-backend-write-path-for-migration",
-      "degradation": "warning"
-    },
-    {
-      "sourceEntityRef": "plugin.ti-woocommerce-wishlist.wishlist-item",
-      "degradedField": "items",
-      "pitfallCode": "no-backend-write-path-for-migration",
-      "degradation": "warning"
-    }
-  ],
-  "objectPageException": "This API is internal-only (proto exposure: INTERNAL for its mutating RPCs, ALPHA maturity) -- it has no public dev.wix.com docs object page. Confirmed by two ranked SearchWixRESTDocumentation queries and a full raw API-spec index substring scan for 'wishlist', all returning zero results; the authoritative source is the internal proto itself (see evidence[]).",
-  "sourceAliases": [
-    {
-      "sourceSystem": "wordpress",
-      "sourceEntity": "ti_woocommerce_wishlist",
-      "routes": [
-        "tinvwl_lists (structure-bridge-plugin)",
-        "tinvwl_items (structure-bridge-plugin)",
-        "/wc/v3/wishlist/get_by_user/{user_id} (plugin-rest-child, per-member chain)"
-      ],
-      "confidence": "high"
-    }
-  ],
-  "preferredWrite": {
-    "surface": "com.wixpress.wishlist.Wishlist (internal proto, package com.wixpress.wishlist)",
-    "endpoint": "POST /v1/wishlists/my",
-    "writerId": null,
-    "verification": "unverified",
-    "importSafe": false,
-    "bulk": false
-  },
-  "fallbacks": [
-    {
-      "classification": "cms",
-      "when": "Always, for a bulk migration import. The native AddToWishlist/RemoveFromWishlist RPCs only operate on 'the default wishlist by context's member' (member-session-scoped, exposure: INTERNAL) -- there is no service-account/backend RPC to write items to an arbitrary existing member's wishlist on their behalf. GetWishlistById/GetWishlists accept a site-level WISHLIST.MANAGE-SITE-WISHLISTS permission but are read-only. A migration script has no member session for historical WooCommerce customers who have never logged into the new Wix site, so the native write path is unusable for import regardless of Alpha status."
-    }
-  ],
-  "reliability": {
-    "status": "unreliable",
-    "flags": ["IMPORT_UNRELIABLE"]
-  },
-  "pitfalls": [
-    {
-      "code": "no-backend-write-path-for-migration",
-      "severity": "blocker",
-      "summary": "Verified against the authoritative internal proto: the fqdn is wix.platform.v1.wishlist (service com.wixpress.wishlist.Wishlist). Its three mutating RPCs (GetWishlist/AddToWishlist/RemoveFromWishlist) are ALPHA maturity, exposure: INTERNAL, and scoped to 'the default wishlist by context's member' -- the caller's own session, not an arbitrary member named by a backend script. The only RPCs open to a site-level manage permission (GetWishlistById, GetWishlists) are read-only. There is no proto-level path for a migration script to write wishlist items on behalf of pre-existing customers who have never authenticated to the new site."
-    },
-    {
-      "code": "native-target-exists-do-not-conclude-requires-development",
-      "severity": "info",
-      "summary": "This is NOT a 'Wix has no surface' gap -- a real native Wishlist entity and proto exist, confirmed live from source. The limitation is specifically the migration-import use case (no backend bulk-write RPC), not an absent feature. Do not record this capability in requires-development.json; it is a documented reliability/fallback case (see fallbacks[] and reliability.flags above), revisitable if Wix adds a service-account write path or a different integration surface (e.g. Velo backend code running with elevated permissions, not yet investigated)."
-    }
-  ],
-  "mappingGuidance": [
-    "Land wishlist data in a Wix CMS collection (cms/collection) for migration imports today -- see fallbacks[]. Revisit this entity if a backend/service-account write RPC is ever added to the Wishlist API."
-  ],
-  "setupRequirements": [
-    "Wix Data (CMS) app, for the fallback collection",
-    "Wix Stores, so wishlist items can reference real migrated product ids"
-  ],
-  "evidence": [
-    {
-      "type": "source-proto",
-      "path": "wix-private/monorepo@391685f038538afc4a84ac7f9fa6e38a3642783a:comp/ecom/platform/wishlist/wishlist-api/src/main/proto/com/wixpress/wishlist/wishlist.proto",
-      "note": "Authoritative internal proto for com.wixpress.wishlist.Wishlist."
-    }
-  ]
-}

package/skills/wix-replatform/resources/rp-target-wix/domains/events/docs-survey.json

@@ -1,128 +0,0 @@
-{
-  "schemaVersion": 1,
-  "domain": "events",
-  "fetchedAt": "2026-08-11",
-  "roots": [
-    "api-reference/business-solutions/events"
-  ],
-  "surfaces": [
-    {
-      "id": "api-reference/business-solutions/events/event-management/categories",
-      "title": "Categories",
-      "url": "https://dev.wix.com/docs/api-reference/business-solutions/events/event-management/categories",
-      "group": "Event Management",
-      "verdict": "claimed",
-      "refs": [
-        "events/category"
-      ],
-      "reviewedOn": "2026-08-11"
-    },
-    {
-      "id": "api-reference/business-solutions/events/event-management/events-settings",
-      "title": "Events Settings",
-      "url": "https://dev.wix.com/docs/api-reference/business-solutions/events/event-management/events-settings",
-      "group": "Event Management",
-      "verdict": "not-relevant",
-      "reason": "Site-level settings singleton (get/update only, no create); app configuration, not migratable records. Revisit only if a setup-config entity for Events defaults is ever needed.",
-      "reviewedOn": "2026-08-11"
-    },
-    {
-      "id": "api-reference/business-solutions/events/event-management/events-v3",
-      "title": "Events V3",
-      "url": "https://dev.wix.com/docs/api-reference/business-solutions/events/event-management/events-v3",
-      "group": "Event Management",
-      "verdict": "claimed",
-      "refs": [
-        "events/event"
-      ],
-      "reviewedOn": "2026-08-11"
-    },
-    {
-      "id": "api-reference/business-solutions/events/event-management/form",
-      "title": "Form",
-      "url": "https://dev.wix.com/docs/api-reference/business-solutions/events/event-management/form",
-      "group": "Event Management",
-      "verdict": "claimed",
-      "reviewedOn": "2026-08-11",
-      "refs": [
-        "events/registration-form"
-      ]
-    },
-    {
-      "id": "api-reference/business-solutions/events/event-management/policies-v2",
-      "title": "Policies V2",
-      "url": "https://dev.wix.com/docs/api-reference/business-solutions/events/event-management/policies-v2",
-      "group": "Event Management",
-      "verdict": "not-relevant",
-      "reason": "Checkout policy text attached to events (full CRUD exists), but no observed WP event source models policies as data. Revisit if a source carries per-event terms/refund policies.",
-      "reviewedOn": "2026-08-11"
-    },
-    {
-      "id": "api-reference/business-solutions/events/event-management/schedule-items",
-      "title": "Schedule Items",
-      "url": "https://dev.wix.com/docs/api-reference/business-solutions/events/event-management/schedule-items",
-      "group": "Event Management",
-      "verdict": "not-relevant",
-      "reason": "Multi-session agenda model (full CRUD exists), but observed WP event sources (TEC) model a single start/end carried on events/event. Revisit if a conference-schedule source capability appears.",
-      "reviewedOn": "2026-08-11"
-    },
-    {
-      "id": "api-reference/business-solutions/events/event-management/staff-members",
-      "title": "Staff Members",
-      "url": "https://dev.wix.com/docs/api-reference/business-solutions/events/event-management/staff-members",
-      "group": "Event Management",
-      "verdict": "not-relevant",
-      "reason": "Event staff records (full CRUD exists), but observed WP event sources model organizers as event fields, not standalone staff. Revisit if a source carries a staff/organizer directory worth importing.",
-      "reviewedOn": "2026-08-11"
-    },
-    {
-      "id": "api-reference/business-solutions/events/event-management/ticket-definitions-v3",
-      "title": "Ticket Definitions V3",
-      "url": "https://dev.wix.com/docs/api-reference/business-solutions/events/event-management/ticket-definitions-v3",
-      "group": "Event Management",
-      "verdict": "claimed",
-      "reviewedOn": "2026-08-11",
-      "refs": [
-        "events/ticket-definition"
-      ]
-    },
-    {
-      "id": "api-reference/business-solutions/events/registration/event-guests",
-      "title": "Event Guests",
-      "url": "https://dev.wix.com/docs/api-reference/business-solutions/events/registration/event-guests",
-      "group": "Registration",
-      "verdict": "not-importable",
-      "reason": "Read-only derived records (query + webhooks, no write API); guest rows are produced by RSVP/ticket-order writes, so imports land there, never here.",
-      "reviewedOn": "2026-08-11"
-    },
-    {
-      "id": "api-reference/business-solutions/events/registration/rsvp-v2",
-      "title": "RSVP V2",
-      "url": "https://dev.wix.com/docs/api-reference/business-solutions/events/registration/rsvp-v2",
-      "group": "Registration",
-      "verdict": "claimed",
-      "reviewedOn": "2026-08-11",
-      "refs": [
-        "events/rsvp"
-      ]
-    },
-    {
-      "id": "api-reference/business-solutions/events/registration/ticketing",
-      "title": "Ticketing",
-      "url": "https://dev.wix.com/docs/api-reference/business-solutions/events/registration/ticketing",
-      "group": "Registration",
-      "verdict": "not-importable",
-      "reason": "Ticket orders/reservations are only created through the live checkout flow — the domain's ticket-order-history-not-importable blocker. Past ticket sales cannot be migrated.",
-      "reviewedOn": "2026-08-11"
-    },
-    {
-      "id": "api-reference/business-solutions/events/skills",
-      "title": "Skills",
-      "url": "https://dev.wix.com/docs/api-reference/business-solutions/events/skills",
-      "group": null,
-      "verdict": "not-relevant",
-      "reason": "AI-skill documentation page (agent walkthrough of Create Event), not a data surface.",
-      "reviewedOn": "2026-08-11"
-    }
-  ]
-}

package/skills/wix-replatform/resources/rp-target-wix/domains/events/domain.json

@@ -1,38 +0,0 @@
-{
-  "schemaVersion": 1,
-  "domain": "events",
-  "dependsOnRequired": true,
-  "displayName": "Wix Events",
-  "ownerHint": "Events, registration, RSVP, and ticketing domain owners",
-  "wixAppsRequired": [
-    "Wix Events"
-  ],
-  "docsRoots": [
-    "api-reference/business-solutions/events"
-  ],
-  "defaultImportOrder": [
-    "category",
-    "event",
-    "registration-form",
-    "ticket-definition",
-    "rsvp"
-  ],
-  "sharedPitfalls": [
-    {
-      "code": "ticket-order-history-not-importable",
-      "severity": "blocker",
-      "summary": "Ticketed registration history has no import path: ticket orders are only created through the live checkout flow. Past ticket sales cannot be migrated even though the events themselves can."
-    },
-    {
-      "code": "registration-notifications-default-on",
-      "severity": "warning",
-      "summary": "Registration side effects are on by default across this domain. RSVP creation sends a confirmation email unless disableNotifications is set."
-    }
-  ],
-  "evidence": [
-    {
-      "type": "wix-docs",
-      "url": "https://dev.wix.com/docs/api-reference/business-solutions/events/event-management/events-v3/create-event"
-    }
-  ]
-}

package/skills/wix-replatform/resources/rp-target-wix/domains/events/entities/category.json

@@ -1,73 +0,0 @@
-{
-  "schemaVersion": 1,
-  "domain": "events",
-  "entity": "category",
-  "displayName": "Events Category",
-  "capability": "content.event-categories",
-  "target": {
-    "classification": "native",
-    "nativeEntity": "Wix Events Category",
-    "verifiedFqdn": "wix.events.v1.category",
-    "idPolicy": "server-assigned",
-    "crosswalkRequired": true
-  },
-  "dependsOn": [],
-  "sourceAliases": [
-    {
-      "sourceSystem": "wordpress",
-      "sourceEntity": "tribe_events_cat",
-      "routes": [
-        "/wp/v2/tribe_events_cat"
-      ],
-      "confidence": "high"
-    }
-  ],
-  "preferredWrite": {
-    "surface": "Events Categories",
-    "endpoint": "POST /events/v1/categories",
-    "writerId": null,
-    "verification": "verified-live",
-    "importSafe": true,
-    "bulk": false
-  },
-  "fallbacks": [
-    {
-      "classification": "cms",
-      "when": "Only if category metadata beyond name/assignment must survive (Wix category carries name + assigned events)."
-    }
-  ],
-  "reliability": {
-    "status": "unknown",
-    "flags": []
-  },
-  "mappingGuidance": [
-    "Create categories first, then assign events to them by ID — assignment happens on the category, not the event.",
-    "Wix Events categories are flat: flatten hierarchical source taxonomies and record the faithfulness-ledger entry."
-  ],
-  "setupRequirements": [
-    "Wix Events app"
-  ],
-  "pitfalls": [
-    {
-      "code": "flat-categories",
-      "severity": "warning",
-      "summary": "Wix Events categories are flat; a hierarchical source event taxonomy (tribe_events_cat is hierarchical) flattens on import — faithfulness-ledger entry required."
-    }
-  ],
-  "notes": "Event categories have a native Categories API (dev.wix.com Events > Event Management > Categories); do not map them to CMS. Docs-verified only; exercise live before confirming.",
-  "evidence": [
-    {
-      "type": "wix-docs",
-      "url": "https://dev.wix.com/docs/api-reference/business-solutions/events/event-management/categories/category-object"
-    },
-    {
-      "type": "review-decision",
-      "path": "anonymized-live-verification"
-    },
-    {
-      "type": "live-run",
-      "path": "anonymized-live-verification",
-      "note": "Verified live: create + query-back readback, safe mode on — 3/3 categories created via POST /events/v1/categories, server IDs crosswalked; assignment-to-events not exercised (events stayed drafts)"
-    }
-  ]
-}