james/vmall
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

chore(openspec): archive add-flash-sales

Browse Source 
Sync the flash-sales capability plus the order, frontend-mall, and
frontend-shop-admin requirements into the main specs, and write the capability
Purpose the archive leaves as a placeholder.

Restate the flash-price and coupon-exclusion scenarios in the group-buying
order delta, since its MODIFIED checkout block must carry the scenarios the main
order spec now has.
This commit is contained in:
james
2026-09-18 12:53:26 +00:00
parent b15a246c3f
commit c93bff28b0
13 changed files with 85 additions and 12 deletions
Download Patch File Download Diff File Expand all files Collapse all files
openspec/specs/flash-sales/spec.md
+31
View File
@@ -0,0 +1,31 @@
# flash-sales Specification
## Purpose
Let a shop run timed flash sales on its own SKUs. A session owns a window and per-SKU activity items with fixed pricing, reserved inventory, and a per-customer limit. Shoppers browse only active sessions, and checkout resolves activity pricing server-side: eligible quantity gets the activity price while any remainder keeps the catalog price, both inventories decrement together, and a pending-payment cancellation restores them. Activity pricing and coupons are mutually exclusive on one shop order.
## Requirements
### Requirement: Shop flash-sale configuration
Shop users SHALL manage only their own timed flash-sale sessions and SKU activity items. An item SHALL have a fixed minor-unit sale price, currency, reserved stock, per-customer limit, and belong to an active SKU owned by the session shop. The service SHALL reject a SKU that already has an overlapping active group-buying activity.
#### Scenario: cross-shop SKU rejected
- **WHEN** a merchant adds another shop's SKU to a flash-sale session
- **THEN** the API rejects it without creating an activity item
#### Scenario: overlapping group-buy SKU rejected
- **WHEN** a merchant adds a SKU that already has an overlapping active group-buying activity
- **THEN** the API rejects it without creating an activity item
### Requirement: Public active flash-sale discovery
Customers SHALL list active sessions and their eligible products with current sale price, remaining activity stock, and sell-through information. Inactive, disabled, or elapsed items SHALL not be purchasable as flash-sale items.
#### Scenario: window closes
- **WHEN** a session end time has passed
- **THEN** it is absent from active discovery and checkout applies the normal SKU price
### Requirement: Flash-sale purchase limit and inventory
Checkout SHALL enforce the activity's remaining stock and each customer's purchase limit atomically with normal SKU stock. A successful order SHALL retain the applied activity item and final price snapshot.
#### Scenario: quantity exceeds limit
- **WHEN** a customer checks out a flash-sale SKU above the remaining per-customer allowance
- **THEN** only eligible activity quantity receives the activity price and any other quantity follows normal availability and price