System Requirements Document for cobalt-e

1. Introduction

cobalt-e is a multi-category e-commerce website: an all-in-one online shopping platform where customers purchase products across clothing, groceries, kitchen essentials, home appliances, and home & living goods in one convenient place. The product intent is a modern, professional, fully responsive storefront built with HTML, CSS, JavaScript, and a suitable JavaScript framework where needed, delivering an attractive, clean, user-friendly interface with smooth animations, professional typography, high-quality product images, and a consistent color scheme that works smoothly on desktop computers, tablets, and mobile devices.

The audience is everyday households shopping on phones and desktops — people buying a refrigerator, a bag of produce, a pair of sneakers, and a set of cookware in the same trip. The register must be premium and trustworthy enough for a major appliance while remaining joyful and loud enough that buying bananas and sneakers feels like the same fun trip.

This document specifies the current front-end prototype: a working storefront that uses sample product data and localStorage to preserve the cart and wishlist between page refreshes, structured so that a backend, database, authentication system, and payment gateway can be integrated later.

2. System Overview

cobalt-e is delivered as a responsive, browser-based storefront. The current build is a front-end prototype: product data is realistic sample data, and the cart and wishlist persist locally in the browser via localStorage across page refreshes. The application is structured so that a backend, database, authentication system, and payment gateway can be integrated later.

Actors. Two accepted human personas shop the store: the Shopper, who browses and searches across all five categories, filters and sorts listings, inspects product detail pages, and adds items to the cart or wishlist; and the Registered Customer, who registers and logs in to manage a profile, saved addresses, order history, wishlist, and order tracking, and to receive confirmation messages for important shopping actions. No other human personas are in scope.

Accepted behavior. The storefront presents a Homepage with navigation, hero promotions, category cards, merchandising sections, discount and limited-time offers, customer reviews and testimonials, and a professional footer. Five dedicated category pages (Clothing & Fashion, Groceries, Kitchen Essentials, Home Appliances, Home & Living) each carry a banner, relevant products, filters, and sorting. A Product Listing destination owns search, category filters, price range filters, and sorting across the catalog. Product Details pages show multiple images, descriptions, available sizes or colors, specifications, stock status, and customer reviews, with Add to Cart, Buy Now, and Add to Wishlist. The Shopping Cart supports adding, removing, and updating quantities with automatic subtotals, discounts, delivery charges, and total. Checkout collects shipping address, contact information, and payment method selection, supporting cash on delivery and providing a structure for later online payment gateway integration. Login, Registration, and a protected User Account area cover profile management, saved addresses, order history, wishlist, and order tracking.

Ownership. All storefront surfaces are first-party application pages. Cart and wishlist persistence is a browser-local responsibility. Cash on delivery is the only currently supported payment method; online payment gateways are a structure for later integration, not a live capability.

Narrow exclusions. No live online payment gateway integration is required in the current build. No backend, database, or authentication service is required in the current build; the application is structured so these can be integrated later. No additional product categories beyond the five named are in scope.

2a. Product Interpretation and Delivery Boundary

cobalt-e is a first-party storefront application. Every shopping surface — Homepage, the five category pages, Product Listing, Product Details, Shopping Cart, Checkout, Login, Registration, and User Account — is owned and rendered by the application itself. There is no provider-owned or external-only surface in the current scope.

The current delivery is a front-end prototype. Product data is realistic sample data held in the application; the cart and wishlist persist in the browser via localStorage so they survive page refreshes. Checkout supports cash on delivery today and exposes only a structure for later online payment gateway integration — no live gateway is wired. The application is deliberately structured so a backend, database, authentication system, and payment gateway can be integrated later without reworking the storefront.

Access is split by lifecycle. Browsing, searching, filtering, sorting, viewing product details, and managing the cart are open to any visitor. Registration is the anonymous first-use entry that creates a customer account; Login is the returning verification entry. The User Account area is protected and requires login. Cart and wishlist contents persist locally for any visitor, whether or not they hold an account.

Future work — live payment gateways, a real backend and database, and a production authentication system — is out of current scope and is not part of current acceptance.

2b. Source Content Inventory

Not applicable. No reference directive in this project declares a content_source; all product content is realistic sample data authored for the prototype.

2c. Page Content and Component Coverage

Homepage

• Information/state: Anonymous public entry. Presents the marketplace as a whole: brand identity, current promotional offers, seasonal sales, featured products, the five category cards, merchandising rails, discount and limited-time offers, customer reviews and testimonials, and footer information.
• Primary actions: Search products from the navigation bar; open a category card; open a merchandising rail item; open the account icon, wishlist, or shopping cart; interact with promotional banners.
• Supporting actions: Navigate via the mobile navigation; follow footer links to contact information, social media, FAQs, and policies; read testimonials.
• Domain entities: Product, Category, Promotion/Offer, Review/Testimonial, Cart (badge count), Wishlist (badge count).
• Component responsibilities:
  • Navigation bar: website logo, search bar, account icon, wishlist, shopping cart.
  • Hero banner: promotional offers, seasonal sales, and featured products.
  • Category cards: attractive images with clear labels for the five categories.
  • Merchandising rails: best-selling products, trending items, new arrivals, and recommended products.
  • Discount sections: special discount sections and limited-time offers.
  • Testimonials: customer reviews and testimonials.
  • Footer: contact information, social media links, FAQs, and policies.
• States: Loading state while sample product data resolves; empty state for any rail with no qualifying products; success state when rails and cards render; error/recovery state if product data fails to load, with a retry affordance.

Clothing & Fashion

• Information/state: Dedicated category page for Clothing & Fashion, covering men's clothing, women's clothing, kids' wear, shoes, bags, accessories, and seasonal collections. Carries a category banner and the relevant product set.
• Primary actions: Browse the category's products; apply filters; change sorting; open a product.
• Supporting actions: Add to cart or wishlist directly from the grid; clear filters.
• Domain entities: Product, Category, Filter, Sort option, Cart, Wishlist.
• Component responsibilities: Category banner; product grid with images, names, prices, ratings, and discount badges; filter controls; sorting controls.
• States: Loading state while products resolve; empty state when filters exclude all products, with a clear-filters recovery; success state with the filtered grid; error/recovery state if the category product set fails to load.

Groceries

• Information/state: Dedicated category page for Groceries, covering fruits, vegetables, dairy products, snacks, beverages, packaged foods, and daily essentials. Carries a category banner and the relevant product set.
• Primary actions: Browse the category's products; apply filters; change sorting; open a product.
• Supporting actions: Add to cart or wishlist directly from the grid; clear filters.
• Domain entities: Product, Category, Filter, Sort option, Cart, Wishlist.
• Component responsibilities: Category banner; product grid with images, names, prices, ratings, and discount badges; filter controls; sorting controls.
• States: Loading state while products resolve; empty state when filters exclude all products, with a clear-filters recovery; success state with the filtered grid; error/recovery state if the category product set fails to load.

Kitchen Essentials

• Information/state: Dedicated category page for Kitchen Essentials, covering cookware, utensils, dinnerware, kitchen organizers, storage containers, and cooking tools. Carries a category banner and the relevant product set.
• Primary actions: Browse the category's products; apply filters; change sorting; open a product.
• Supporting actions: Add to cart or wishlist directly from the grid; clear filters.
• Domain entities: Product, Category, Filter, Sort option, Cart, Wishlist.
• Component responsibilities: Category banner; product grid with images, names, prices, ratings, and discount badges; filter controls; sorting controls.
• States: Loading state while products resolve; empty state when filters exclude all products, with a clear-filters recovery; success state with the filtered grid; error/recovery state if the category product set fails to load.

Home Appliances

• Information/state: Dedicated category page for Home Appliances, covering refrigerators, washing machines, microwave ovens, blenders, air fryers, vacuum cleaners, and other household appliances. Carries a category banner and the relevant product set.
• Primary actions: Browse the category's products; apply filters; change sorting; open a product.
• Supporting actions: Add to cart or wishlist directly from the grid; clear filters.
• Domain entities: Product, Category, Filter, Sort option, Cart, Wishlist.
• Component responsibilities: Category banner; product grid with images, names, prices, ratings, and discount badges; filter controls; sorting controls.
• States: Loading state while products resolve; empty state when filters exclude all products, with a clear-filters recovery; success state with the filtered grid; error/recovery state if the category product set fails to load.

Home & Living

• Information/state: Dedicated category page for Home & Living, covering furniture, bedding, home décor, lighting, cleaning supplies, and bathroom accessories. Carries a category banner and the relevant product set.
• Primary actions: Browse the category's products; apply filters; change sorting; open a product.
• Supporting actions: Add to cart or wishlist directly from the grid; clear filters.
• Domain entities: Product, Category, Filter, Sort option, Cart, Wishlist.
• Component responsibilities: Category banner; product grid with images, names, prices, ratings, and discount badges; filter controls; sorting controls.
• States: Loading state while products resolve; empty state when filters exclude all products, with a clear-filters recovery; success state with the filtered grid; error/recovery state if the category product set fails to load.

Product Listing

• Information/state: Cross-catalog listing destination owning search, category filters, price range filters, and sorting across all products. Displays products in an attractive grid layout with product images, names, prices, ratings, and discount badges.
• Primary actions: Live search; apply category filters; apply price range filters; sort by price, popularity, or newest arrivals; open a product.
• Supporting actions: Clear individual or all filters; add to cart or wishlist from the grid.
• Domain entities: Product, Category, Filter, Price range, Sort option, Cart, Wishlist.
• Component responsibilities: Search input with live results; category filter controls; price range filter controls; sorting controls; product grid with images, names, prices, ratings, and discount badges.
• States: Loading state while results resolve; empty state when search or filters return no products, with a clear-filters recovery; success state with the result grid; error/recovery state if the catalog fails to load.

Product Details

• Information/state: Individual product detail page for a single product. Shows multiple images, descriptions, available sizes or colors, specifications, stock status, and customer reviews.
• Primary actions: Add to Cart; Buy Now; Add to Wishlist.
• Supporting actions: Browse the image gallery; select an available size or color; read customer reviews; adjust quantity.
• Domain entities: Product, Product image, Variant (size/color), Specification, Stock status, Review, Cart, Wishlist.
• Component responsibilities: Image gallery with multiple images; description block; size/color selector; specifications table; stock status indicator; customer reviews section; Add to Cart, Buy Now, and Add to Wishlist buttons.
• States: Loading state while the product resolves; empty state when a product has no reviews; success state when the product renders with its gallery, variants, specs, stock status, and reviews; error/recovery state if the product fails to load or is unavailable, with a route back to the listing.

Shopping Cart

• Information/state: Cart destination listing the products the customer has added, with quantities and line prices. Automatically calculates subtotals, discounts, delivery charges, and the total price.
• Primary actions: Add products; remove products; update product quantities; proceed to checkout.
• Supporting actions: Continue shopping; move an item to the wishlist.
• Domain entities: Cart, Cart line item, Quantity, Subtotal, Discount, Delivery charge, Total, Wishlist.
• Component responsibilities: Cart line list with quantity controls; remove control; subtotal, discount, delivery charge, and total summary; proceed-to-checkout control.
• States: Loading state while the cart resolves from localStorage; empty-cart state with a clear route back to shopping; success state with recalculated totals on every quantity change; error/recovery state if a cart line is no longer available, with a remove-and-continue recovery.

Checkout

• Information/state: Simple, user-friendly checkout process collecting shipping address, contact information, and payment method selection. Supports cash on delivery and provides a structure for integrating online payment gateways.
• Primary actions: Enter shipping address; enter contact information; select a payment method; place the order.
• Supporting actions: Review the order summary; return to the cart to adjust items.
• Domain entities: Shipping address, Contact information, Payment method (cash on delivery; online gateway structure), Order, Order summary.
• Component responsibilities: Shipping address form; contact information form; payment method selection; order summary; place-order control; form validation.
• States: Loading state while the order summary resolves; empty state when the cart is empty, routing the customer back to shopping; success state with a clear order confirmation message; error/recovery state on validation failure, with field-level messages and preserved input.

Login

• Information/state: Anonymous identity-access surface providing returning verification for registered customers before they reach the User Account area.
• Primary actions: Enter credentials and submit to verify identity; navigate to Registration.
• Supporting actions: Recover from a failed verification attempt.
• Domain entities: Customer account, Credentials, Session.
• Component responsibilities: Credential form with validation; submit control; link to Registration.
• States: Idle state; loading state during verification; success state routing to the User Account area; error/recovery state on invalid credentials, with a clear message and preserved input.

Registration

• Information/state: Anonymous identity-access surface providing self-service first-use enrollment that creates a customer account.
• Primary actions: Enter registration details and submit to create the account; navigate to Login.
• Supporting actions: Recover from a failed registration attempt.
• Domain entities: Customer account, Registration details, Session.
• Component responsibilities: Registration form with validation; submit control; link to Login.
• States: Idle state; loading state during account creation; success state confirming account creation and routing onward; error/recovery state on validation failure or an already-registered identity, with field-level messages and preserved input.

User Account

• Information/state: Protected account area for a verified Registered Customer. Presents customer profile management, saved addresses, order history, wishlist, and order tracking, and displays clear confirmation messages for important shopping actions.
• Primary actions: Manage the customer profile; manage saved addresses; review order history; review the wishlist; track an order.
• Supporting actions: Reuse a saved address at checkout; open a past order; remove a wishlist item.
• Domain entities: Customer profile, Saved address, Order, Order history, Order tracking status, Wishlist, Confirmation message.
• Component responsibilities: Profile management panel; saved addresses panel; order history list; order tracking view; wishlist panel; confirmation message surface.
• States: Loading state while account data resolves; empty state for a customer with no saved addresses, no order history, or an empty wishlist, each with a clear route to the relevant shopping surface; success state with the account panels populated; error/recovery state if account data fails to load, with a retry affordance.

3. Functional Requirements

FR-1 — Responsive multi-category storefront (explicit) As a Shopper, I should shop a modern, professional, fully responsive multi-category e-commerce website built with HTML, CSS, JavaScript, and a suitable JavaScript framework where needed, so that I can purchase products across categories on desktop, tablet, or mobile.

• Lifecycle: Trigger — the Shopper opens the site on any device. Observable result — the storefront renders and remains usable across desktop, tablet, and mobile viewports. Failure/recovery — if a viewport cannot render a section, the layout reflows to a usable arrangement. Continuation — the Shopper proceeds to browse or search.
• Acceptance: The site works smoothly on desktop computers, tablets, and mobile devices.

FR-2 — Five-category organization (explicit) As a Shopper, I should shop across Clothing & Fashion, Groceries, Kitchen Essentials, Home Appliances, and Home & Living, so that fashion, groceries, kitchen essentials, and home appliances come together in one convenient platform.

• Lifecycle: Trigger — the Shopper selects a category. Observable result — the store presents the products belonging to that category. Failure/recovery — if a category has no matching products under active filters, an empty state with a clear-filters recovery appears. Continuation — the Shopper opens a product or refines filters.
• Acceptance: All five categories are present and each is browsable.

FR-3 — Homepage navigation bar (explicit) As a Shopper, I should see a modern navigation bar with the website logo, search bar, account icon, wishlist, and shopping cart, so that I can reach every major area from anywhere on the Homepage.

• Lifecycle: Trigger — the Homepage loads. Observable result — the navigation bar presents the logo, search bar, account icon, wishlist, and shopping cart. Failure/recovery — if the mobile navigation is collapsed, the mobile navigation control expands it. Continuation — the Shopper searches, opens the account icon, wishlist, or cart.
• Acceptance: All five navigation elements are present and functional.

FR-4 — Homepage hero banner (explicit) As a Shopper, I should see a hero banner featuring promotional offers, seasonal sales, and featured products, so that I immediately understand what is on offer.

• Lifecycle: Trigger — the Homepage loads. Observable result — the hero banner presents promotional offers, seasonal sales, and featured products. Failure/recovery — if a promotional asset fails to load, the banner still presents its offer text and a route into the promoted products. Continuation — the Shopper opens a featured product or a promotion.
• Acceptance: The hero banner presents promotional offers, seasonal sales, and featured products.

FR-5 — Homepage category cards (explicit) As a Shopper, I should see category cards with attractive images and clear labels, so that I can identify and enter the category I want.

• Lifecycle: Trigger — the Homepage loads. Observable result — category cards present attractive images and clear labels for the categories. Failure/recovery — if a card image fails to load, the card still presents its clear label and remains openable. Continuation — the Shopper opens a category page.
• Acceptance: Category cards show attractive images and clear labels.

FR-6 — Homepage merchandising sections (explicit) As a Shopper, I should see best-selling products, trending items, new arrivals, and recommended products, so that I can discover products beyond what I already know I want.

• Lifecycle: Trigger — the Homepage loads. Observable result — best-selling, trending, new arrivals, and recommended product sections render. Failure/recovery — if a section has no qualifying products, that section shows an empty state rather than a broken rail. Continuation — the Shopper opens a product from any section.
• Acceptance: Best-selling products, trending items, new arrivals, and recommended products are each presented.

FR-7 — Homepage discount and limited-time offers (explicit) As a Shopper, I should see special discount sections and limited-time offers, so that I can act on time-sensitive savings.

• Lifecycle: Trigger — the Homepage loads. Observable result — special discount sections and limited-time offers render with their discount information. Failure/recovery — if an offer expires, the section updates or clears rather than showing a stale claim. Continuation — the Shopper opens a discounted product.
• Acceptance: Special discount sections and limited-time offers are presented.

FR-8 — Homepage customer reviews and testimonials (explicit) As a Shopper, I should see customer reviews and testimonials, so that I can judge the store's trustworthiness before buying.

• Lifecycle: Trigger — the Homepage loads. Observable result — customer reviews and testimonials render. Failure/recovery — if no testimonials are available, the section shows an empty state. Continuation — the Shopper continues to browse.
• Acceptance: Customer reviews and testimonials are presented.

FR-9 — Homepage footer (explicit) As a Shopper, I should see a professional footer with contact information, social media links, FAQs, and policies, so that I can find support and store information.

• Lifecycle: Trigger — the Shopper reaches the bottom of the Homepage. Observable result — the footer presents contact information, social media links, FAQs, and policies. Failure/recovery — if a linked destination is unavailable, the remaining footer content stays usable. Continuation — the Shopper follows a footer link.
• Acceptance: The footer contains contact information, social media links, FAQs, and policies.

FR-10 — Dedicated category pages (explicit) As a Shopper, I should visit a dedicated page for each main category with relevant products, a category banner, filters, and sorting options, so that I can browse a category in depth.

• Lifecycle: Initiator — the Shopper opens a category page. Observable result — the page presents the category banner, the relevant products, filters, and sorting options. Failure/recovery — if filters exclude all products, an empty state with a clear-filters recovery appears. Continuation — the Shopper opens a product or refines the listing.
• Acceptance: Each of the five categories has its own dedicated page with relevant products, a category banner, filters, and sorting options.

FR-11 — Product grid display (explicit) As a Shopper, I should see products displayed in an attractive grid layout with product images, names, prices, ratings, and discount badges, so that I can compare offers at a glance.

• Lifecycle: Trigger — a listing or category page renders. Observable result — each product card shows its image, name, price, rating, and discount badge where applicable. Failure/recovery — if a product image fails to load, the card still shows its name, price, rating, and discount badge. Continuation — the Shopper opens a product.
• Acceptance: Products display in a grid with images, names, prices, ratings, and discount badges.

FR-12 — Search, filters, and sorting (explicit) As a Shopper, I should use product search, category filters, price range filters, and sorting by price, popularity, and newest arrivals, so that I can narrow the catalog to what I want.

• Lifecycle: Trigger — the Shopper enters a search term or applies a filter or sort. Observable result — the listing updates to the matching, ordered result set. Failure/recovery — if the combination returns nothing, an empty state with a clear-filters recovery appears. Continuation — the Shopper opens a product or adjusts the criteria.
• Acceptance: Product search, category filters, price range filters, and sorting by price, popularity, and newest arrivals all function.

FR-13 — Product detail content (explicit) As a Shopper, I should open an individual product detail page showing multiple images, descriptions, available sizes or colors, specifications, stock status, and customer reviews, so that I can decide whether to buy.

• Lifecycle: Initiator — the Shopper opens a product. Observable result — the detail page presents multiple images, the description, available sizes or colors, specifications, stock status, and customer reviews. Failure/recovery — if the product is unavailable, the page shows its stock status and a route back to the listing. Continuation — the Shopper adds the product to the cart or wishlist.
• Acceptance: Product detail pages show multiple images, descriptions, available sizes or colors, specifications, stock status, and customer reviews.

FR-14 — Product detail actions (explicit) As a Shopper, I should use Add to Cart, Buy Now, and Add to Wishlist on a product detail page, so that I can act on a product immediately.

• Lifecycle: Initiator — the Shopper selects Add to Cart, Buy Now, or Add to Wishlist. Observable result — the cart or wishlist updates and a clear confirmation message appears. Failure/recovery — if the product is out of stock, the action is blocked with a clear message. Continuation — the Shopper continues shopping or proceeds to the cart or checkout.
• Acceptance: Add to Cart, Buy Now, and Add to Wishlist are present and functional on product detail pages.

FR-15 — Cart quantity management (explicit) As a Shopper, I should add, remove, and update product quantities in the shopping cart, so that I control exactly what I am buying.

• Lifecycle: Initiator — the Shopper adds, removes, or changes a quantity. Observable result — the cart line list and totals update. Failure/recovery — if a cart line is no longer available, the Shopper can remove it and continue. Continuation — the Shopper proceeds to checkout.
• Acceptance: Adding, removing, and updating product quantities all function.

FR-16 — Automatic cart calculation (explicit) As a Shopper, I should have subtotals, discounts, delivery charges, and the total price calculated automatically, so that I always see the true cost.

• Lifecycle: Trigger — any cart change. Observable result — subtotals, discounts, delivery charges, and the total price recalculate automatically. Failure/recovery — if a discount or delivery rule cannot be applied, the affected line is shown without it rather than producing a wrong total. Continuation — the Shopper proceeds to checkout.
• Acceptance: Subtotals, discounts, delivery charges, and the total price are calculated automatically.

FR-17 — Simple checkout process (explicit) As a Shopper, I should complete a simple, user-friendly checkout process, so that I can place my order without friction.

• Lifecycle: Initiator — the Shopper proceeds from the cart. Observable result — the checkout presents the order summary and the required inputs in a simple sequence. Failure/recovery — if the cart is empty, the Shopper is routed back to shopping. Continuation — the Shopper submits the order.
• Acceptance: Checkout is a simple, user-friendly process.

FR-18 — Shipping address and contact information (explicit) As a Shopper, I should provide my shipping address and contact information at checkout, so that my order can be delivered and I can be reached.

• Lifecycle: Initiator — the Shopper enters shipping address and contact information. Observable result — the entered values are captured and validated. Failure/recovery — invalid or missing fields produce field-level validation messages and preserve the entered input. Continuation — the Shopper selects a payment method.
• Acceptance: Checkout includes shipping address and contact information.

FR-19 — Payment method selection with cash on delivery (explicit) As a Shopper, I should select a payment method at checkout, with cash on delivery supported and a structure for integrating online payment gateways, so that I can pay in the way available to me.

• Lifecycle: Initiator — the Shopper selects a payment method. Observable result — cash on delivery is selectable and the order can be placed with it; online payment gateways are represented only as a structure for later integration. Failure/recovery — if no payment method is selected, checkout blocks submission with a clear message. Continuation — the Shopper places the order.
• Acceptance: Cash on delivery is supported; online payment gateway integration is provided as a structure only.

FR-20 — Login and registration pages (explicit) As a Registered Customer, I should use login and registration pages, so that I can create an account and verify my identity on return.

• Lifecycle: Initiator — a visitor opens Registration to create an account, or Login to verify an existing one. Observable result — Registration creates the account; Login verifies identity and routes to the User Account area. Failure/recovery — invalid credentials or registration details produce a clear message with preserved input. Continuation — the Registered Customer reaches the User Account area.
• Acceptance: Login and registration pages exist and function.

FR-21 — Customer profile management (explicit) As a Registered Customer, I should manage my customer profile, so that my account details stay correct.

• Lifecycle: Initiator — the Registered Customer edits profile details. Observable result — the updated profile is saved and reflected. Failure/recovery — invalid values produce field-level validation messages and preserve input. Continuation — the Registered Customer continues to other account panels.
• Acceptance: Customer profile management is available in the User Account area.

FR-22 — Saved addresses (explicit) As a Registered Customer, I should manage saved addresses, so that I can reuse them at checkout.

• Lifecycle: Initiator — the Registered Customer adds, edits, or removes a saved address. Observable result — the saved address list updates and the address is available for reuse at checkout. Failure/recovery — an incomplete address produces field-level validation messages and preserves input. Continuation — the Registered Customer reuses the address at checkout.
• Acceptance: Saved addresses are available in the User Account area.

FR-23 — Order history (explicit) As a Registered Customer, I should review my order history, so that I can see what I have bought.

• Lifecycle: Initiator — the Registered Customer opens order history. Observable result — past orders are listed. Failure/recovery — a customer with no orders sees an empty state with a route back to shopping. Continuation — the Registered Customer opens an order or tracks it.
• Acceptance: Order history is available in the User Account area.

FR-24 — Wishlist (explicit) As a Registered Customer, I should review my wishlist, so that I can return to products I saved.

• Lifecycle: Initiator — the Registered Customer opens the wishlist. Observable result — saved products are listed and can be opened or moved to the cart. Failure/recovery — an empty wishlist shows an empty state with a route back to shopping. Continuation — the Registered Customer opens a saved product or adds it to the cart.
• Acceptance: Wishlist is available in the User Account area.

FR-25 — Order tracking (explicit) As a Registered Customer, I should track my orders, so that I know where a purchase stands.

• Lifecycle: Initiator — the Registered Customer opens order tracking for an order. Observable result — the order's tracking status is presented. Failure/recovery — if tracking status is unavailable, the order's recorded state is shown instead. Continuation — the Registered Customer returns to order history.
• Acceptance: Order tracking is available in the User Account area.

FR-26 — Confirmation messages (explicit) As a Registered Customer, I should see clear confirmation messages for important shopping actions, so that I know my action succeeded.

• Lifecycle: Trigger — an important shopping action completes. Observable result — a clear confirmation message is displayed. Failure/recovery — if the action fails, a clear failure message is displayed instead. Continuation — the Registered Customer continues shopping or reviewing the account.
• Acceptance: Clear confirmation messages appear for important shopping actions.

FR-27 — Interactive JavaScript functionality (explicit) As a Shopper, I should use live search, category navigation, product filtering, sorting, image galleries, shopping cart updates, wishlist functionality, quantity controls, form validation, mobile navigation, and interactive promotional banners, so that the storefront behaves like a real, working shop.

• Lifecycle: Trigger — the Shopper interacts with any of these controls. Observable result — the corresponding behavior executes without a full page reload. Failure/recovery — invalid form input produces validation messages; an empty result set produces an empty state. Continuation — the Shopper continues the shopping flow.
• Acceptance: Live search, category navigation, product filtering, sorting, image galleries, shopping cart updates, wishlist functionality, quantity controls, form validation, mobile navigation, and interactive promotional banners all function.

FR-28 — localStorage persistence of cart and wishlist (explicit) As a Shopper, I should have my cart and wishlist preserved between page refreshes via localStorage, so that I do not lose my selections.

• Lifecycle: Trigger — the Shopper refreshes or revisits a page. Observable result — the cart and wishlist contents are restored from localStorage. Failure/recovery — if stored data is unavailable or unreadable, the cart and wishlist start empty rather than erroring. Continuation — the Shopper continues shopping with restored selections.
• Acceptance: Cart and wishlist persist between page refreshes using localStorage.

FR-29 — Sample product data (explicit) As a Shopper, I should browse realistic sample products, so that the prototype reads like a real marketplace.

• Lifecycle: Trigger — any listing or detail surface renders. Observable result — realistic sample product data populates the storefront. Failure/recovery — if sample data fails to load, an error state with a retry affordance appears. Continuation — the Shopper browses the populated catalog.
• Acceptance: The prototype uses sample product data with realistic products.

FR-30 — Structure for later backend, database, authentication, and payment gateway integration (explicit) As a Shopper, I should shop a storefront structured so that a backend, database, authentication system, and payment gateway can be integrated later, so that the prototype can grow into a production store without rework.

• Lifecycle: Trigger — the application is structured and built. Observable result — the codebase separates data access, cart/wishlist persistence, identity, and payment concerns so each can be replaced by a real service later. Failure/recovery — not applicable to a structural requirement. Continuation — later integration proceeds without reworking the storefront.
• Acceptance: The application is structured for later backend, database, authentication system, and payment gateway integration.

FR-31 — Self-service registration creates a customer account (required_inference) As a visitor, I should create a customer account through self-service registration, so that I can access the User Account area on first use.

• Lifecycle: Initiator — an anonymous visitor opens Registration. Observable result — a customer account is created and the visitor becomes a Registered Customer. Failure/recovery — invalid or already-registered details produce a clear message with preserved input. Continuation — the Registered Customer reaches the User Account area.
• Acceptance: Registration creates a customer account for first use.

FR-32 — Returning verification through Login (required_inference) As a Registered Customer, I should verify my identity through the Login page, so that I can reach the User Account area on return.

• Lifecycle: Initiator — the Registered Customer opens Login. Observable result — successful verification grants access to the User Account area. Failure/recovery — invalid credentials produce a clear message with preserved input. Continuation — the Registered Customer reaches the User Account area.
• Acceptance: Returning customers verify their identity through the Login page before accessing the User Account area.

FR-33 — Cart and wishlist persist locally across refreshes (required_inference) As a Shopper, I should have my cart and wishlist persist locally across page refreshes, so that my selections survive navigation.

• Lifecycle: Trigger — a page refresh or revisit. Observable result — cart and wishlist contents are restored from local storage. Failure/recovery — unreadable stored data results in an empty cart and wishlist rather than an error. Continuation — the Shopper continues shopping.
• Acceptance: Cart and wishlist persist locally across page refreshes.

FR-34 — Cash on delivery with gateway structure only (required_inference) As a Shopper, I should place an order with cash on delivery, with online payment gateways provided only as a structure for later integration, so that I can complete a purchase today without a live gateway.

• Lifecycle: Initiator — the Shopper selects cash on delivery and places the order. Observable result — the order is placed and a clear confirmation message appears. Failure/recovery — if no payment method is selected, submission is blocked with a clear message. Continuation — the Shopper receives order confirmation.
• Acceptance: Checkout supports cash on delivery and provides only a structure for later online payment gateway integration.

4. User Personas

Shopper

Product context. The Shopper is the everyday household buyer who arrives at cobalt-e without an account and without a fixed shopping list. They may be on a phone during a commute or on a desktop in the evening, and they may be buying a refrigerator, a bag of produce, a pair of sneakers, or all three in the same trip. The storefront must be legible and appetising to them immediately, because an all-in-one marketplace lives or dies on whether they can tell the five departments apart and find something worth buying.

Primary goal. Find the right products across clothing, groceries, kitchen essentials, home appliances, and home & living, and place an order with clear confirmation.

Distinct accepted responsibilities. The Shopper browses and searches products across all five categories; filters and sorts listings by category, price range, price, popularity, and newest arrivals; opens product detail pages to inspect multiple images, descriptions, available sizes or colors, specifications, stock status, and customer reviews; adds items to the cart or wishlist; manages cart quantities; and completes checkout with shipping address, contact information, and a payment method (cash on delivery or, later, an online gateway).

Relevant inputs and decisions. Search terms; category selections; price range bounds; sort order; size or color selection on a product; quantity changes; shipping address and contact information; payment method choice. The Shopper's key decisions are which product variant to take, whether to buy now or save to the wishlist, and which payment method to use.

Interactions with other accepted participants. The Shopper is the sole human actor in the browsing, cart, and checkout lifecycle. Their cart and wishlist persist locally across refreshes. When they choose to create an account, they become a Registered Customer and their account data becomes available to them on return.

Observable success. The Shopper finds the products they want, sees accurate automatic totals, places an order with cash on delivery, and receives a clear confirmation message.

Registered Customer

Product context. The Registered Customer is a Shopper who has chosen to hold an account with cobalt-e. They shop repeatedly and want their details and history to persist so they do not re-enter them every time. Their work is not browsing — it is continuity: keeping a profile correct, keeping addresses reusable, and being able to look back at what they bought and where it is.

Primary goal. Have their account data and past orders persist and be easy to review and reuse at checkout.

Distinct accepted responsibilities. The Registered Customer registers and logs in; manages their customer profile; manages saved addresses; reviews order history; reviews their wishlist; tracks orders; and receives confirmation messages for important shopping actions.

Relevant inputs and decisions. Registration details; login credentials; profile field edits; saved address entries; which saved address to reuse at checkout; which past order to open or track; which wishlist item to open or move to the cart.

Interactions with other accepted participants. The Registered Customer begins as a Shopper and retains the full Shopper lifecycle. Their account area is protected and reachable only after verification through Login. Their saved addresses are reusable at checkout, connecting the account lifecycle back to the Shopper's purchase lifecycle.

Observable success. Their profile, saved addresses, order history, wishlist, and order tracking persist and are easy to review and reuse at checkout, with clear confirmation messages for important shopping actions.

5. Core User Flows

Flow 1 — Shopper discovers products from the Homepage

1. The Shopper opens cobalt-e and lands on the Homepage as an anonymous visitor.
2. The navigation bar presents the website logo, search bar, account icon, wishlist, and shopping cart.
3. The hero banner presents promotional offers, seasonal sales, and featured products; the Shopper reads the current offer.
4. The Shopper scrolls through the category cards, each with an attractive image and a clear label, and through the best-selling, trending, new arrivals, and recommended sections, the special discount and limited-time offer sections, and the customer reviews and testimonials.
5. The Shopper either opens a category card, opens a product from a merchandising section, or types a term into the search bar.
6. Result: the Shopper reaches the relevant category page, product detail page, or Product Listing with results. Next step: continue to Flow 2, Flow 3, or Flow 4.
7. Failure/recovery: if a merchandising section has no qualifying products, that section shows an empty state and the Shopper continues with the remaining sections. If the product data fails to load, an error state with a retry affordance appears.

Flow 2 — Shopper browses a category page

1. From the Homepage category cards or the navigation, the Shopper opens one of the five dedicated category pages: Clothing & Fashion, Groceries, Kitchen Essentials, Home Appliances, or Home & Living.
2. The category page presents its category banner and the relevant products for that category — for example, Clothing & Fashion covers men's clothing, women's clothing, kids' wear, shoes, bags, accessories, and seasonal collections; Groceries covers fruits, vegetables, dairy products, snacks, beverages, packaged foods, and daily essentials; Kitchen Essentials covers cookware, utensils, dinnerware, kitchen organizers, storage containers, and cooking tools; Home Appliances covers refrigerators, washing machines, microwave ovens, blenders, air fryers, vacuum cleaners, and other household appliances; Home & Living covers furniture, bedding, home décor, lighting, cleaning supplies, and bathroom accessories.
3. The Shopper applies filters and changes sorting options to narrow the listing.
4. Result: the grid updates to the filtered, sorted product set, each card showing its image, name, price, rating, and discount badge. Next step: the Shopper opens a product (Flow 4) or adds an item directly to the cart or wishlist.
5. Failure/recovery: if the filters exclude all products, an empty state appears with a clear-filters recovery; the Shopper clears the filters and continues.

Flow 3 — Shopper searches and filters the catalog

1. The Shopper uses the search bar in the navigation bar or opens the Product Listing destination.
2. The Shopper types a term; live search updates the results as they type.
3. The Shopper applies category filters and price range filters, and sorts by price, popularity, or newest arrivals.
4. Result: the Product Listing shows the matching products in an attractive grid with images, names, prices, ratings, and discount badges. Next step: the Shopper opens a product (Flow 4) or adds an item to the cart or wishlist.
5. Failure/recovery: if the search or filter combination returns no products, an empty state appears with a clear-filters recovery; the Shopper adjusts the criteria and continues.

Flow 4 — Shopper inspects a product and acts on it

1. The Shopper opens a Product Details page from a category page, the Product Listing, or a Homepage merchandising section.
2. The page presents multiple images in a gallery, the description, available sizes or colors, specifications, stock status, and customer reviews.
3. The Shopper browses the image gallery and selects an available size or color where the product offers them.
4. The Shopper chooses Add to Cart, Buy Now, or Add to Wishlist.
5. Result: the cart or wishlist updates and a clear confirmation message appears. Next step: the Shopper continues shopping, opens the cart (Flow 5), or proceeds directly to checkout (Flow 6).
6. Failure/recovery: if the product is out of stock, the action is blocked with a clear message and the Shopper returns to the listing. If the product fails to load, an error state with a route back to the listing appears.

Flow 5 — Shopper manages the shopping cart

1. The Shopper opens the Shopping Cart from the navigation bar.
2. The cart lists the added products with their quantities and line prices.
3. The Shopper adds, removes, or updates product quantities.
4. Result: subtotals, discounts, delivery charges, and the total price recalculate automatically on every change. Next step: the Shopper proceeds to checkout (Flow 6) or continues shopping.
5. Failure/recovery: if the cart is empty, an empty-cart state appears with a clear route back to shopping. If a cart line is no longer available, the Shopper removes it and continues.

Flow 6 — Shopper completes checkout with cash on delivery

1. The Shopper proceeds from the Shopping Cart to Checkout.
2. The checkout presents the order summary and a simple, user-friendly sequence of inputs.
3. The Shopper enters the shipping address and contact information.
4. The Shopper selects a payment method; cash on delivery is supported, and online payment gateways are represented only as a structure for later integration.
5. The Shopper places the order.
6. Result: the order is placed and a clear confirmation message is displayed. Next step: the Shopper continues shopping or, if registered, reviews the order in the User Account area (Flow 9).
7. Failure/recovery: if required fields are missing or invalid, field-level validation messages appear and the entered input is preserved; the Shopper corrects the fields and resubmits. If no payment method is selected, submission is blocked with a clear message. If the cart is empty, the Shopper is routed back to shopping.

Flow 7 — Visitor registers a customer account

1. An anonymous visitor opens Registration from the account icon or the Login page.
2. The visitor enters their registration details and submits.
3. Result: a customer account is created and the visitor becomes a Registered Customer. Next step: the Registered Customer reaches the User Account area.
4. Failure/recovery: if the details are invalid or the identity is already registered, field-level messages appear with preserved input; the visitor corrects the details or navigates to Login.

Flow 8 — Registered Customer logs in

1. A returning Registered Customer opens Login.
2. The customer enters their credentials and submits.
3. Result: identity is verified and the customer reaches the protected User Account area. Next step: the customer manages their profile, addresses, order history, wishlist, or order tracking (Flow 9).
4. Failure/recovery: if the credentials are invalid, a clear message appears with preserved input; the customer retries or navigates to Registration.

Flow 9 — Registered Customer manages their account

1. The verified Registered Customer opens the User Account area.
2. The customer manages their customer profile, updating their details.
3. The customer manages saved addresses, adding, editing, or removing entries.
4. The customer reviews order history and opens an order to track it.
5. The customer reviews their wishlist and opens a saved product or moves it to the cart.
6. Result: the updated profile, saved addresses, order history, tracking status, and wishlist are reflected, and clear confirmation messages appear for important shopping actions. Next step: the customer reuses a saved address at checkout (Flow 6) or continues shopping.
7. Failure/recovery: if account data fails to load, an error state with a retry affordance appears. If the customer has no saved addresses, no order history, or an empty wishlist, the relevant panel shows an empty state with a clear route to the corresponding shopping surface.

Flow 10 — Cart and wishlist persist across refreshes

1. The Shopper adds products to the cart or wishlist.
2. The Shopper refreshes the page or navigates away and returns.
3. Result: the cart and wishlist contents are restored from localStorage and the badge counts reflect them. Next step: the Shopper continues shopping or proceeds to checkout.
4. Failure/recovery: if stored data is unavailable or unreadable, the cart and wishlist start empty rather than erroring, and the Shopper continues shopping.

6. Visuals Colors and Theme

The creative direction is Saturated retail theatre after Jessica Walsh — a mass-market multi-category marketplace that must read as premium and trustworthy enough for a refrigerator while staying joyful and loud enough that buying bananas and sneakers feels like the same fun trip. The emotional target is confident, appetising, and alive: a shop window you want to walk into, not a utility. This is deliberately the opposite of a blue-on-white SaaS template and of a neutral dashboard language, so the marketplace reads as a brand, not a backend.

Colour tokens (light mode).

Category colour fields (flat saturated blocks used at full bleed): Clothing #FF2E88, Groceries #14B87A, Kitchen #FFB300, Appliances #3B4CFF, Home & Living #FF7A1A. On Kitchen and Appliances the block is darkened to 12% for contrast behind white type. No gradients behind text; colour is flat, poster-like, never blended.

Typography. Headings use Archivo Black, set in ALL CAPS with tight -0.02em tracking and near-solid leading (0.92); display sizes are deliberately oversized and allowed to run edge to edge. Weights: 900 for section headlines and prices-as-headlines, 700 for product names, 600 for labels. Body copy uses Archivo Regular/Medium at a generous 1.6 line-height for readability inside a loud frame. Scale is a 1.333 modular scale: display 44/60/84/120px (clamp), section headline 32/44/56px, product name 16/18px, price 20/24px tabular, label 12px uppercase +0.14em, body 16/17px.

Shape language. Hard-edged colour fields with big 20–28px card radii and pill buttons — the tension between poster squares and soft pills is the signature. Sticker elements (badges, "NEW", "-40%", "BESTSELLER") are rotated 3–6 degrees, sit half-off the card corner, and use flat colour plus a 2px ink outline. Section boundaries are straight horizontal colour bands, never soft fades.

Layout rhythm. Full-bleed colour-blocked bands stacked vertically: a hot-pink hero, a cream category rail, a tangerine promo strip, a white product grid, a green grocery band, a black testimonial band. The category rail is a horizontally scrollable row of five saturated tiles with oversized labels, each tile tall enough to hold an image crop and a word. Product grids are 2-up at 375px, 3-up at 768px, 4-up at 1280px with 16/24/32px gutters. Filters live in a sticky left column at 1280px and become a bottom sheet at 375/768px. Prices and discount badges are anchored to the same baseline across a row so the grid reads as a table of offers.

Imagery. Art-directed, brightly lit product photography on saturated colour grounds — a sneaker on hot pink, a blender on cobalt, tomatoes on green — plus a few surreal staged props (a giant lemon, a floating kettle) for promo bands. Every product image is cut out on a flat colour field rather than a white studio sweep. The testimonial band uses high-contrast monochrome portraits with a pink duotone. No gradient blobs, no generic stock lifestyle scenes, no white-background catalogue shots.

Avoid. Blue–indigo primary or accent on a white ground (no #0057FF / #2563EB / #6366F1 anywhere, including focus rings — focus rings use #141414 or #FF2E88). Inter, Roboto, Poppins, Montserrat, Open Sans, Lato, or system-ui for headings or body. Gradient-blob heroes, glassmorphism panels, or soft blurred shadows on cards. A grid of identical hover-lift cards with no colour difference between categories. White-background studio product shots as the default card image. Centred headline + subtext + button hero composition. Pastel or desaturated category colours — every category colour must be usable at full saturation behind white type. Grey-on-grey filter chips; filters use ink outlines and the active state fills with the category colour.

7. Signature Design Concept

The Shop Window. The public entry is a full-bleed split hero, not a centred stack. The left 58% is a solid hot-pink #FF2E88 field carrying a four-line ALL-CAPS Archivo Black headline at clamp(44px, 9vw, 120px) — "EVERYTHING / FOR YOUR / HOME, IN / ONE CART." — with the primary CTA as an ink-black pill pinned directly under the last line and a thin white rule above it. The right 42% is a single oversized art-directed image of a stacked haul (a blender, folded linen, a bag of produce) shot on cobalt, bleeding off the right and bottom edges. Overlapping the seam between the two halves, three rotated sticker badges ("-40%", "FREE DELIVERY OVER $49", "NEW IN") sit at 4–6 degrees. A tangerine marquee strip runs immediately beneath the hero with seasonal offer text.

The concept recomposes only accepted content: the hero banner's promotional offers, seasonal sales, and featured products; the primary route into the catalog; and the discount and limited-time offer messaging. It introduces no new behaviour, page, or destination.

At 375px the split becomes a vertical stack: the pink field with the headline and CTA first, the image below at 60vh, and the stickers reflowed into a wrapped row so none is cropped. Headlines, wordmarks, labels, numbers, and controls stay entirely inside the viewport and their container at 375px, 768px, and 1280px, wrapping or scaling to fit; imagery and decoration may bleed, rotate, and overlap as the direction asks, but never cover readable text or a control.

8. Interaction Model & Motion Direction

Interaction Model: Animated Motion Tempo: expressive Hero Dimensionality: layered_2d

Landing Hero Motion Brief. The focal subject is the split hero: the hot-pink headline field on the left and the oversized cobalt-shot haul image on the right, joined by three rotated sticker badges. The thesis is input → transformation → outcome: as the page loads, the headline lines and the thin white rule reveal in a staggered 60ms word/block sequence while the haul image settles into place and the three stickers rotate from their resting 4–6 degrees toward 0deg; the outcome is a composed first frame in which the offer, the primary CTA, and the route into the catalog are all legible at once. Motion vocabulary: 220–320ms cubic-bezier(0.2, 0.8, 0.2, 1), staggered block reveals, sticker straightening, and the continuous tangerine offer marquee beneath the hero. The composed first frame shows the pink field with the full four-line headline, the ink-black pill CTA, the cobalt haul image bleeding off the right and bottom edges, and the three stickers at rest at 4–6 degrees. Under prefers-reduced-motion, all motion collapses to static: the staggered reveals resolve immediately, the stickers hold their resting rotation, and the marquee becomes a wrapped two-row list of the same offer strings.

Motion system. Category tiles scale to 1.03 and swap their image crop on hover; discount stickers rotate to 0deg from their resting 4deg on hover; the promo strip runs a continuous marquee of offer text; product cards lift 4px with a hard 0 6px 0 #141414 offset shadow (offset shadow, not a blur); page section entrances are staggered 60ms word/block reveals on scroll. All motion collapses to static under prefers-reduced-motion, with the marquee becoming a wrapped two-row list and the category rail becoming a horizontally scrollable row.

Readable content under motion. Moving and scrollable content — the marquees, the category rail — may cross the viewport or container edge by design; every item becomes fully readable as it passes or as it is scrolled into view. Under prefers-reduced-motion, the marquee wraps into rows and the category rail remains horizontally scrollable so each item can be brought fully into view.

9. Non-Functional Requirements

NFR-1 — Full responsiveness (explicit) The website must work smoothly on desktop computers, tablets, and mobile devices. Rationale: the source states the storefront must be fully responsive across these device classes. Product grids are 2-up at 375px, 3-up at 768px, and 4-up at 1280px; filters are a sticky left column at 1280px and a bottom sheet at 375/768px.

NFR-2 — Readable text and controls at every viewport (explicit) Headlines, wordmarks, labels, numbers, and cards' text and controls must stay entirely inside the viewport and their container at 375px, 768px, and 1280px, wrapping or scaling (for example font-size: clamp(...) with its mobile size) to fit, with no other element covering any part of them. Rationale: the source requires readable text and accessible buttons; the creative direction requires readable text and controls to stay whole at every viewport.

NFR-3 — Accessible buttons and helpful empty and loading states (explicit) The storefront must provide accessible buttons and helpful empty-cart and loading states. Rationale: explicitly required by the source's visual design requirements.

NFR-4 — Consistent color scheme and professional typography (explicit) The interface must use a consistent color scheme and professional typography. Rationale: explicitly required by the source's design and layout requirements; concretised in Section 6.

NFR-5 — Smooth animations (explicit) The interface must use smooth animations. Rationale: explicitly required by the source; concretised in Section 8 at 220–320ms cubic-bezier(0.2, 0.8, 0.2, 1) with a reduced-motion collapse.

NFR-6 — High-quality product images (explicit) The storefront must use high-quality images for clothing, groceries, kitchen products, and home appliances. Rationale: explicitly required by the source's visual design requirements.

NFR-7 — Clear visual hierarchy and intuitive navigation (explicit) The design must create a clear visual hierarchy and intuitive navigation. Rationale: explicitly required by the source's visual design requirements.

NFR-8 — Consistent spacing, rounded cards, subtle shadows, smooth hover effects (explicit) The design must use consistent spacing, rounded product cards, subtle shadows, and smooth hover effects. Rationale: explicitly required by the source's visual design requirements. The creative direction specifies the shadow as a hard offset 0 6px 0 #141414 rather than a blur.

NFR-9 — Responsive grid and mobile-friendly layouts (explicit) The storefront must use a responsive grid and mobile-friendly layouts. Rationale: explicitly required by the source's visual design requirements.

NFR-10 — Complete, organized, maintainable code (explicit) The deliverable must be complete, organized, and maintainable code with a clear project structure and reusable components, with all major buttons and front-end interactions working correctly. Rationale: explicitly required by the source's final deliverable requirements.

NFR-11 — Front-end prototype data and persistence boundary (explicit) The current build must use sample product data and localStorage to preserve the cart and wishlist between page refreshes, and must be structured so that a backend, database, authentication system, and payment gateway can be integrated later. Rationale: explicit hard constraint in the source.

NFR-12 — Payment scope boundary (explicit) Checkout must support cash on delivery and provide only a structure for integrating online payment gateways; no live gateway integration is required. Rationale: explicit hard constraint in the source.

NFR-13 — Technology constraint (explicit) The storefront must be built with HTML, CSS, JavaScript, and a suitable JavaScript framework if needed. Rationale: explicit hard constraint in the source.

NFR-14 — Focus ring contrast (explicit) Focus rings must use #141414 or #FF2E88; no #0057FF, #2563EB, or #6366F1 may appear anywhere, including focus rings. Rationale: explicit exclusion in the creative direction.

10. Tech Stack

• Markup and styling: HTML and CSS, as explicitly required by the source.
• Behaviour: JavaScript, as explicitly required by the source, implementing live search, category navigation, product filtering, sorting, image galleries, shopping cart updates, wishlist functionality, quantity controls, form validation, mobile navigation, and interactive promotional banners.
• Framework: A suitable JavaScript framework may be used where needed, as permitted by the source. Reusable components are required by the final deliverable.
• Client-side persistence: Browser localStorage, used to preserve the cart and wishlist between page refreshes, as explicitly required by the source.
• Product data: Realistic sample product data held in the application, as explicitly required by the source.
• Payment: Cash on delivery supported today; online payment gateways provided only as a structure for later integration, as explicitly required by the source.
• Future integration boundary: The application is structured so that a backend, database, authentication system, and payment gateway can be integrated later, as explicitly required by the source. None of these are part of the current build.

11. Assumptions and Constraints

Constraints (source-stated, binding).

1. The current build is a front-end prototype: it uses sample product data and localStorage, and is structured so that a backend, database, authentication system, and payment gateway can be integrated later.
2. Checkout supports cash on delivery and provides only a structure for integrating online payment gateways; no live gateway integration is required.
3. The storefront is built with HTML, CSS, JavaScript, and a suitable JavaScript framework if needed.
4. The website must be fully responsive across desktop, tablet, and mobile devices.
5. High-quality images must be used for clothing, groceries, kitchen products, and home appliances.
6. The deliverable must be complete, organized, and maintainable code with a clear project structure and reusable components.
7. The store is organized into exactly the five named categories: Clothing & Fashion, Groceries, Kitchen Essentials, Home Appliances, and Home & Living.
8. Cart and wishlist persist between page refreshes via localStorage.

Assumptions (narrow, labeled).

1. [Assumption] Sample product data is authored to be realistic and to populate all five categories, so that every listing, category page, and detail page has content to render.
2. [Assumption] Cart and wishlist persistence is browser-local and not tied to an account, since the source specifies localStorage for the prototype and does not require account-bound persistence.
3. [Assumption] Registration and Login are the anonymous entry points for the protected User Account area; the User Account area requires login, while all browsing, cart, and checkout surfaces remain open to any visitor.
4. [Assumption] Order history and order tracking reflect orders placed in the current prototype session or stored locally, since no backend or database is in scope.
5. [Assumption] The footer's contact information, social media links, FAQs, and policies are presented as storefront content; no external service integration is required for them.

Explicit exclusions.

1. No live online payment gateway integration in the current build.
2. No backend, database, or production authentication service in the current build.
3. No product categories beyond the five named.

Presentation defaults. [Default — not specified by user] Where the source does not specify a value, the creative direction in Sections 6–8 supplies the palette, typography, shape language, layout rhythm, imagery style, and motion. These are presentation defaults and do not create product behaviour, personas, or destinations.

12. Glossary

• cobalt-e — The project name for this multi-category e-commerce website.
• Shopper — The accepted persona who browses, searches, filters, sorts, inspects products, manages a cart and wishlist, and completes checkout.
• Registered Customer — The accepted persona who holds an account and manages a profile, saved addresses, order history, wishlist, and order tracking.
• Category — One of the five store departments: Clothing & Fashion, Groceries, Kitchen Essentials, Home Appliances, Home & Living.
• Product Listing — The cross-catalog destination owning search, category filters, price range filters, and sorting.
• Product Details — The individual product page showing multiple images, description, available sizes or colors, specifications, stock status, and customer reviews.
• Variant — An available size or color of a product.
• Discount badge — The visual marker on a product card indicating a price reduction.
• Cart — The collection of products a Shopper intends to buy, with quantities and automatically calculated subtotals, discounts, delivery charges, and total.
• Wishlist — The collection of products a Shopper has saved for later.
• localStorage — The browser storage mechanism used to preserve the cart and wishlist between page refreshes in the current prototype.
• Cash on delivery — The payment method supported at checkout in the current build.
• Order tracking — The Registered Customer's view of where a placed order stands.
• Sample product data — The realistic placeholder product data used by the front-end prototype in place of a backend catalog.