Staging Demo Dataset and Seller Dashboard Readiness¶

Purpose and certification boundary¶

This package creates deterministic, synthetic data for Development and Staging. It makes seller dashboard, catalog, inventory, order, settlement, return, refund, and review states available for demonstration and data-level verification.

This is demo-data readiness, not seller E2E/UAT certification. Seeding rows through domain models does not prove the authorization, validation, browser/mobile, external payment, logistics, or operational paths used by a real seller and customer.

After a staging deployment, E2E/UAT must still exercise the real UI/API sequence:

Seller registration and KYC submission.
Admin review and approval.
Warehouse, listing, inventory, and activation.
Customer browse and cart.
PayU TEST checkout and backend verification.
Order confirmation, packing, ready-to-ship, shipping, and delivery.
Return, refund, settlement, and dashboard reconciliation.

[!CAUTION] The seeder reads the actual ASPNETCORE_ENVIRONMENT and DOTNET_ENVIRONMENT process variables. It rejects Production, missing, unknown, or conflicting values before any data write. Command-line and configuration values cannot downgrade that decision. SeedAsync independently enforces the same boundary for direct callers.

Exact deterministic inventory¶

Counts below describe the records owned by this package, not global database totals. Existing reference categories created by the baseline seeder are not counted again as staging additions.

Entity	Count
Root categories used by the package	8
Staging subcategories	13
Total package categories	21
Sellers	5
Customers	6
Staging audit administrators	1
Products	52
Product variants	21
Seller listings	52
Inventory rows	52
Orders	7
Seller orders	7
Verified payment transactions	6
Settlements	2
Returns	2
Refund transactions	1
Product reviews	2

Categories¶

The eight roots are Electronics, Clothing, Home & Garden, Beauty, Sports, Books, Toys, and Groceries. The package uses or creates these thirteen subcategories:

Smartphones & Tablets; Audio & Headphones; Computer Accessories
Men's Apparel; Women's Ethnic Wear; Footwear & Accessories
Kitchenware & Cookware; Coffee & Beverage Makers; Home Decor & Storage
Skincare & Serums; Haircare & Oils
Fitness Equipment; Sports Accessories

Personas and catalog¶

Seller	Dataset profile
`seller-a@staging.vayzomart.com`	14 active electronics listings; two delivered orders; one settled and one eligible settlement; two reviews.
`seller-b@staging.vayzomart.com`	12 active fashion listings with variants; one shipped and one confirmed order.
`seller-c@staging.vayzomart.com`	10 listings: eight active, one draft, one inactive; two low-stock and two out-of-stock rows; one cancelled order.
`seller-d@staging.vayzomart.com`	10 active personal-care listings; two delivered orders; one completed return/refund and one pending return.
`seller-e@staging.vayzomart.com`	Six active fitness listings and no orders, for an empty-dashboard baseline.

Six customer personas use the customer-*@staging.vayzomart.com namespace. All identities and addresses are synthetic. Products use STG-* SKUs and cover healthy, low, zero, inactive, and draft inventory/listing states.

Transaction scenarios¶

STG-ORD-001: delivered and paid; SET-STG-001 settled; one review.
STG-ORD-002: delivered and paid; SET-STG-002 eligible; one review.
STG-ORD-003: paid and shipped in transit.
STG-ORD-004: paid and confirmed for seller processing.
STG-ORD-005: cancelled before payment; intentionally has no payment transaction.
STG-ORD-006: delivered and paid; RET-STG-001 completed with one refund transaction.
STG-ORD-007: delivered and paid; RET-STG-002 remains requested.

Execution¶

The current VayzoMart staging architecture is Docker Compose. Run the one-off command inside the staging backend service or an equivalently isolated administrative container/process:

ASPNETCORE_ENVIRONMENT=Staging \
STAGING_SEED_PASSWORD='<INJECT_FROM_APPROVED_SECRET_STORE>' \
dotnet ECommerce.API.dll --seed-staging-demo

STAGING_SEED_PASSWORD (or the equivalent secret-injected Database:StagingSeedPassword key) is mandatory. There is no fallback password. It must be at least 16 characters and contain upper-case, lower-case, numeric, and special characters. Never put its value in source, tracked configuration, documentation, shell history, logs, or CI output.

Do not point the command at production. Do not use production credentials. The repository's Kubernetes example is intentionally omitted because the current staging deployment is Docker Compose; any future Kubernetes job requires a separate architecture and security review.

Idempotency and interruption recovery¶

The full seed runs in one database transaction. A process failure before commit leaves no partially committed seed run. For partial STG-ORD-001 through STG-ORD-007 graphs left by an older seeder, the package checks the required payment, settlement, return, refund, review, seller-order, and line counts. It atomically replaces only a known incomplete deterministic scenario, then converges to the inventory above. Complete scenarios are retained.

The deterministic order, seller-order, settlement, and return numbers have private domain setters. The staging seeder uses a tightly allowlisted reflection helper because the production domain does not expose a deterministic construction API. The helper accepts only those four entity/property pairs, validates the property type/setter, and fails loudly if the domain contract changes. Domain encapsulation is not widened for production code.

Audit provenance¶

The package creates demo-system-admin@staging.vayzomart.com as an ordinary synthetic staging Admin, not a SuperAdmin. That actor performs KYC approval, product-compliance approval, and settlement processing/settling in seeded audit metadata. Sellers never approve their own KYC and do not act as settlement administrators. The seeder does not bootstrap or modify any production SuperAdmin.

Verification checklist¶

Apply the real EF migration chain to an isolated disposable MySQL 8.x database.
Run the seed twice and compare all inventory counts.
Confirm unique emails, SKUs, order numbers, settlement numbers, and return numbers.
Remove selected dependent rows in the disposable database and rerun to prove convergence.
Query each seller dashboard and verify seller isolation and expected empty/low-stock/return states.
Run the full non-MySQL backend suite and the complete mysql-smoke suite.
Run frontend tests, lint, and build.
Run diff, conflict-marker, and secret scans.

Passing this checklist certifies deterministic demo-data behavior only. It does not replace the seller E2E/UAT workflow listed at the start of this document.