---
name: evolution-shopify-headless-sow
description: New headless Shopify Plus + Strapi project for an existing Evolution customer — scope of work and key boundary decisions
metadata: 
  node_type: memory
  type: project
  originSessionId: 652d6749-d3fb-4b48-b8db-1d21c10d0cf5
  modified: 2026-07-23T00:48:09.956Z
---

An existing Evolution customer retained a separate agency to build a headless Shopify Plus
storefront + Strapi CMS. This is a **new, second Shopify store** for that customer (not a rebuild
of their current one). Evolution's responsibility is limited to the data plane — categories,
master products/variants, and B2B contract pricing — pushed into Shopify via the Admin/GraphQL
API on an **ongoing sync** basis (not a one-time migration). Shopify itself is the handoff point;
Strapi/storefront consumption of that data is the agency's problem, not ours.

Decision made 2026-07-23: reuse and extend the existing `plugins/shopify/plugin.php` integration
rather than build a parallel one. Full scope of work drafted at
`evolution/audits/SHOPIFY_HEADLESS_STORE_SOW.md`, grounded in how the plugin actually works today
(verified by reading `plugin.php`, not assumed):

- The plugin is **not** multi-store-ready out of the box — `webhook.php`/`cron.php` resolve
  "which store" via a single global "current store" meta flag, and `cron.php` hardcodes tenant db
  `85-1384947162`. Making it store-aware per request is the first, blocking piece of work.
- Evolution has **no master/variant schema concept** — grouping inventory rows into one Shopify
  product with variants is currently done by hand at publish time. The new store's initial catalog
  load needs an explicit grouping rule worked out with the customer first.
- Category → Collection sync is flat today (`categories.parent` hierarchy is ignored) — nested nav
  is an open question for the agency, not yet decided.
- Since this work touches `webhook.php`'s store-resolution code anyway, the SOW recommends landing
  the known-critical unauthenticated-webhook fix (finding W1 in [[plugin_security_review]]'s
  sibling doc `SHOPIFY_PLUGIN_FULL_AUDIT.md`) in the same pass rather than shipping a second
  vulnerable endpoint.

**Why this matters:** if asked to help implement or re-scope this project, start from
`SHOPIFY_HEADLESS_STORE_SOW.md` §7's open questions (single-store-vs-second-channel ambiguity,
nested collections, which clients are in scope, live inventory/SEO needs) — several core
assumptions are still unconfirmed with the customer/agency as of this writing.