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
parent e1a0a5dbdb
commit 2136a48fbe
28 changed files with 84 additions and 30 deletions
@@ -0,0 +1,18 @@
+# Spec Delta
+
+## MODIFIED Requirements
+
+### Requirement: Server-side cart
+Authenticated shoppers SHALL have a Redis-backed cart keyed by user id, containing sku_id + qty entries. Reading the cart SHALL return, for every line, the SKU's current price, currency and stock together with the product's name, image and owning shop, so the storefront can group lines by shop and cap quantity without reading the fixed-data catalog. Lines whose SKU has become inactive or unpurchasable SHALL be omitted from the view.
+
+#### Scenario: add and update
+- **WHEN** a shopper POSTs sku + qty, then PUTs a new qty
+- **THEN** GET /api/cart reflects the latest qty with current price/name snapshot
+
+#### Scenario: unpurchasable SKU rejected
+- **WHEN** adding a SKU that is inactive or whose product is not published
+- **THEN** the API returns 400
+
+#### Scenario: cart view carries shop and stock
+- **WHEN** a shopper reads a cart holding SKUs from more than one shop
+- **THEN** each line reports its shop and the SKU's current stock, so the storefront can group the lines per shop and cap quantity from the response alone
@@ -0,0 +1,25 @@
+# Spec Delta
+
+## MODIFIED Requirements
+
+### Requirement: Shopping flow
+A shopper SHALL be able to browse, view detail, add to cart, checkout with a shipping address, pay, track orders/shipments, confirm delivery, and request an invoice against the live API. Cart, order, shipment and invoice state SHALL be the backend's rather than the browser's, and the fixed-data adapter SHALL remain available as a configured fallback rather than the default. Adding to the cart SHALL require an authenticated shopper: an anonymous add SHALL send the shopper to sign in and return them to where they left off.
+
+#### Scenario: end-to-end purchase
+- **WHEN** a shopper completes checkout on a non-empty cart
+- **THEN** the resulting order appears in the buyer center and the cart is empty
+
+#### Scenario: anonymous add prompts sign-in
+- **WHEN** a signed-out shopper adds an in-stock SKU from a product page
+- **THEN** they are sent to sign in and, once signed in, returned to that product page
+
+### Requirement: Mock transaction flow
+The mall SHALL provide a store-grouped cart, address-selecting checkout preview, payment selection and payment-success result, all reading and writing the live cart and order APIs. Quantity changes, removals, selection totals, checkout and payment SHALL be persisted by the backend for the signed-in shopper, so they survive a page reload.
+
+#### Scenario: complete mock purchase
+- **WHEN** a shopper adds an in-stock SKU, checks out with a mock address and confirms a payment
+- **THEN** the cart is cleared, the success page is shown and the new order appears in the user order list
+
+#### Scenario: cart survives a reload
+- **WHEN** a signed-in shopper adds an item and then reloads the page
+- **THEN** the cart still holds that item, priced and stocked from the catalog