qa-seed-data

name	qa-seed-data
description	[Testing] Seed/teardown ALL test data — catalogs, products, pricing, inventory, B2B orgs/users, configurable products, loyalty, promotions, BOPIS — on ANY environment (TEST_ENV) via repo seed scripts (npm run seed) or Postman MCP; verify with td:reconcile
argument-hint	[bootstrap|minimal|catalog|b2b|pricing|inventory|loyalty|promotions|bopis|configurable|users|full|teardown]
disable-model-invocation	true

/qa-seed-data — Test Data Generation & Teardown

Single entry point for seeding every kind of test data this repo needs — and for tearing it down — on any environment (fresh /qa-local-env localhost, vcst, vcptcore, virtostart, a customer env; selected by TEST_ENV). Covers two execution paths (script-based and Postman MCP), the full test-data/ fixture surface, and the specialized one-purpose seeders.

Environment-agnostic + self-verifying (VCST-5406): npm run seed:bootstrap warms the member index + ensures one bridge fulfillment center, then runs every phase — each its own common script — in an explicit priority order (STEPS[].priority in seed-bootstrap.mjs, sorted, not array-position): Catalog(10) → Categories(20) → Properties(30) → Products(40) → Configurable(50) → Prices(60) → Inventory(70) → Store(80) → BOPIS(90) → Company-users(100) → Promotions(110) → Loyalty(120) → White-labeling(130). Prices run after both products and configurable so everything is priced; the store is finalized after inventory so its FFC roles resolve. The same command works on an empty DB or a populated env. Seeders read the entity back after create (verifyCreated) and each teardown asserts zero residue (verifyRemoved). Confirm any env with npm run td:validate (static @td() gate) + npm run td:reconcile (live: catalog root, .env.{ENV} user roles, B2B org-scoped memberships with no global roles, secret hygiene).

One tear-down-for-all: npm run seed:bootstrap:teardown sweeps every domain in reverse dependency order (mirror of the seed chain). Teardown safety — deletes ONLY AGENT-TEST entities: every seeder scopes deletion to its own fixtures (by AGENT-TEST name prefix, exact seed email, own catalog, or bookkeeping id) and every product delete uses the non-empty objectIds field (an empty ObjectIds on POST /api/catalog/listentries/delete wipes the whole catalog — never do that). All seed catalogs/categories carry stable AGENT-TEST-SEED- names (no date stamp) so separate phase processes resolve the same entities and re-runs don't sprawl orphan catalogs. Entities seeded before a name change (e.g. a rename to add the prefix) are treated as real data and NOT swept — flush them on a fresh-DB re-provision.

Seeding Tooling — Two Execution Paths

Pick the path by what you're seeding. Both end with the same obligation: write seeded IDs back into test-data/ so @td() resolves (Step 6 below).

Path A — Repo seed scripts (direct REST/xAPI) — the practical default

Node seeders in scripts/seed-data/ read CSVs from test-data/, call the platform API directly, are idempotent (look-up-then-create), respect TEST_ENV (via config.js / seed-common.mjs, with per-env _${ENV} secret-suffix promotion), are gated by ENV_RISK (config, not hostname — blocks production, runs on any dev/test/staging/localhost/customer env), and — where an entity's runtime GUID is consumed by @td() — write those ids to test-data/aliases.{env}.json (per-env override; everything else resolves by static business key from the committed CSVs). No _seed-results-*.json reports (VCST-5406) — the legacy seed-test-data.js orchestrator is the sole exception. No Postman/Newman needed.

Script	Seeds	Invoke	Write-back
seed-bootstrap.mjs	⭐ Any-env orchestrator. Preflight (member index + one bridge FFC) then every phase as its own common script in explicit priority order (catalog → categories → properties → products → configurable → pricing → inventory → store → bopis → company-users → promotions → loyalty → white-labeling). Required steps abort on failure; optional steps warn (e.g. loyalty module absent). --teardown = reverse-order tear-down-for-all.	npm run seed:bootstrap ([--dry-run] [--verbose] [--skip-optional]) · npm run seed:bootstrap:teardown	(child seeders write their own)
seed-catalog.mjs	Catalog phase (priority 10). Thin wrapper over shared ensureCatalogs() in seed-common.mjs: creates the physical + virtual catalogs from test-data/catalogs/catalogs.csv with stable AGENT-TEST-SEED- names, links virtuals to their physical sources, binds the store to its virtual catalog. Idempotent.	npm run seed:catalog-structure ([--dry-run])	aliases.<env>.json (CATALOG_* + VIRTUAL_CATALOG_B2B)
seed-catalog-categories.mjs	Categories phase (priority 20). Thin wrapper over shared seedCategoryTree(): builds the category hierarchy from test-data/catalogs/categories.csv (stable codes, parents first), links each catalog's root categories into the store virtual catalog. Self-resolves catalogs; idempotent.	npm run seed:categories ([--dry-run])	—
seed-store.mjs	Store phase (priority 80). Thin wrapper over shared ensureStore() (extracted from seed-test-data.js so both paths build ONE store from test-data/stores/stores.csv — currencies + languages + settings + url + catalog binding + FFC roles). Run after inventory so FFC roles resolve. Idempotent.	npm run seed:store ([--dry-run])	— (store is not @td-id-referenced)
seed-test-data.js	Legacy relational seeder — no longer the default seed path. seed / seed:minimal / seed:catalog / seed:full now route to the unified seed-bootstrap.mjs + phase scripts (see below). This file is retained for its family-sweep teardown (seed:teardown — deletes every AGENT-TEST-SEED-* catalog + cascade; used by seed:bootstrap:teardown) and seed:dry-run.	npm run seed:teardown · seed:dry-run	_seed-results-{date}.json (legacy — sole _seed-results writer)
seed-standard-products.mjs	12 standard products — the test-products.csv rows flagged seeded=true (PROD_HEADPHONES, PROD_LAPTOP, PROD_OOS, PROD_LOW_STOCK, PROD_PACK_SIZE, PROD_TIER_PRICED + 6 loyalty ProductPoints SKUs); also discovers imported standard.csv STD-* fixtures. Config in standard-specs.mjs. Not the relational catalog (that's seed-test-data.js).	node scripts/seed-data/products/seed-standard-products.mjs [--dry-run] [--only PROD-001] [--teardown]	PROD_* resolve by SKU; STD-* runtime ids → aliases.<env>.json
seed-configurable.mjs	⭐ ONE consolidated seeder for every script-created configurable (CFG-012..032 + CFG-FILE) + child-option products. Full feature union in one spec table: Product/Text/File sections · per-option price/salePrice/stock(OOS)/quantity/isDefault · dependsOnSectionId cascades · parent base/sale price. Families: base (012–021,017,019,FILE), conditional (022–029), default (030–031), bike (032).	node scripts/seed-data/products/seed-configurable.mjs [--dry-run] [--only CFG-013] [--group base|conditional|default|bike] [--teardown]	aliases.{env}.json (product_id_guid + configuration_id)
seed-promotions.mjs	Marketing promotions + rewards + coupons from test-data/promotions/*.csv	npm run seed:promotions ([--dry-run] [--only P01] [--teardown])	— (COUPON_* static keys)
seed-bopis.mjs	BOPIS pickup locations from test-data/stores/bopis-locations.csv (vc-module-shipping; linked to an existing FFC)	npm run seed:bopis ([--only LOC-001] [--teardown])	— (static location keys)
seed-catalog-properties.mjs	Catalog/variation property definitions + dictionary values from test-data/catalogs/properties.csv	npm run seed:properties ([--only PROP-001] [--teardown])	— (not @td-referenced)
seed-white-labeling.mjs	Menu link lists + white-labeling org config from test-data/white-labeling/*.csv. Logo/secondary/favicon bytes are uploaded too — a row's *_source path (under test-data/, e.g. white-labeling/assets/electronics/logo.png) is POSTed to api/assets?folderUrl=customization[/favicons] (same endpoint as the admin blades) with its sibling {stem}_<size>.<ext> thumbnails (admin tile 64x64 + WL xAPI favicon set 16/32/96/128/196), so both surfaces render with zero 404s; idempotent (reuses an already-serving URL unless --reupload-assets). Orgs/users are NOT provisioned here — it delegates to seedWhiteLabelingUsers() in scripts/lib/user-provision.mjs (the SAME function seed-company-users.mjs's wl kind calls), reusing its orgMap for the WL config step so orgs are only ever seeded once per run.	npm run seed:white-labeling ([--skip-users] [--reupload-assets] [--teardown])	aliases.{env}.json
seed-company-users.mjs	ONE script for every company user (VCST-5406 — replaces the old seed-b2b-fixtures / seed-users / seed-impersonation-targets / seed-loyalty-users). CSV/env-driven over scripts/lib/user-provision.mjs. Kinds: all (default) · b2b (orgs parent-child + contacts + org-scoped logins + cross-org memberships) · imp (ORG-009…019 + blocked/invited targets, status-driven) · cross-org (organization-memberships.csv) · personal (env customer roles + agent-pool + test-users) · loyalty (VIP/Wholesale group) · wl (white-labeling orgs + users from test-data/white-labeling/*.csv, same org-scoped-role model — VCST-5028 — as b2b, incl. one user with a DIFFERENT role per org). Account status (Approved/Locked/EmailUnconfirmed) is data-driven from the users.csv status column. One unified --teardown sweeps ALL sources, including white-labeling, (no orphan gap).	npm run seed:company-users (b2b / personal / imp / wl via seed:b2b / seed:users / seed:impersonation / seed:wl; --teardown / --dry-run)	aliases.{env}.json (platform_id)

The seed / seed:minimal / seed:catalog / seed:full entry points now route to the unified seed-bootstrap.mjs + phase scripts (not the legacy seed-test-data.js monolith). All company users (B2B orgs/contacts/logins/memberships + personal + impersonation + loyalty + white-labeling) are seed-company-users.mjs. All configurable products are seeded by the single seed-configurable.mjs (families base/conditional/default/bike via --group); it imports seed-common.mjs and keeps each family's catalog/category/pricelist names for idempotency.

The newer seeders (seed-configurable, seed-promotions, seed-bopis, seed-catalog-properties, seed-white-labeling) share scripts/lib/seed-common.mjs — the common env-load / host-allowlist / auth / api() / CSV / write-back helper — and all support --dry-run (reads only, never writes), --verbose, --only <id>, and --teardown (deletes exactly the rows they seed). Reference-only test-data/ (payment cards, search queries, security payloads, uploads, GraphQL query library) and discovered/pre-existing infra (FFCs, stores, languages) intentionally have no seeder. All company-user account creation (B2B logins, cross-org members, personal accounts, impersonation targets, loyalty group users) is now covered by the single seed-company-users.mjs over scripts/lib/user-provision.mjs. test-data/b2b/roles.csv needs no seeder — it now mirrors the real storefront roles (vc-frontend core/constants/security.ts ALL_ROLES + real permissions.enum.ts keys; the 3 member_dropdown=yes rows are B2B_ROLES, the Company-Members "Change role" options). Those role IDs (org-maintainer/org-employee/purchasing-agent/store-admin/store-manager) are platform built-ins that already exist — the memberships seeder references them by id.

Path B — Postman MCP (collection-driven)

The 6-step workflow below builds a reusable Postman collection via MCP and executes it via Newman / Postman CLI. Use when you want a shareable, reusable seed collection or are already in a Postman-centric flow. The MCP cannot execute collections — execution is out-of-band (see /qa-postman/execution.md). Read /qa-postman first for auth, variable scoping, collection structure, and tool signatures.

Prefixes & teardown scope. All seeders share the AGENT-TEST-* family. Each seeder owns a matching teardown that verifies zero residue (verifyRemoved in seed-common.mjs): seed:teardown (catalog/product/pricing family — sweeps every prior AGENT-TEST-SEED-* run + legacy SEED-*), seed:company-users:teardown (unified — every company user: B2B orgs/contacts/logins/memberships + personal + impersonation + loyalty + white-labeling across all sources; seed:b2b:teardown / seed:users:teardown are back-compat aliases of it), seed:pricing:teardown, seed:inventory:teardown, seed:loyalty:teardown, seed:bopis:teardown, seed:products:teardown, seed:configurable:teardown. seed:teardown is scoped to its own family, so it does not delete the specialized .mjs fixtures (AGENT-TEST-CFG-*, B2B orgs, etc.) that carry pinned @td() IDs — run those domains' teardowns for that. Promotions are persistent (not swept by default; use seed:promotions --teardown). The Postman teardown profile sweeps the broader AGENT-TEST-* ephemeral set. Deleting a seed catalog cascades to its categories/products; price lists are swept by keyword.

Reference

Read before executing:

1. skills/qa-postman/SKILL.md — Postman MCP entry point (index of all sub-guides: mcp-tools.md, variables-and-environments.md, collections-and-requests.md, graphql-authoring.md, test-data-fixtures.md, execution.md, common-mistakes.md, examples.md)
2. skills/qa-seed-data/test-data-generation.md — Entity graph, API endpoints, request bodies, batch patterns, naming

Arguments

Argument	Description	Fastest backing tool
bootstrap	⭐ Any-env, from-scratch. Preflight (member index + bridge FFC) then all 13 phases as common scripts in explicit priority order; required steps abort on failure, optional steps warn. Use on a fresh /qa-local-env DB or to fully (re)seed any env. Tear down everything: npm run seed:bootstrap:teardown (reverse order, AGENT-TEST-only).	npm run seed:bootstrap ([--skip-optional]) · seed:bootstrap:teardown
catalog-structure / categories / store	Individual phase scripts (priority 10/20/80) — build the stable AGENT-TEST-SEED- catalog structure, category tree (roots linked into the virtual catalog), and the full store from stores.csv. All idempotent; normally run via bootstrap.	npm run seed:catalog-structure · seed:categories · seed:store
minimal	Unified required-only chain (seed:bootstrap --skip-optional) — catalog → categories → properties → products → pricing → inventory → store → company-users, skipping optional domains.	npm run seed:minimal
catalog	Unified catalog subset — the new phase scripts chained: catalog-structure → categories → products → pricing → inventory (stable AGENT-TEST-SEED- names).	npm run seed:catalog
b2b	Organizations (parent-child) + contacts + addresses, plus storefront logins + org-scoped role memberships (VCST-5028) + cross-org members	npm run seed:b2b (= seed-company-users.mjs b2b; cross-org only: npm run seed:b2b:memberships)
pricing	Price lists (USD + EUR), tiered prices, quantity breaks, multi-currency	npm run seed:pricing (seed-pricing.mjs; also folded into seed:catalog / seed:full)
inventory	Fulfillment centers + stock levels from test-data/inventory/*.csv (creates a default FFC on a fresh DB)	npm run seed:inventory (seed-inventory.mjs)
configurable	All configurable products (CFG-012..032 + CFG-FILE) via one consolidated seeder; :conditional, :default, :bike are --group filters of it	npm run seed:configurable (seed-configurable.mjs)
users	Personal storefront accounts from test-data/users/*.csv and the .env.{ENV} customer role identities (USER/USER2/EUR_USER/LOYALTY_*), created with the per-env password and read back to verify	npm run seed:users (= seed-company-users.mjs personal)
imp	Impersonation targets for IMP-048/049 (suite 082): ORG-009…019 + many-orgs/blocked/invited users, blocked & invited states data-driven from the users.csv status column	npm run seed:impersonation (= seed-company-users.mjs imp)
loyalty	Loyalty programs (Product Points + others) built from the platform's new/{programType} skeleton, with per-program product factors (a ProductPoints program earns nothing without them) and the VIP/Wholesale eligibility user groups + users	npm run seed:loyalty (seed-loyalty.mjs; VIP/Wholesale logins via npm run seed:loyalty:users = seed-company-users.mjs loyalty)
promotions	Marketing promotions + reward trees + coupons from test-data/promotions/*.csv	npm run seed:promotions (seed-promotions.mjs)
bopis	BOPIS pickup locations (vc-module-shipping) from test-data/stores/bopis-locations.csv, linked to an existing FFC	npm run seed:bopis (seed-bopis.mjs)
full	Seed every seedable fixture defined in test-data/ so every @td() reference across all suites resolves against live data. Now an alias for the unified seed:bootstrap (all 13 phases in priority order — catalogs, categories, properties, products, configurable, pricing, inventory, store, B2B orgs/contacts/users/roles, promotions/coupons, loyalty, white-labeling, BOPIS).	npm run seed:full (= seed:bootstrap)
teardown	Delete ephemeral seeded entities (each teardown verifies zero residue). npm run seed:teardown sweeps all prior AGENT-TEST-SEED-* runs (+ legacy SEED-*); run the per-domain teardowns for the specialized fixtures (seed:company-users:teardown — all company users; seed:products:teardown, seed:configurable:teardown, seed:bopis:teardown, seed:pricing:teardown, seed:inventory:teardown, seed:loyalty:teardown). See the prefix note above.	npm run seed:teardown (+ per-domain)
verify	Not a seed profile — the check after seeding. td:validate (static: every @td() resolves, no hardcoded GUIDs) + td:reconcile (live, per TEST_ENV: catalog root exists, .env.{ENV} user roles have accounts, B2B users are org-scoped with no global roles, no password literals in CSVs).	npm run td:validate · npm run td:reconcile

Workflow

Step 1 — Read Reference

Read test-data-generation.md for entity dependency graph, API endpoints, request bodies, and batch patterns.

Step 2 — Fast Path: Reuse Existing Collection

Use getCollections to check if a seed collection already exists for the requested profile.

Collection naming: VC Seed — {Profile} (e.g., VC Seed — Minimal, VC Seed — Full)

Exists?	Action
Yes	Skip to Step 5 — execute via Newman/Postman CLI immediately. No rebuild needed.
Yes, but outdated	Use putCollection to update in-place (1 call; needs the owner-qualified <OWNER>-<UUID>).
No	Continue to Step 3.

This is the #1 speed optimization. Building should only happen once per profile.

Step 3 — Environment

Reuse existing VC QA Environment or create one per ../qa-postman/variables-and-environments.md. Entity IDs go in collection variables (not environment).

Step 4 — Build Collection (Single Call)

Use one createCollection call with ALL requests inline (per ../qa-postman/collections-and-requests.md §1). Never use createCollectionRequest for seed collections — that's N MCP round-trips instead of 1.

Seed collection folder structure (entity order from test-data-generation.md §Entity Dependency Graph):

00-Auth           → OAuth2 token (per ../qa-postman/collections-and-requests.md §3)
01-Infrastructure → GET store, GET FFCs (verify + extract IDs)
02-Catalog        → Physical catalog, virtual catalog, categories
03-Products       → Products by type, variations, images
04-Pricing        → Price list + batch prices (single request — see §Batch API Patterns)
05-Inventory      → Batch inventory per product (see §Batch API Patterns)
06-Orgs-Users     → Organization, contacts, users, roles (if profile includes B2B)
07-Reindex        → Trigger all document types in 1 call + poll status
08-Verify         → GET assertions to confirm entities exist

For full: the folders above seed synthetic AGENT-TEST-* entities. To seed the entire test-data/ directory instead, follow test-data-generation.md §Full Profile — Seed All test-data/ Fixtures — its seed-order table maps every CSV-backed source to its entity + endpoint, flags reference-only sources, and requires idempotent look-up-then-create so pinned @td() IDs survive. CMS pages (UI-only) and order/quote-state fixtures (admin-transition) are seeded outside Postman by qa-frontend-expert/qa-backend-expert.

Teardown collection: same single-call approach, reverse dependency order (see test-data-generation.md §Teardown Collection).

Step 5 — Execute (out-of-band)

The Postman MCP cannot execute collections. Pick a runner — see qa-postman/execution.md for full details. Quickest path:

# Export collection + environment from Postman UI (or fetch via getCollection model=full + getEnvironment, then save)
npx newman run <seed-collection.json> -e <env.json> --reporters cli,json --reporter-json-export results.json

Or for an immediate run that surfaces in the Postman UI:

postman collection run <collection-uid> --environment <environment-uid>

After the run, capture the seeded entity IDs from the Newman/Postman result JSON and write them back into test-data/ so downstream suites can resolve them via @td() — see Step 6 and qa-postman/test-data-fixtures.md.

Step 6 — Report

## Test Data Seed Report

**Profile:** {profile}
**Environment:** {BACK_URL}
**Timestamp:** {ISO timestamp}
**Build:** {new | reused existing}
**Duration:** ~{X}s

### Created Entities
| Entity | ID | Name |
|--------|-----|------|
| Catalog | {id} | AGENT-TEST-Catalog-{date} |
| ... | ... | ... |

### Postman Collections
- Seed: {collection name} (ID: {id})
- Teardown: {collection name} (ID: {id})

### Verification
- [ ] Products visible via REST API
- [ ] Prices applied correctly
- [ ] Inventory levels set
- [ ] Search index updated

Expected Timing

Profile	Build (first run)	Build (reuse)	Execute	Reindex	Total
minimal	~10s	0s	~5s	~15s	~20-30s
catalog	~15s	0s	~15s	~30s	~30-60s
b2b	~10s	0s	~10s	~15s	~25-35s
loyalty	n/a (script)	—	~15-25s	n/a	~20-30s
promotions	n/a (script)	—	~10-20s	n/a	~15-25s
bopis	n/a (script)	—	~5-10s	n/a	~10-15s
full	~30s	0s	~2-4 min	~45-60s	~4-6 min (seeds the entire test-data/ directory; far heavier than the legacy "all profiles" full)

Profile Details

minimal

Fastest seed — single product with price and stock. Good for:

• Smoke testing a single CRUD workflow
• Verifying API connectivity
• Quick checkout flow (needs product + price + inventory)

Creates: 1 catalog, 1 category, 1 product (physical, full fields), 1 price list + prices, inventory at 1 FFC

catalog

Rich catalog for search/filter/browse testing:

• 1 physical catalog, 1 virtual catalog linked to store
• 3-level category tree (root → 2 subcategories)
• 5 products: 2 physical, 1 digital, 1 configurable (with 3 variations), 1 out-of-stock
• All products have full properties, SEO, descriptions
• Multi-currency prices (USD + EUR), tiered quantity breaks
• Inventory across 2 FFCs (varied stock levels)

b2b

B2B organization with user hierarchy (seed-company-users.mjs b2b):

• Base orgs (AcmeCorp/TechFlow/BuildRight/AcmeWest) + the imp orgs + contacts + addresses from test-data/b2b/*.csv
• Contacts re-linked to surviving platform users; org-scoped logins provisioned with status from the users.csv status column

cross-org kind (VCST-5028) — org-scoped roles & per-org access, from test-data/b2b/organization-memberships.csv:

• Ensures a contact + storefront login (security account) per user_email
• Creates one OrganizationMembership per (user, org) with its role_id → seeds cross-org members (same user in N orgs with distinct roles, e.g. TechFlow=maintainer + BuildRight=employee)
• Idempotent (reuses existing user/memberships); included in b2b/all; the unified teardown removes the seeded logins + memberships
• API contract: REST body uses userId + roles:[{roleId,roleName}] (NOT memberId/roleIds) — see reference_organization_membership_api_contract memory

pricing

Pricing module deep test:

• 2 price lists (USD, EUR)
• Assignments to catalog + store with priority
• Tiered prices: qty 1 (list + sale), qty 5, qty 10, qty 50
• Products reused from catalog profile (or created if run standalone)

loyalty

Loyalty programs for earn/redeem testing (seed-loyalty.mjs, VCST-5104/5135):

• Builds each program in test-data/loyalty/programs.csv from the platform's GET /api/loyalty-programs/new/{programType} skeleton (guaranteed-valid empty program), then applies per-row overrides: name, localized name, isActive, priority, store, start/end window, and the eligibility user group (all / VIP / Wholesaler via the dynamicExpression condition tree)
• Populates each program's product factors from test-data/loyalty/program-factors.csv (a ProductPoints program earns nothing without factors). Factors are resolved SKU→productId at runtime — no hardcoded GUIDs — via PUT /api/loyalty-program-product-factors/factors
• VIP/Wholesale storefront logins seeded by npm run seed:loyalty:users (= seed-company-users.mjs loyalty)
• Idempotent — a program whose name already exists is reused; factors are re-applied (PUT replaces the set, repairing factors without duplicating programs)
• Earning model: single highest-priority eligible+active+in-window program wins globally (no stacking) — see project_loyalty_productpoints_resolution_model memory. Balances cannot be reset via API (project_loyalty_balance_cannot_be_reset)
• Teardown: npm run seed:loyalty:teardown deletes AGENT-TEST-* loyalty programs

promotions

Marketing promotions for cart/coupon testing (seed-promotions.mjs):

• Promotions + reward trees + coupons from test-data/promotions/*.csv
• Reward set via GET-merge-PUT of dynamicExpression; relative date tokens resolved to ISO; coupons added via the separate POST /api/marketing/promotions/coupons/add (inline coupons[] is silently ignored — see reference_marketing_coupons_api_contract)
• Supports --only P01, --dry-run, --teardown

bopis

BOPIS (Buy Online, Pick up In Store) pickup locations (seed-bopis.mjs, vc-module-shipping):

• Pickup locations from test-data/stores/bopis-locations.csv, each linked to an existing fulfillment center (FFC discovered at runtime, not hardcoded)
• Covers store-selector / cart / checkout pickup suites (036–038)
• Supports --only LOC-001, --teardown

full

Seeds the entire test-data/ directory — not just the synthetic entities created by the other profiles. The goal is a platform state where every @td() reference in every regression suite resolves against live data. Use before full regression runs.

Seed each CSV-backed fixture in test-data/, in dependency order, preserving the IDs/codes/names the CSVs and aliases.json already pin (so existing @td() rows resolve without rewrites). Sources that are reference-only (payment cards, search queries, upload files, GraphQL query library, security payloads) are NOT seeded — they are consumed in place. The full mapping of each test-data/ source → platform entity → endpoint (and which are reference-only) lives in test-data-generation.md §Full Profile — Seed All test-data/ Fixtures.

Idempotency: the full seed must be re-runnable. For each fixture, look it up first (by pinned platform_id/code/name); create only if missing, otherwise update in place. A full run that 404s on a pinned entity should re-provision that row and write the new ID back into the CSV + aliases.json (see Step 6). It must NOT create duplicate copies of fixtures that already exist.

teardown

Scans for entities matching AGENT-TEST-* naming convention and deletes them in safe order. Does not remove the persistent test-data/ fixtures provisioned by full (catalogs, products, B2B orgs/users, promotions/coupons, etc.) — those keep their pinned IDs so @td() references stay resolvable across runs; teardown only sweeps the ephemeral AGENT-TEST-* entities created by individual tests. Also:

• Triggers search reindex after deletion
• Verifies cleanup (GET → assert 404)
• Reports any orphaned entities that failed to delete

Agents

Agent	Role
qa-backend-expert	Primary executor — authors Postman seed collections (via MCP), then executes them via Newman or the Postman CLI; writes seeded IDs back into test-data/
qa-frontend-expert	Verifies seeded data appears on storefront
test-management-specialist	References profiles when planning test coverage

Notes

• Never seed data into production — check BACK_URL against known production URLs before executing
• Always use AGENT-TEST- prefix — enables safe teardown without affecting real data
• After full seed, wait for search reindex before running storefront tests (~30-60s)
• If seed fails mid-execution, run teardown for the partial data before retrying
• For Postman troubleshooting (auth errors, variable resolution, ID format) — see qa-postman/common-mistakes.md
• After every successful seed, write the new entity IDs back into test-data/ (CSV files referenced by aliases.json) so downstream regression suites resolve them via @td() — see qa-postman/test-data-fixtures.md for the resolver contract
• Never hardcode environment GUIDs (catalog roots, store IDs, FFC IDs, virtual-catalog IDs) inside the seed collection or any helper script — read them from test-data/aliases.json (e.g. @td(VIRTUAL_CATALOG_B2B.id), @td(B2B_STORE.id)) or via the 01-Infrastructure discovery folder. See .claude/rules/test-data.md and feedback_no_hardcoded_guids_in_scripts.md.
• Inventory status matters. New products MUST be seeded with inventoryStatus: "Enabled" — xAPI addItem silently returns itemsCount=0 (no error) when status is Disabled, masquerading as a cart-layer bug. See test-data-generation.md §Inventory.
• Storefront visibility requires the B2B virtual catalog. A product in a fresh physical catalog returns 404 on the B2B storefront until it is linked into @td(VIRTUAL_CATALOG_B2B.id). Include the link step in 02-Catalog or 03-Products.
• Passwords come from .env, not the skill. The example bodies show TestPassword123!/TestPass123! for readability only — actual seed runs must read credentials from .env (ADMIN_PASSWORD, USER_PASSWORD) or test-data/users/agent-user-pool.csv for agent slots. See feedback_agents_read_env_creds.md + user_test_accounts.md.