Capture exclusive promotion composition, empty-group cancel, and mall surface scope so the five marketing changes can be implemented without stacking or lifecycle ambiguity. Co-authored-by: Cursor <cursoragent@cursor.com>
26 lines
1.4 KiB
Markdown
26 lines
1.4 KiB
Markdown
## Why
|
|
|
|
Account statistics are fixed mall fixtures, and points redemption needs an auditable balance rather than mutable user fields. A customer account boundary establishes safe balances and append-only history before any points-spend flow is introduced.
|
|
|
|
## What Changes
|
|
|
|
- Add one customer account per supported balance: cash balance, frozen cash, and integer loyalty points.
|
|
- Add append-only account entries that record the resulting balance, signed delta, reason, reference type, and reference ID.
|
|
- Add an authenticated customer account summary endpoint and replace the account-stat fixture on the mall user center.
|
|
- Provide transactional service operations for later flows to credit, debit, freeze, and release funds or points with non-negative-balance checks.
|
|
|
|
## Capabilities
|
|
|
|
### New Capabilities
|
|
- `customer-accounts`: Customer balance and points accounts, immutable entries, account summary, and guarded balance mutations.
|
|
|
|
### Modified Capabilities
|
|
- `frontend-mall`: User-center account statistics load through the shared API client.
|
|
|
|
## Non-goals
|
|
|
|
No top-up, payment-from-balance, withdrawal, refund-to-balance, points earning campaign, merchant settlement, or public account-entry listing is included. The frozen monetary kind is reserved for later freeze/release flows.
|
|
|
|
## Impact
|
|
|
|
Adds Rust account module and migrations, shared account types/API/locales, a mall live-data migration, and a reusable transactional dependency for the points mall. |