@wix/agent-skills 1.36.0 → 1.36.1

package/skills/wix-vibe-headless/SKILL.md

@@ -1,183 +0,0 @@
----
-name: wix-vibe-headless
-description: "Connect an existing front end to a live Wix site using client-only REST and its public WIX_CLIENT_ID, without an SDK or backend. Covers Stores/cart/checkout, Bookings and Rentals, Blog, Events and tickets, Portfolio, Restaurants, Donations, Forms, CMS, Pricing Plans, and Members with login, social/SSO and gated content. Use when wiring Wix business data and buyer flows into a vibe-coded app, HTML/JSX/Vite project or design export: shopping, appointments, donations, form submissions, memberships, restaurant orders/reservations and member accounts. Ships dependency-free helpers and wiring guides; never provisions or changes owner content and never mocks data. Use wix-headless instead for SDK integration, Wix CLI builds, hosting or new-site creation."
----
-
-# Wix Vibe Headless — client-only REST connectors
-
-Wire an existing front end to a live Wix site **from the browser**, over the site's public
-`WIX_CLIENT_ID`, using hand-rolled REST — **no `@wix/sdk`, no backend, no build step, no
-dependencies**. One skill, one shared transport, and a copy-as-is REST layer per Wix
-business solution. Everything is **read-only over the owner's content**: render live Wix
-data or an honest empty state — **never mock, never provision, never invent** products,
-posts, events, menus, plans, reviews, or counts.
-
-## When to use this skill
-
-- The user has (or is building) a front end — a vibe-coded app, plain HTML/JSX, a Vite/React
-  project, a design-tool export — and wants it to show **live data from their existing Wix
-  site** and complete real purchases/bookings, all from the client.
-- They hand you a **public `WIX_CLIENT_ID`** and ask to "connect this to my Wix store /
-  blog / bookings / events / …".
-- They want to replace placeholder/mock data with real Wix content, or add a cart, checkout,
-  booking, RSVP, ticketing, reservation, form, or subscribe flow over an app they already have.
-
-## When NOT to use this skill
-
-| Scenario | Use instead |
-|---|---|
-| Build a **new** Wix site end-to-end from one prompt (discovery → design → build → host) | `wix-headless` |
-| The project should use the **Wix SDK** (`@wix/sdk`) and/or the **Wix CLI**, or be **hosted on Wix** | `wix-headless` |
-| Manage/configure the site via REST (install apps, seed catalogs, set up business solutions) | `wix-manage` |
-| Build a Wix **app extension** (dashboard page, widget, backend, plugin) | `wix-app` |
-
-This skill is the deliberately **client-only, REST-only** path. It is independent from
-`wix-headless` (which is SDK + CLI + hosting) — do not mix the two in one project.
-
-## The shared model (applies to every vertical)
-
-- **Auth = one public client id.** `WIX_CLIENT_ID` is a **buyer/visitor-facing** credential —
-  it only mints anonymous visitor tokens. It is **not a secret**; hardcoding and committing it
-  is fine. The user provides it (their vibe/host platform surfaces a copyable prompt with the
-  id filled in). Paste it into `wix-config.js` in place of the `<YOUR-CLIENT-ID>` placeholder.
-- **Money/price fields are objects, never scalars.** Every price/amount a Wix API returns —
-  Stores `price.actualPrice`, Bookings service `payment.fixed.price`, Events ticket
-  `registration.tickets.lowestPrice`, and the rest — has the shape `{ value, currency,
-  formattedValue }`. Render **`formattedValue`** (it already includes the currency symbol), or
-  fall back to building from `value` + `currency`. **Never** drop the object straight into the UI
-  or treat it as a number/string — that renders `[object Object]` or a bare unformatted number.
-  **Donations exception:** campaign prices use `{ amount, formattedAmount }`, with a decimal-string
-  `amount`; donation cart `options.amount` must instead be a JSON number. Follow the Donations recipe.
-- **Visitor token = identity.** `wix-client.js` mints an anonymous visitor token, persists the
-  **refresh token to `localStorage`**, and refreshes on expiry. That token IS the identity of
-  the cart / reservation / member session — **never re-mint anonymously per load** or the cart
-  silently empties.
-- **Member login swaps the token set on the same client.** The **members** vertical is *custom*
-  login — the front owns its login UI; the member is **never redirected to a Wix-hosted login page**.
-  On success it writes the member's tokens into the *same* store the visitor token used
-  (`setSessionTokens`), so **every subsequent `wixApiRequest` runs as the member** and the cart/session
-  carries over. "My …" surfaces (plans, orders, bookings, registrations) light up only once logged in.
-- **⚠️ Once you're building on Wix, keep it on Wix — auth, member data, and other business features
-  too.** If you're wiring a Wix storefront/blog/etc. over `WIX_CLIENT_ID`, prefer Wix for the *rest*
-  of the app as well, rather than reaching for a host platform's own backend or login. **Especially
-  for auth:** when the user wants members, log them in as a **Wix member** (`members` vertical) — don't
-  bolt on the host platform's auth. Likewise, member-generated content (likes, reviews, submissions,
-  "my …" lists) goes in a **Wix CMS collection** (`cms` vertical), not a host database.
-  - **The split-brain trap:** the most common failure is mixing the two — e.g. storing "likes" in the
-    host's DB while identifying the member from the Wix session (or logging in with Wix members but
-    keying data on a host user id). The two identities never match, ownership filters silently return
-    nothing (a like vanishes on refresh), and the data never sits with the rest of the Wix content.
-  - **Rule of thumb:** one store and one identity per feature. For a Wix-backed feature that's the Wix
-    member + the Wix collection, with ownership on Wix's server-stamped `_owner` (never a hand-stored
-    or host-supplied member id). Using a host backend for genuinely host-only data is fine — just
-    never straddle a single feature across both.
-- **Never mock, never provision.** These scaffolds are read-only over the owner's content. The
-  owner adds products/posts/services/events/menus/plans in the **Wix dashboard**. If a
-  collection is empty, show the empty state — never fabricate data, reviews, ratings, or counts.
-- **Purchases go through Wix.** Checkout/ticketing/plan purchase always complete via the Wix
-  redirect-session / Wix-hosted form — **never hand-build a `/checkout` or purchase URL**.
-- **Fail loudly.** The helpers throw on out-of-stock, empty carts, unbookable slots, expired
-  holds, and payment-still-owed. A green path means it really worked — don't swallow the error.
-- **Copy the shipped helpers as-is — don't rewrite their internals.** Wire your UI to the *exported*
-  functions; don't "refactor" or reimplement the helper bodies. Several Wix request shapes are exact
-  and easy to break (the members `createRedirectSession` body is the classic trap — a rewritten
-  version returns 400 and login dies). Extend by *calling* the exports or adding a new
-  `wixApiRequest` call for a genuine gap — never by editing the shipped ones.
-- **Beyond the snippets, look it up — never guess.** The templates and the shipped
-  `references/<vertical>/` helpers are the implementation — build from them first. When you hit a
-  genuine gap (a field, an endpoint, or an error the snippets don't cover), extend the client with
-  `wixApiRequest` — confirming the exact endpoint, method, and body first. **For that iteration and
-  troubleshooting** — finding the right endpoint, reading a method's request/response schema, or
-  diagnosing an API error — consult the official Wix API documentation using the documentation
-  skill available in your environment to search methods, read pages, and inspect API schemas.
-  Reference index: https://dev.wix.com/docs/api-reference.md
-- **Provide the user with deep links to the Wix dashboard**: In many cases, the user will need to modify the default vertical data in the Wix dashboard. Always provide the user with these links. The relevant information for each vertical's links is in its `INSTRUCTIONS.md` file.
-
-## How this skill is structured
-
-`<SKILL_ROOT>` is this file's directory (strip `/SKILL.md`). Each vertical supplies integration
-code under `references/<vertical>/app/`: REST helpers in `app/rest/`, and, depending on the
-vertical, utilities, hooks, context, components, or pages. All use the **shared transport** in
-`references/shared/app/` (`app/rest/wix-client.js` + `wix-config.js`, identical for every vertical).
-Set `WIX_CLIENT_ID` (and `WIX_METASITE_ID`) in `wix-config.js`. Deploying `references/<vertical>/app/`
-and `references/shared/app/` into the app's `src/` puts every file in place — the REST helpers land in
-`src/rest/`, so their relative imports resolve.
-
-**Where these files live in the app, and how they get there** (pre-installed at setup, or copied
-in) **is your platform's call — follow your platform instructions for that.**
-
-Each vertical's `INSTRUCTIONS.md` specifies its prerequisites, supplied pieces, exported interfaces,
-and the presentation you must build. **Read it before implementation**: reuse the supplied pieces
-and build the missing presentation without reimplementing shipped logic. Follow the platform's
-and vertical's completion guidance where provided.
-
-## Routing — pick the vertical(s) from the request
-
-Load the vertical(s) the user's app needs; a project may combine several (e.g. a restaurant
-with a blog, or a store with pricing plans).
-
-Each vertical's integration files ship in `references/<vertical>/app/`; copy that dir plus
-`references/shared/app/` into the app's `src/` (base44 does this at install via `deploy.cjs`).
-
-| The user wants… | Vertical | Read |
-|---|---|---|
-| Online store: products, categories, cart, checkout | **storefront** | `references/storefront/INSTRUCTIONS.md` |
-| Donations: fundraising campaigns, one-time or recurring giving, hosted checkout | **donations** | `references/donations/INSTRUCTIONS.md` |
-| Appointments: services, time slots, booking, checkout — **and the form attached to a bookable service** | **bookings** | `references/bookings/INSTRUCTIONS.md` |
-| Rentals: an item hired for a length **the customer picks** (by the hour or by the day) — Wix Rentals runs on the Bookings APIs, so it is the same vertical | **bookings** | `references/bookings/INSTRUCTIONS.md` ("Rentals") |
-| Blog/news: post feed, post pages, categories, tags | **blog** | `references/blog/INSTRUCTIONS.md` |
-| Events: browse, event page, RSVP, ticketing — **an RSVP is here, not `forms`**, even for one occasion with no tickets | **events** | `references/events/INSTRUCTIONS.md` |
-| Portfolio/showcase: collections, projects, media galleries | **portfolio** | `references/portfolio/INSTRUCTIONS.md` |
-| Restaurant: menu, online ordering, table reservations | **restaurants** | `references/restaurants/INSTRUCTIONS.md` |
-| Any visitor-fillable form: contact/enquiry, lead, signup, waitlist, application, feedback/survey, quote request, intake or registration. **Not** an event RSVP (`events`), per-service booking form (`bookings`) or donation contribution (`donations`) | **forms** | `references/forms/INSTRUCTIONS.md` |
-| CMS content: list/detail, filter/search, data CRUD. **A visitor-fillable form is `forms`** — cms only when the app must read the entries back | **cms** | `references/cms/INSTRUCTIONS.md` |
-| Plans & pricing: memberships/subscriptions, subscribe, my plans | **pricing-plans** | `references/pricing-plans/INSTRUCTIONS.md` |
-| Member accounts: custom login/sign-up (email+password, Google/Facebook, SSO), account area, gated content | **members** | `references/members/INSTRUCTIONS.md` |
-
-**⚠️ Anything a visitor fills in and submits is `forms` — with four exceptions:**
-
-1. **The app must read the entries back → `cms`.** A public gallery, a listing, a member's "my
-   submissions". A visitor cannot read Forms submissions, so those need a collection. Submit-only is
-   always `forms`: a form wired to `insertDataItem` works, but gives up the dashboard form builder,
-   spam protection, submission notifications and CRM contact mapping, and needs the owner to set
-   collection permissions by hand before anyone can submit at all.
-2. **Confirming attendance to an event or occasion → `events`.** A wedding, party or gathering —
-   events ships a built-in RSVP registration form. Route there even for a single occasion with no
-   tickets.
-3. **A form attached to a bookable service → `bookings`.**
-4. **A contribution to a donation campaign → `donations`.** Recurring giving is not a Pricing Plans purchase; the donation form must preserve the campaign's amount/frequency rules and use its catalog reference.
-
-### When the request doesn't name a Wix Business Solution — ask, or check the site
-
-Don't infer which Wix Business Solution to build (stores, bookings, blog, events, portfolio,
-restaurants, CMS, pricing plans, members, etc..) from a vague brief. **Ask the user** one short
-question — what do they offer (products? appointments? posts? events?) — or **check what the
-site actually has**: call a cheap read from each likely solution's helper (`queryProducts`,
-`queryServices`, `queryPosts`, `queryEvents`, …) — authenticated with a visitor token minted
-from the `WIX_CLIENT_ID`, or with an admin token if you have one — and build for the solutions
-that return real content. A `428` "app not installed" (blog: `401`) means
-that solution isn't on the site; sample-looking content ("Sample product 3") proves the app is
-installed, not what the business is about. Never default to store/bookings on silence.
-
-## The run
-
-1. **Get `WIX_CLIENT_ID`.** It comes from the user (the handoff prompt from their Wix/vibe
-   platform carries it). If it's missing, ask for it before wiring — nothing works without it.
-2. **Pick the vertical(s)** from the routing table — and when the request doesn't name any,
-   **ask or check the site** (see above) instead of guessing. Open each picked vertical's
-   `INSTRUCTIONS.md`.
-3. **Ensure the vertical's files are in place** — copy `references/<vertical>/app/` and
-   `references/shared/app/` into the app's `src/`, and set `WIX_CLIENT_ID` in `wix-config.js`. (Where
-   and how they get there is your platform's call — see its instructions. On base44 the install step
-   writes and verifies `wix-config.js` for you, so there's nothing to set by hand.)
-4. **Build the presentation and wire the integration** following the vertical's `INSTRUCTIONS.md`.
-   Reuse its supplied pieces through their documented interfaces, build the presentation it leaves
-   to you, and connect routes/providers as specified. Do not reimplement shipped logic. Style new
-   presentation using the existing platform theme.
-5. **Complete the applicable platform and vertical guidance**, including any required checks and
-   handoff instructions they provide.
-
-> Some flows need Wix-side setup the user completes later (payments connected, the deployed
-> domain allow-listed on the OAuth client for hosted-checkout return, collection permissions).
-> Those are out of scope here — if a call fails for that reason, flag it and continue; don't
-> fall back to mock data.

package/skills/wix-vibe-headless/install/deploy.cjs

@@ -1,221 +0,0 @@
-// Post-install deploy — run by base44.md STEP 1 with the vertical(s) the app needs:
-//   node deploy.cjs <vertical> [<vertical> …] --client-id <id> --metasite-id <id>
-//   (storefront | bookings | blog | cms | forms | portfolio | pricing-plans | events | members | restaurants | donations)
-// Pass the two ids from the prompt and this writes src/rest/wix-config.js for you — see WRITE below.
-// Retyping those ids into the file by hand is how a storefront ships with a dead client id.
-// ONE mechanism: recursively copy `app/` -> /app/src. The shared transport (app/rest/wix-client.js,
-// wix-config.js) is copied always; then each named vertical's app/ (its UI + app/rest/ helpers).
-// Deploy every vertical the app actually uses, in one call or across several — an app that needs both
-// members and cms names both, and its CMS helpers then come from the skill instead of being
-// hand-written. Order matters only where two verticals ship a file at the SAME path (both have
-// components/…, pages/…): the first one listed wins, since the copy never overwrites. Verticals whose
-// file sets don't overlap (cms and forms ship utils only, no UI) combine freely.
-// paths are the Base44 sandbox's /app. Re-running is non-destructive: it fills in only missing files,
-// never overwriting the agent's edits (see COPY), so a later call can add a vertical safely.
-// No vertical arg -> deploys just the shared transport; re-run with the vertical(s) once known.
-// NOTE: .cjs on purpose — the app is an ESM package ("type":"module"); a .js here would load as ESM
-// and require()/module.exports would throw.
-const { existsSync, cpSync, mkdirSync, readFileSync, writeFileSync } = require('fs');
-const { createHash } = require('crypto');
-
-const REF = '/app/.agents/skills/wix-vibe-headless/references';
-const WIX_CONFIG = '/app/src/rest/wix-config.js';
-const NAV_ADAPTER = '/app/src/lib/nav.js';
-const VERTICALS = ['storefront', 'bookings', 'blog', 'cms', 'forms', 'portfolio', 'pricing-plans', 'events', 'members', 'restaurants', 'donations'];
-
-// force:false + errorOnExist:false — fill in only files that AREN'T there yet; never overwrite.
-// A re-run (e.g. the "files missing? re-run" fallback) then restores what's missing without
-// clobbering the agent's edits (wired App.jsx, home/header components) from the first deploy.
-const COPY = { recursive: true, force: false, errorOnExist: false };
-
-// Only this exact shipped legacy transport is safe to replace. Any customization needs a merge.
-const LEGACY_TRANSPORT_SHA256 = '10d53e5e06ac3da62f93d41cfd618b6169c5bb1a5ba07fb58ec7700aad42889e';
-function prepareDonationsTransport() {
-  const src = `${REF}/shared/app/rest/wix-client.js`;
-  const dest = '/app/src/rest/wix-client.js';
-  if (!existsSync(src)) return { error: 'Donations needs the shared Wix transport. Reinstall the skill and retry deployment.' };
-  if (!existsSync(dest)) return { status: 'from_shared_tree' };
-  const existing = readFileSync(dest, 'utf8');
-  if (/^export const WIX_API_SUPPORTS_STRICT_PAYMENT_ERRORS = true;$/m.test(existing)) {
-    return { status: 'already_supported' };
-  }
-  if (createHash('sha256').update(existing).digest('hex') === LEGACY_TRANSPORT_SHA256) {
-    cpSync(src, dest, { force: true });
-    return { status: 'upgraded_unmodified_legacy' };
-  }
-  return { error: 'Donations was not deployed: src/rest/wix-client.js is customized or incompatible and was left unchanged. Merge strict payment-error support and the WIX_API_SUPPORTS_STRICT_PAYMENT_ERRORS export from the shared transport, then re-run deployment.' };
-}
-
-// --- members vertical only: replace leftover Base44 auth pages -------------------------------
-//
-// Base44 seeds src/pages/Login.jsx + src/pages/Register.jsx into every custom-auth-enrolled app
-// at APP CREATION, before any Wix skill ever runs (backend/app/user_apps/auth_templates/_loader.py
-// in the platform repo). The members vertical's own Login.jsx lands at that SAME path via the COPY
-// above, but COPY's force:false skips it because Base44's file is already there — so the Base44-auth
-// page silently survives instead of the Wix-auth one, and the app ends up with two half-wired auth
-// systems. There is no Wix Register.jsx at all (LoginForm's own "Sign up" tab covers registration),
-// so Base44's Register.jsx was never even in contention — it just sits there, wrong, either way.
-//
-// Fix both, but ONLY when the file currently on disk is still recognizably Base44's boilerplate
-// (imports base44Client / calls base44.auth.*). Never touch a file that's already the Wix version
-// or an agent's own customization — same "don't clobber" contract as COPY above, just evaluated on
-// content instead of mere existence.
-function isBase44AuthBoilerplate(path) {
-  if (!existsSync(path)) return false;
-  const src = readFileSync(path, 'utf8');
-  return src.includes('@/api/base44Client') || src.includes('base44.auth.');
-}
-
-// Each entry: the src/ file to repair, and the reference file that replaces it.
-// Login.jsx comes from the vertical's shipped pages; Register.jsx from references/members/install/
-// (a repair stub kept OUT of app/ — this vertical ships no /register route, so a fresh app with no
-// Base44 leftover must not receive it).
-const MEMBERS_AUTH_REPAIRS = [
-  { dest: '/app/src/pages/Login.jsx', src: `${REF}/members/app/pages/Login.jsx` },
-  { dest: '/app/src/pages/Register.jsx', src: `${REF}/members/install/Register.jsx` },
-];
-
-function replaceMembersAuthLeftovers() {
-  const result = {};
-  for (const { dest, src } of MEMBERS_AUTH_REPAIRS) {
-    const name = dest.split('/').pop().replace('.jsx', '').toLowerCase();
-    if (existsSync(src) && isBase44AuthBoilerplate(dest)) {
-      cpSync(src, dest, { force: true });
-      result[name] = 'replaced_base44_leftover';
-    } else {
-      result[name] = 'left_as_is';
-    }
-  }
-  return result;
-}
-
-// --- nav adapter --------------------------------------------------------------------------------
-//
-// Every shipped component imports Link/useParams/etc from "@/lib/nav", so one set of sources runs on
-// either Base44 template and the router is named in exactly one file. Which adapter belongs there is
-// a filesystem fact, so resolve it here rather than leaving the agent to infer the template and
-// hand-write the file: the react-router one is a re-export a model can guess, but the TanStack one
-// normalises useParams (strict:false) and useNavigate (object arg), and a guess breaks every page.
-//
-// The react-router adapter ships INSIDE shared/app/ (-> src/lib/nav.js), so it lands on every
-// install path, including hosts that copy that tree themselves and never run this script. Only the
-// TanStack override needs writing, and it goes down BEFORE the shared copy — that copy is
-// force:false, so whatever is at the path first wins.
-function detectTemplate() {
-  return existsSync('/app/src/routes/__root.jsx') ? 'tanstack' : 'react-router';
-}
-
-function installNavAdapter(template) {
-  if (template !== 'tanstack') return 'from_shared_tree';
-  const src = `${REF}/_shared/nav/nav.tanstack.js`;
-  if (!existsSync(src)) return 'adapter_missing_from_skill';
-  if (existsSync(NAV_ADAPTER)) return 'already_present';   // same don't-clobber contract as COPY
-  mkdirSync('/app/src/lib', { recursive: true });
-  cpSync(src, NAV_ADAPTER);
-  return 'written';
-}
-
-// --- WRITE the credentials ----------------------------------------------------------------------
-//
-// The two ids arrive as flags so this script writes them once, character-for-character, instead of a
-// later hand-edit of the placeholder file.
-//
-// An id already in the file wins; the flags only fill what is unset. A host that writes this file
-// at app creation (Base44) has each id as an exact value rather than a copy read out of a prompt.
-// Per id, so a host that resolved one but not the other still gets the gap filled.
-//
-// This briefly worked the other way round for WIX_METASITE_ID, while Base44 could write a different
-// site than the business: it shared one field between the launch and a metasite it provisions per
-// app, and the launch's id lost. Fixed on that side, and the ids it stores now verify against the
-// site each launch came from, so the file is trusted again.
-function readWixConfig() {
-  if (!existsSync(WIX_CONFIG)) return {};
-  const src = readFileSync(WIX_CONFIG, 'utf8');
-  const pick = (name) => {
-    const v = (src.match(new RegExp(`${name}\\s*=\\s*["']([^"']*)["']`)) || [])[1] || '';
-    return v.startsWith('<') ? '' : v;   // the shipped file's `<YOUR-…>` placeholders count as unset
-  };
-  return { clientId: pick('WIX_CLIENT_ID'), metaSiteId: pick('WIX_METASITE_ID') };
-}
-
-function writeWixConfig(clientId, metaSiteId) {
-  const body = [
-    '// Wix credentials — written by the skill\'s deploy step from the ids in your prompt.',
-    '// Safe to commit: WIX_CLIENT_ID is a public, buyer-facing id (it only mints anonymous visitor',
-    '// tokens); WIX_METASITE_ID just identifies the site.',
-    `export const WIX_CLIENT_ID = "${clientId}";`,
-    `export const WIX_METASITE_ID = "${metaSiteId}";`,
-    '',
-  ].join('\n');
-  writeFileSync(WIX_CONFIG, body);
-}
-
-// --- main ---------------------------------------------------------------------------------------
-
-// Accept one or many: `deploy.cjs members cms`. Duplicates collapse; order is preserved so the
-// first vertical listed wins any same-path file (the copy never overwrites).
-const argv = process.argv.slice(2);
-const flag = (name) => {
-  const i = argv.indexOf(`--${name}`);
-  return i !== -1 && argv[i + 1] && !argv[i + 1].startsWith('--') ? argv[i + 1] : null;
-};
-const clientId = flag('client-id');
-const metaSiteId = flag('metasite-id');
-// Verticals are the positional args — drop the flags and their values.
-const flagArgs = new Set(['--client-id', '--metasite-id', clientId, metaSiteId].filter(Boolean));
-// `rentals` is an alias of the Bookings vertical — Wix Rentals runs on the Bookings APIs. A rental
-// business picks `rentals` and gets the bookings scaffolds; it resolves to bookings everywhere.
-const ALIASES = { rentals: 'bookings' };
-const positional = argv.filter((a) => !flagArgs.has(a));
-const requested = [...new Set(positional.map((a) => ALIASES[a] || a))];
-const deployed = { verticals: [] };
-// Report any alias resolution so the caller sees an intended mapping (rentals -> bookings), not a
-// silent `bookings` result it might read as "rentals unsupported" and wastefully re-deploy.
-const aliased = [...new Set(positional.filter((a) => ALIASES[a]))].map((a) => `${a} -> ${ALIASES[a]}`);
-if (aliased.length) deployed.aliased = aliased;
-
-const donationsTransport = requested.includes('donations') ? prepareDonationsTransport() : null;
-if (donationsTransport?.error) {
-  deployed.error = donationsTransport.error;
-  process.exitCode = 1;
-} else {
-  if (donationsTransport) deployed.donationsTransport = donationsTransport.status;
-
-  // Nav adapter — before the shared copy, which carries the react-router default at the same path.
-  deployed.template = detectTemplate();
-  deployed.navAdapter = installNavAdapter(deployed.template);
-
-  // Shared transport — always (app/rest/wix-client.js, wix-config.js -> src/rest/, lib/nav.js).
-  if (existsSync(`${REF}/shared/app`)) cpSync(`${REF}/shared/app`, '/app/src', COPY);
-
-  // Each named vertical — its app/ (UI + app/rest/ helpers) -> src/.
-  const unknown = requested.filter((v) => !VERTICALS.includes(v));
-  for (const vertical of requested.filter((v) => VERTICALS.includes(v))) {
-    if (!existsSync(`${REF}/${vertical}/app`)) continue;
-    cpSync(`${REF}/${vertical}/app`, '/app/src', COPY);
-    deployed.verticals.push(vertical);
-    if (vertical === 'members') deployed.authPagesFixed = replaceMembersAuthLeftovers();
-  }
-
-  if (unknown.length) {
-    deployed.error = `unknown vertical(s) ${unknown.map((v) => `"${v}"`).join(', ')} — expected: ${VERTICALS.join(', ')}`;
-  }
-  if (!requested.length) {
-    deployed.note = 'no vertical given — deployed the shared transport only; re-run: node deploy.cjs <vertical> [<vertical> …]';
-  }
-
-  const onDisk = readWixConfig();
-  const finalClientId = onDisk.clientId || clientId;
-  const finalMetaSiteId = onDisk.metaSiteId || metaSiteId;
-
-  if (!finalClientId || !finalMetaSiteId) {
-    deployed.wixConfig = 'skipped — no ids provided';
-  } else if (finalClientId === onDisk.clientId && finalMetaSiteId === onDisk.metaSiteId) {
-    deployed.wixConfig = 'already_set';
-  } else {
-    writeWixConfig(finalClientId, finalMetaSiteId);
-    deployed.wixConfig = 'written';
-  }
-}
-
-console.log(JSON.stringify(deployed));

package/skills/wix-vibe-headless/install/pin-agents-md.cjs

@@ -1,35 +0,0 @@
-// Pin the skill location + project facts into /app/AGENTS.md so later turns (after the platform
-// build doc leaves context) still know the rules. Idempotent — safe to re-run; writes at most once.
-// Run once by base44.md STEP 1, separately from per-vertical deploys (deploy.cjs), so "copy a
-// vertical's files" and "record the project's ground rules" stay independent concerns.
-// .cjs on purpose — the app is an ESM package ("type":"module"); a .js here would load as ESM and
-// require()/module.exports would throw.
-const { existsSync, readFileSync, appendFileSync } = require('fs');
-
-const NOTE = `
-
-## This app — a Wix-managed headless frontend (built with the Wix skills)
-
-This project is the **frontend for a Wix-managed business** — a REST client that talks directly to a live Wix site over \`WIX_CLIENT_ID\`. The **Wix site is the source of truth** for all content and commerce; build and seed it only through the Wix connector and the skills below. **Do NOT use the Base44 commerce kit (or any Base44 solution kit).**
-
-The Wix skills live under \`.agents/skills/\` — on ANY turn, read them from that exact path (ignore stray copies like \`agent/skills/\`).
-
-- \`wix-vibe-headless\` — **how the CLIENT is built AND how the site is seeded**: your vertical's UI client + REST scaffolds are already deployed into \`src/\`; one vertical per capability under \`references/<vertical>/\`, each with a \`seed/\` module that creates content over the connector:
-  - **storefront** — sell physical or digital products online.
-  - **bookings** — let customers book appointments or services with your business.
-  - **blog** — publish articles for visitors to read.
-  - **forms** — any visitor-fillable form: contact/enquiry, lead, signup, waitlist, application, feedback/survey, quote request, intake or registration. **Not forms** — an event or occasion RSVP is **events** (built-in RSVP registration form), and a per-service booking form is **bookings**.
-  - **cms** — model and serve your own custom, structured content — for anything the other verticals don't cover. **Not cms** — a visitor-fillable form is **forms**; reach for cms only when the app must read the entries back.
-  - **portfolio** — showcase creative work in collections and project pages.
-  - **pricing-plans** — sell memberships or subscriptions to your service.
-  - **events** — publish events and handle RSVPs or ticket sales.
-  - **members** — let visitors create an account and sign in — this is **auth**.
-  - **restaurants** — publish a menu, take online orders, and manage table reservations.
-- **Documentation fallback** for **frontend code**, **backend code**, or **runtime / API management operations** alike: consult the official Wix API documentation using the documentation skill available in your environment.
-`;
-
-const amd = '/app/AGENTS.md';
-const cur = existsSync(amd) ? readFileSync(amd, 'utf8') : '';
-const pinned = !cur.includes('Wix-managed headless frontend');
-if (pinned) appendFileSync(amd, NOTE);
-console.log(JSON.stringify({ agentsMdPinned: pinned }));

package/skills/wix-vibe-headless/platforms/README.md

@@ -1,26 +0,0 @@
-# Vibe platform handoff prompts
-
-One file per AI-builder platform (Base44, Lovable, Bolt, v0, Manus, …). Each file is the
-**handoff prompt** the Wix Headless funnel hands to that platform after it creates the site +
-OAuth app: build the client, then seed/manage the business.
-
-`generic.md` is the **platform-agnostic** version and the default/fallback for any platform without
-its own tuned file. It is also a **lens over the skill**: the skill's `SKILL.md` + per-vertical
-`INSTRUCTIONS.md` are written for Base44's stack (Vite + react-router + `.jsx`, files pre-copied into
-`src/`), so `generic.md` tells a non-Base44 agent what the skill's three real assets are (the `rest/`
-client layer, the field-shape/route-pattern data contract, the `seed/` functions), which Base44-isms
-to ignore/translate, and the hard rule to **generate into the existing stack — never convert the
-framework**. `base44.md` is the Base44-specific one (its exec tool, secret store, pre-configured
-connector, `deploy.cjs` copy path, etc.).
-
-These are hosted (served at `https://www.wix.com/skills/vibe-headless/platforms/<platform>.md`)
-so the funnel loader can pass a short pointer to the prompt instead of inlining the whole
-script into the launch URL. Inlining tripped the Base44 edge WAF, which scans the POST body
-for command-injection patterns (`curl … | tar`, `require('child_process')`, etc.); a plain
-GET of a hosted file is not scanned that way.
-
-**Loader contract:** the funnel sends a short prompt that names the business, passes the Wix
-client id + metasite id, and points here — e.g. "Build a site for my Wix managed business:
-&lt;business&gt;. Then fetch and follow https://www.wix.com/skills/vibe-headless/platforms/base44.md
-exactly." The dynamic bits (business description, client id, metasite id) stay in the loader
-prompt; everything static lives in these files.

package/skills/wix-vibe-headless/platforms/base44-ecom-light-seed-with-install.md

@@ -1,127 +0,0 @@
-# Wix Managed Headless — Base44 storefront client + seed
-
-You are building a **Wix Managed** headless storefront inside Base44 — the business is described in your
-initial prompt, and the Wix connector is already configured.
-
-The shipped client is already configured. Use its documented hooks and components; no ID lookup
-or configuration changes are needed.
-
-> **The Wix skills installed below are the complete build and seed path for this app.** **Do NOT use the Base44 commerce kit (or any Base44 solution kit).**
-
-**Banner disabled for this entry flow:** do not add `<WixManageBanner/>`; skip the shared
-storefront instructions' optional banner integration.
-
-Follow STEPs 1–4 below exactly. Fire product image generations first, then build the client
-(STEP 2), and seed (STEP 3) **after** the client is built — generation finishes while you build.
-
-## STEP 1 — Install the Wix skills and deploy the storefront vertical to the app
-
-Install three skills — they land under `.agents/skills/`:
-- **`wix-vibe-headless`** — storefront build instructions, hook/component contracts, and seeding modules.
-- **`wix-manage`** — REST recipes for managing and configuring the Wix site.
-- **`wix-base44-connector`** — Wix connector usage, API contracts, and documentation discovery.
-
-
-Run this through exec_tool, exactly as written — installs all three skills, deploys the `storefront` REST scaffolds + UI into `src/` (the nav adapter at `src/lib/nav.js` among them), and pins the AGENTS.md note. **Its `deploy` result reports this app's `template`** — `react-router` wires routes into `src/App.jsx`, `tanstack` mounts them as files under `src/routes/`; see [`../references/_shared/routing.md`](../references/_shared/routing.md).
-
-```js
-const { execSync } = require('child_process');
-const { existsSync, readdirSync } = require('fs');
-const results = {};
-for (const skill of ['wix-vibe-headless', 'wix-manage', 'wix-base44-connector']) {
-  if (existsSync(`/app/.agents/skills/${skill}/SKILL.md`)) { results[skill] = 'already_installed'; continue; }
-  try {
-    const out = execSync(`CI=1 npx -y skills add wix/skills/skills/${skill} --yes 2>&1`,
-      { cwd: '/app', timeout: 60000, shell: '/bin/bash' }).toString().replace(/\x1b\[[0-9;]*m/g, '');
-    results[skill] = /installed 1 skill|found 1 skill/i.test(out) ? 'success'
-      : out.includes('No valid skills') ? 'not_found' : 'unknown';
-  } catch (e) { results[skill] = 'error: ' + e.message; }
-}
-const deploy = execSync(`node /app/.agents/skills/wix-vibe-headless/install/deploy.cjs storefront`, { cwd: '/app' }).toString();
-const agentsMd = execSync(`node /app/.agents/skills/wix-vibe-headless/install/pin-agents-md.cjs`, { cwd: '/app' }).toString();
-return { results, installed: readdirSync('/app/.agents/skills'), deploy: JSON.parse(deploy), agentsMd: JSON.parse(agentsMd) };
-```
-
-## STEP 2 — Build the client
-
-Read `.agents/skills/wix-vibe-headless/references/storefront/INSTRUCTIONS.md` and follow it **EXACTLY** — the single source of truth for how the storefront client is built.
-
-The shipped storefront provides catalog, cart, and checkout. Identify the additional workflows
-in the user's request and implement them alongside the storefront. If a workflow needs an
-external service or missing information, continue the work you can complete and identify the
-remaining dependency.
-
-For code or actions not covered by this skill, read and follow the installed connector skill at
-`.agents/skills/wix-base44-connector/SKILL.md` to find Wix documentation and APIs.
-
-Build the client using the component outlines, interfaces, and theme guidance in `INSTRUCTIONS.md`.
-The shipped files are already deployed and configured; you do not need to read their source or
-rebuild them. If you encounter an error after building the client, read or change whatever you
-need to diagnose and fix it.
-
-## STEP 3 — Seed the storefront
-
-**Never delete or clean up anything on the user's site — seeding is additive only.** It's a live
-user-owned business, so never delete or overwrite existing content, even apparent sample data. If a
-cleanup truly seems needed, ask the user first.
-
-Seed by calling the storefront's ready-made seed module, `seed-store.cjs` — `require()` it and use its
-one-call `setupStore` (build-time exec_tool). Read
-`.agents/skills/wix-vibe-headless/references/storefront/seed/SEED.md` for the full `setupStore`
-contract — the `ctx` and the product/category shapes.
-
-```js
-const seed = require(require("path").resolve(".agents/skills/wix-vibe-headless/references/storefront/seed/seed-store.cjs"));
-const result = await seed.setupStore(ctx, { products, categories }); // one call: install → products → categories → images
-```
-
-For code or actions not covered by this skill, read and follow the installed connector skill at
-`.agents/skills/wix-base44-connector/SKILL.md` to find Wix documentation and APIs.
-
-**Auth for these admin calls is the already-configured Wix headless connector — nothing else.** Get its
-access token and send it as a bearer token:
-
-```js
-const { accessToken } = await base44.asServiceRole.connectors.getConnection("wix");
-// then: fetch(url, { headers: { Authorization: `Bearer ${accessToken}`, "Content-Type": "application/json" }, ... })
-```
-
-Inline via exec_tool, `base44` is already declared — use it directly; do **not** import
-`@base44/sdk`, re-declare it, or call `createClient()` (that's for standalone `.js` files only;
-inline it throws *"Identifier 'base44' has already been declared."*).
-
-**Product images.** Fire every `generate_image` **before you build the client**, and seed **after**
-it — generation finishes while you build, so by the time you write the seed call your images are
-ready: each finished result now reads `status: "completed"` with its final
-`https://media.base44.com/...` url. Read every `imageUrl` from the results **as they read at that
-moment** — not from what they said when you called the tool — and pass them in the single
-`setupStore` call. A result without a final url by then (still running, or failed) → seed that
-product **without** `imageUrl` and attach it afterwards with `attachProductImages`.
-
-## STEP 4 — Wrap up
-
-### Verify
-
-Verify **once, after the seed** — home, shop, and a product page against the populated catalog.
-
-Images that are still generating may show `/__generating__/…` placeholders;
-the platform replaces these automatically at turn end, with a stock fallback if generation
-fails. You can finish without waiting for those images or replacing their placeholder URLs.
-
-### Final text response
-
-**Never paste a Wix dashboard link or path.**
-
-**Before writing your final text response, make one handoff call** — `search_base44_docs(query="how do I manage my store's products, orders, inventory and payments?", prefer_dashboard=true)`. Use its handoff guidance, note that the seeded catalog is mock data they can edit, replace or delete, and state any requested workflows that remain unfinished and what is needed to complete them.
-
-**A payment ask is a store ask.** The store carries its own checkout, in every region, so
-nothing separate connects payments and no payment provider is installed alongside it — send
-the user to the same dashboard page the handoff call names. A note that Base44 Payments /
-Wix Payments is unavailable in their region is about a provider installed into the app, and
-says nothing about their store's checkout.
-
-## Additional Wix functionality
-
-During the initial build or later, use the installed connector skill at
-`.agents/skills/wix-base44-connector/SKILL.md` to find Wix documentation and APIs for writing code
-or performing actions not covered by this skill.