| name | curate-golive-data |
| description | Use before go-live to make the data a Spryker project is keeping production-safe — real tax rates instead of placeholders, the customer's own imagery instead of Spryker-CDN URLs, demo accounts/passwords removed or rotated, remaining demo leftovers cleared, integrity re-verified. A late, standalone checklist on a project that already boots green; resolves the go-live warnings project-data and boot-and-verify surface. Not infra/deploy hardening, not code. |
curate-golive-data
A go-live checklist, run late on a project that already boots green — not a project-start wizard step. It turns dev-adapted data (English copies, demo imagery, placeholder rates, demo accounts) into data a real shop can go live on, and closes the go-live liabilities project-data (adapt) flags and boot-and-verify lists at close. It curates data only — it is NOT infra/deploy hardening (that's configure-services) and NOT code.
Boundary vs project-data cleanup: this pass makes the data you're keeping production-safe (real rates, licensed imagery, rotated/removed demo passwords) at go-live. Removing a whole demo domain (drop all customers, all merchants) is the cleanup strategy in project-data, run any time. Rule of thumb: "make X real for launch" → here; "drop the demo X" → project-data cleanup.
You drive the spryker-import-tools scripts (csv.php + validate.php); you supply the judgment. Invocation + command discipline: follow spryker-import-tools → "Invocation & command discipline" (the authoritative copy) — literal-path invocation from the project cwd ($CSV/$VALIDATE below = that path, substituted inline; never a shell variable, never cd); one op over many files in one command with --in-place, no shell loops/operators; count via rowCount/matchedRows; explore with the built-in Read/Grep/Glob; every rm surfaced as a step. Destructive-op gate applies: any in-place row delete (which does NOT prompt on its own), reset, or clean-data — preview, announce in one line what it will destroy, and get an explicit yes first (full gate: spryker-import-tools → Invocation & command discipline; weight: boot-and-verify §3b). Never wipe unannounced. Work from real files.
The file/column names below are a KNOWN set, not exhaustive
As everywhere in this run, the names are the demoshop as observed — a starting point. Discover the real set by scanning data/import/** for the shape, scoped to the active manifest's bucket (the dirs full_<REGION>.yml imports); the tree also holds CI/fixture buckets (b2b_common/, robot/, b2b_robot/) the boot never reads — decide explicitly whether they are in the go-live bar.
Checklist
- Real tax rates. The demo ships placeholder rates keyed by country (
tax.csv: country_name, tax_rate_percent, tax_set_name). Confirm every go-live country has its correct statutory rate (rates are developer-supplied — never invent one). Set per country with php "$CSV" set tax.csv --column tax_rate_percent --value <rate> --where country_name=<X> --in-place (the --where is required — without it set overwrites every country's rate), or edit the anchored rows. A demo country left in the file (a rate for a country you don't sell to) is leftover — remove it.
- Customer imagery — PRESENCE first, then substance. A URL-replacement sweep passes a
product_image.csv with zero rows: there is no cloudfront URL left to find, so "0 hits" reads as a clean sweep when in fact every product renders "No image available". Assert presence before touching any URL.
- (a) Presence — every product has an image row, in every project locale.
product_image.csv is locale-ROW-keyed, so the bar is: for each project locale, one row per product with a non-empty external_url_small and external_url_large (the PLP renders small, the PDP large — one blank column breaks one surface only). Check: php "$CSV" count product_image.csv --plain (expect ≈ product count × project locales, never 0), php "$VALIDATE" required product_image.csv --column external_url_small --column external_url_large, and php "$CSV" distinct product_image.csv --column abstract_sku --plain compared against product_abstract.csv's SKUs to find products with no row at all. A catalog with zero (or partial) imagery is the single most demo-breaking gap there is and is a finding in its own right — never report it as clean. Same for category/CMS/merchant image columns.
- (b) Substance — de-CDN the URLs. Demo images point at the Spryker CDN —
product_image.csv external_url_small/external_url_large carry *.cloudfront.net URLs (find with columns --plain; category/CMS/merchant images carry the same). Replace with the customer's asset URLs (developer-supplied — never fabricated): php "$CSV" replace <all image files> --column <url-col> --search '#^https://[^/]+\.cloudfront\.net/#' --with '<customer-base>/' --regex --in-place, or set explicit per-row URLs. Verify none remain (step 7 sweep). Generated SVG placeholders from a run are the same debt — they are not customer imagery.
Apply & verify
Pre-boot edits import on the next boot. On a running project, reflect changes via the iteration ladder in boot-and-verify §3b — targeted data:import -c for adds/edits, reset for deletions/value changes — then drain the queues and re-verify per store (imports emit events automatically; publish:trigger-events only to recover an out-of-sync read model) (boot-and-verify step 4, reusable standalone). Report what was curated and any remaining developer-supplied inputs still owed (real rates, real asset URLs, translations).
Not here
Infra/deploy hardening (configure-services). Real translation mechanics ([[translate-content]]). Reshaping demo data to stores/locales/currencies, and catalog reduction ([[project-data]] — adapt / reduce strategies). Code changes. Named gap — config fallback secrets: this skill is data-only, so hardcoded fallback secrets in config (e.g. the shipped fallback encryption key in config/Shared/config_default.php) fall between this checklist and configure-services' deploy-file scope — recommend the team grep config for fallback secrets (?: 'change patterns, default keys) as part of their go-live hardening, and say explicitly that no skill in this plugin owns it.
