theme-ecommerce

name	theme-ecommerce
description	E-commerce application palette: variants, pages, entities, and flows for building a varied online-shopping app. Use when theme_preset is ecommerce.

E-commerce theme

Domain

Apps where users browse a catalog, build a cart, pay, and track orders. The money flow (price → discount → total → payment → fulfillment) and the ownership of orders/addresses are the parts that make exploits feel real.

Application variants — pick ONE per lab

Choose a single variant; it biases everything below. If theme_free_text or custom_prompt hints at one (e.g. "sneaker shop", "marketplace"), honor it — otherwise pick one at random so labs diverge.

• Fashion / general storefront — single-seller catalog, sizes & variants, reviews, coupons.
• Multi-vendor marketplace — independent vendors, per-vendor storefronts, payouts, commission.
• Digital downloads — license keys / downloadable files after purchase, no shipping.
• Grocery / delivery — delivery slots, substitutions, address book, tips.
• Subscription box — recurring plans, billing cycles, pause/skip, prorations.
• Auction / resale marketplace — listings with bids, reserve prices, watch & outbid, settle to the highest bidder.
• Print-on-demand / custom goods — base products, per-order customization (text/art), design previews, production status.

Roles — choose the set that fits the variant

• anon — browse catalog, search, view product (guest checkout optional).
• user (customer) — cart, checkout, orders, reviews, addresses.
• vendor (service/seller) — marketplace only: manage own products & orders.
• admin — catalog, coupons, refunds, all orders.

Most exploits run as user.

Candidate pages — select a coherent subset

Size the subset to endpoint_count (small ≈ home + catalog + cart + checkout; xlarge ≈ the full list). Candidates: home/landing, category listing, search results, product detail, cart, checkout, order confirmation, order history, order detail, account/profile, address book, wishlist, reviews, coupon entry, vendor storefront (marketplace), seller dashboard (marketplace), payouts (marketplace), downloads / license library (digital), delivery slot picker (grocery), subscription plans / manage subscription (subscription box), admin catalog, admin orders, admin refunds.

Candidate entities (seed tables) — select what the variant needs

Core (most variants):

• users — id, email, password_hash, role, created_at
• products — id, title, description, price_cents, stock, category_id, vendor_id?
• categories — id, name, parent_id?
• carts / cart_items — id, user_id, product_id, qty
• orders — id, user_id, status, total_cents, address_id, created_at
• order_items — id, order_id, product_id, qty, unit_price_cents
• reviews — id, product_id, user_id, rating, body
• coupons — id, code, kind (percent/fixed), value, max_uses, used
• addresses — id, user_id, line1, city, postal, country
• payments — id, order_id, amount_cents, method, status, created_at

Fashion / general storefront (variant):

• product_variants — id, product_id, size, color, sku, stock
• wishlists — id, user_id, product_id

Multi-vendor marketplace (variant):

• vendors — id, name, owner_user_id, commission_bps, payout_balance_cents
• payouts — id, vendor_id, amount_cents, status, requested_at, paid_at

Digital downloads (variant):

• license_keys — id, order_item_id, user_id, product_id, key, revoked
• downloads — id, license_key_id, file_path, max_downloads, used, expires_at

Grocery / delivery (variant):

• delivery_slots — id, date, window, capacity, booked
• order_substitutions — id, order_item_id, replacement_product_id, status
• tips — id, order_id, amount_cents

Subscription box (variant):

• plans — id, name, price_cents, cadence, active
• subscriptions — id, user_id, plan_id, status, next_bill_at, paused_until?
• subscription_invoices — id, subscription_id, amount_cents, period, paid_at

Seed ≥5 rows in each content table, and multiple users each owning their own orders/addresses, so cross-account exploits are possible.

Candidate user flows — select the ones matching chosen pages/features

1. Browse category → open product → add to cart → checkout → confirmation.
2. Search → filter/sort → product detail.
3. Apply coupon at checkout → recalculated total → pay.
4. View order history → open an order → (request refund / track shipment).
5. Write a review on a purchased product.
6. Manage the address book → set a default shipping address → use it at checkout.
7. (fashion) Pick a size/color variant → add to wishlist → move wishlist item to cart.
8. (marketplace) Vendor adds a product → it appears in catalog → sells → requests a payout.
9. (digital) Buy a downloadable product → retrieve license key → download the file.
10. (grocery) Reserve a delivery slot → set substitution preferences → check out → add a tip.
11. (subscription) Subscribe to a plan → skip/pause a cycle → billing updates on next run.

Candidate endpoints — a feature may span several

Endpoints are a shared surface, not owned 1:1 by a feature (a single feature often spans several, and an endpoint can back multiple features). Pick a coherent subset alongside the pages above. Grouped by area:

• catalog / search — GET /api/products, GET /api/products/{id}, GET /api/search?q=&category=&sort=
• cart — GET/POST/DELETE /api/cart, PUT/DELETE /api/cart/items/{id}, POST /api/cart/coupon
• checkout / orders — POST /api/checkout, GET /api/orders, GET /api/orders/{id}, POST /api/orders/{id}/refund
• reviews / wishlist — POST /api/products/{id}/reviews, GET/POST/DELETE /api/wishlist
• account — GET/PUT /api/profile, GET/POST/PUT/DELETE /api/addresses
• vendor (marketplace) — GET/POST /api/vendor/products, GET /api/vendor/orders, GET/POST /api/vendor/payouts
• digital (downloads) — GET /api/licenses, GET /api/downloads/{id}
• grocery (delivery) — GET /api/slots, POST /api/slots/{id}/reserve, POST /api/orders/{id}/substitutions, POST /api/orders/{id}/tip
• subscriptions (box) — GET /api/plans, POST /api/subscriptions, POST /api/subscriptions/{id}/pause, POST /api/subscriptions/{id}/skip
• admin — /api/admin/products, /api/admin/orders, POST /api/admin/orders/{id}/refund

Where vulnerabilities fit naturally

• idor → GET /api/orders/{id}, /api/addresses/{id}, /api/licenses, vendor payouts — view/edit another user's resource.
• sqli → search/filter params (q, sort, category).
• business_logic → coupon reuse / stacking, negative-quantity or price-tamper at checkout, refund more than paid, inventory oversell, subscription proration abuse.
• xss → review body, product Q&A, seller storefront description.
• file_upload → product image / avatar / digital-good upload.
• race_condition → coupon max_uses, last-in-stock checkout, delivery-slot capacity, subscription credit.
• idor/privilege_escalation → vendor accessing another vendor's orders; customer reaching /api/admin/....

Diversity guidance

Pick ONE variant and a coherent subset of pages/entities/flows — never emit the whole menu. Let endpoint_count set the size and theme_free_text / custom_prompt bias the variant and product naming. Two ecommerce labs should look like different stores, not the same template twice.