Problem: ActivateClubMembership overwrites ActivatedAt on re-purchase,
losing the original club activation date. Commission check uses
ActivatedAt to determine 'new member this week'.
Solution: New ClubMembershipCycle table
- Each package purchase creates a new cycle record
- ClubMembership.ActivatedAt = first-time only (never overwritten)
- Commission uses Cycle.PackagePurchasedAt instead of ActivatedAt
- IsCurrentCycle flag tracks active cycle
- Full history preserved for all purchase cycles
Also updated:
- SPEC: section 7.5 (entity), 7.6 (migration), 8.2 (SP change), 8.3 (handler)
- PLAN: phase 1 (entity), phase 2 (activate handler), phase 4 (date query)
- Checklist: added 4 new items
- Exit requires BOTH simultaneously: Balance==0 AND TotalDeposited>=100M
- If Balance=0 but cap not reached → still Magic (can charge more)
- If cap reached but Balance>0 → still Magic (can spend more)
- Added examples: partial deposit (50M/100M) stays in Magic
- Fixed handler 8.1 pseudo-code
- Updated test scenarios in PLAN (7 scenarios covering edge cases)
- Cap resets every time user buys a new 56M package and re-enters Magic
- MagicTotalDeposited & MagicTotalCredited reset to 0 on each new cycle
- Added multi-cycle example (cycle 1, 2, 3... ∞)
- Added section 4.3: reset behavior on re-entry
- Added test scenarios for cycle reset
- PurchaseCycleCount tracks cycles but has no limit
- New folder: roadmap/ for upcoming features
- MAGIC-WALLET-SPEC: full business rules, state machine, x2.5 multiplier,
100M deposit cap, API flow, data model changes, transaction logging
- MAGIC-WALLET-PLAN: 6-phase implementation, checklist, time estimates
- Note: ChargeDiscountWallet completion is independent (not Magic Wallet)
- Note: WalletChangeLog is mandatory (not optional)
- Updated master index with roadmap section
masoodafar-web