Files
vmall/openspec/changes/archive/2026-09-18-add-group-buying/specs/group-buying/spec.md
T
james cdfb1b06f2 chore(openspec): archive add-group-buying
Sync the group-buying 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. This closes the last of the five
planned marketing changes.
2026-09-18 13:22:47 +00:00

2.4 KiB

ADDED Requirements

Requirement: Shop group-buying activities

Shop users SHALL manage only their timed group-buying activities, each bound to one owned SKU with localized display content, fixed minor-unit group price, required paid-member count of at least two, group lifetime, and a per-order activity quantity of 1. The service SHALL reject a SKU that already has an overlapping active flash-sale item.

Scenario: invalid participant target

  • WHEN a merchant configures a group activity requiring fewer than two paid members
  • THEN the API rejects the activity

Scenario: overlapping flash-sale SKU rejected

  • WHEN a merchant publishes a group activity for a SKU that already has an overlapping active flash-sale item
  • THEN the API rejects the activity

Requirement: Customer group discovery and intent

Customers SHALL discover active group-buying activities and open groups. A customer MAY initiate checkout by opening a new group or selecting an open eligible group for exactly one activity SKU at quantity 1.

Scenario: join an open group

  • WHEN a shopper selects an active open group and checks out its activity SKU
  • THEN the resulting pending-payment order identifies that group and snapshots the group price

Requirement: Group membership and lifecycle

Payment SHALL atomically claim a paid membership in an open unexpired group. A group SHALL become successful exactly when paid member count reaches its required count; it SHALL become expired when its lifetime ends before success; it SHALL become cancelled when its opening pending-payment order is cancelled while paid member count is zero. A full, expired, or cancelled group SHALL reject payment without changing order state.

Scenario: concurrent final seat

  • WHEN two pending group orders attempt payment for one final seat concurrently
  • THEN exactly one payment succeeds and the group becomes successful

Scenario: expired paid group

  • WHEN an open group expires before reaching its required count
  • THEN it is marked expired and its paid orders remain identifiable for a later refund flow

Scenario: unpaid opener cancel closes an empty group

  • WHEN the opening pending-payment order is cancelled and the group still has zero paid members
  • THEN the group becomes cancelled, SKU stock is restored, and later join or payment for that group returns 409