Files
vmall/openspec/changes/archive/2026-09-17-replace-mock-api-wave-1/specs/frontend-mall/spec.md
T
james 2136a48fbe chore(openspec): archive the mock-migration waves and green the spec set
Archive the three completed changes behind replace-mock-api-wave-1/2/3. Each
merge applied cleanly to the main specs:

- catalog gains the Public product browse requirement (subtree filtering and
  price sort)
- frontend-mall picks up the per-domain adapter, the pinned home page, the
  discovery-page changes, the live auth panels and the live transaction flows
- cart's Server-side cart requirement now documents the shop and stock carried
  by every line

Also replace the TBD Purpose placeholder in all eleven specs with a one-line
description of what each capability covers. Those placeholders predate this
work and were the only reason `openspec validate --all --strict` reported
0 passed / 11 failed; it now reports 11 passed / 0 failed.
2026-09-17 16:36:10 +00:00

3.6 KiB

Spec Delta

MODIFIED Requirements

Requirement: Mock API adapter

The mall SHALL select its API adapter per domain, so one domain can be served by the live backend while the others stay on fixed data. The mall SHALL still ship a fixed-data adapter implementing the whole @vmall/shared API client surface, and the live/fixed choice SHALL be configurable per domain without changing page call sites. The fixed-data adapter SHALL remain able to serve every domain when the live backend is unavailable.

Scenario: mall runs without backend

  • WHEN the mall starts with the API service unavailable and every domain configured to fixed data
  • THEN browsing, cart, checkout, payment, orders and invoice pages return deterministic fixed data and remain functional

Scenario: domains migrate independently

  • WHEN the live backend serves the catalog and currency domains while auth, cart, orders, shipments and invoices remain on fixed data
  • THEN browsing and prices come from the backend while those other flows keep working against fixed data

Requirement: Mock PC home page

The mall home page SHALL render a hero row composed of a pinned 240px category sidebar on the left and a hero carousel filling the remainder of the 1200px grid, both 450px tall and occupying layout space (not overlaid). The sidebar SHALL list the catalog's top-level categories with up to three child links each; hovering a top-level category SHALL expand the mega-menu panel to the right over the carousel. Banner images SHALL render at fixed 450px height, center-cropped horizontally to the narrower carousel width. Below the hero, the page SHALL render a six-item quick-link strip with promotion tiles and bilingual product floors, where each floor's products come from the catalog API while the banner, promotion, quick-link and floor advert assets remain local content.

Scenario: shopper lands on home

  • WHEN / loads
  • THEN the category sidebar is visible to the left of the carousel without any hover or click, the carousel renders center-cropped banners at 450px height, and the quick links, promotions and every non-empty product floor render, with floor products sourced from the catalog API

Scenario: sidebar stays while scrolling

  • WHEN a shopper scrolls the home page beyond 200px
  • THEN the category sidebar remains rendered in the hero row and does not auto-hide

Scenario: expand a category

  • WHEN a shopper hovers a top-level category in the pinned sidebar
  • THEN the mega-menu panel expands to the right, overlaying the carousel with that category's child and grandchild links from the catalog API

Requirement: Product discovery pages

The mall SHALL provide /search with breadcrumb, category and sort controls, a five-column desktop product grid, pagination and an empty state, listing products from the catalog API filtered by the selected category's subtree. The sort control SHALL offer newest-first and price ascending/descending only. It SHALL provide /goods/[id] rendering product and SKU data from the catalog API with image gallery/zoom, bilingual name/subtitle, integer-minor-unit prices, attribute and SKU selection, stock-aware quantity, store card, and detail/comments/after-sale tabs whose comment, coupon and sales content stays local display-only content.

Scenario: filter and inspect a product

  • WHEN a shopper filters the search page by a parent category and opens a product
  • THEN products from that category and its descendants are listed, and selecting an in-stock SKU updates the displayed price, stock and cart target from the catalog API