Variant options are clearly defined and enumerated

Variant options stored as free-form strings ('medium', 'Med', 'M') for the same logical value produce duplicate facets in filters, inconsistent add-to-cart payloads, and inventory mismatches when orders reference 'M' but the stock record uses 'Medium'. ISO 25010:2011 functional-correctness requires consistent behavior across the same logical input. Without an enum or lookup table, every new developer who touches the product creation form can introduce a new spelling, and there's no schema-level enforcement to catch it. Filter UIs built on free-form strings show three separate size options when there should be one.

Define variant options as enum types or a reference table in prisma/schema.prisma so the database rejects any value not in the allowed set.

enum Size {
  XS
  S
  M
  L
  XL
}

model ProductVariant {
  id        String @id @default(cuid())
  productId String
  product   Product @relation(fields: [productId], references: [id])
  size      Size
  color     String
}

For more flexible option systems, use a separate OptionValue reference table and foreign key instead of a Prisma enum — this allows adding new values via migration rather than code change.