APPROVED — proceed with implementation now according to the approved analysis and plan.
I approve the three features with the following final requirements:
1. Purchase Count
Reuse the existing Product.salesCount as the purchase counter.
The counter represents the number of successful orders containing the product, not the total quantity of units.
Use the existing successful-payment definition already used by the project:
PAID
COMPLETED
Do not count:
PENDING
FAILED
CANCELLED
REFUNDED
EXPIRED
test/invalid orders
Before implementation, verify that salesCount cannot be incremented more than once for the same successful order/order item when the order passes through multiple payment or verification flows.
If the existing architecture already prevents double increment, do not change it unnecessarily.
If a real double-increment risk exists, fix it with the smallest safe change possible while preserving existing data.
Display the purchase count on:
Product cards
Product details
Other relevant storefront locations where the product is displayed
Support:
English
Arabic
Russian
RTL
Light/Dark Mode
Mobile/Desktop
Do not introduce N+1 queries.
2. Verified Buyer Reviews
Change the new-review system so that only registered/authenticated customers who can prove a real purchase of the exact product can submit a review.
IMPORTANT REVIEW RULE
Do NOT enforce:
one review per customer per product
Instead:
One review per successful purchase/order of that product.
Example:
Customer buys Product A once → 1 review opportunity.
Customer buys Product A twice through two different successful orders → 2 separate review opportunities.
Customer buys Product A five times through five different successful orders → up to 5 separate review opportunities.
Each successful purchase/order gives the customer one independent review opportunity.
Review uniqueness
The same purchase must NOT be reusable.
Therefore:
The same Order + Product combination can create only ONE review.
A customer can create multiple reviews for the same product only when they have multiple different successful orders containing that product.
Do not prevent legitimate reviews merely because the same customer already reviewed the same product before.
The logical ownership of a review opportunity is:
Customer + Product + Order
not merely:
Customer + Product
Server-side verification
For every new review:
Require an authenticated registered customer.
Derive the customer identity from the server-side session.
Accept the order number/purchase code from the customer.
Look up the order server-side.
Verify that the order belongs to the authenticated customer.
Verify that the order/payment is successful according to the existing project rules.
Verify that the exact product being reviewed exists in that order.
Verify that this exact Order + Product combination has not already been used for a review.
Only then create the review.
Store the correct customerId, orderId, and productId server-side.
Keep isVerified = true only after the server has successfully verified the purchase.
Keep the existing moderation workflow (PENDING, APPROVED, REJECTED, HIDDEN).
Never trust these values from the client:
userId
customerId
orderId
productId
isVerified
email ownership claims
The server must derive/verify them from the authenticated session and database relationships.
Security tests
Explicitly test:
Guest → rejected.
Registered customer without purchase → rejected.
Registered customer with successful purchase of Product A → can review Product A.
Customer attempts to review Product B using an order containing Product A → rejected.
Customer A attempts to use Customer B’s order → rejected.
Fake/nonexistent order number → rejected.
Pending order → rejected.
Failed order → rejected.
Cancelled order → rejected.
Refunded order → follow the existing successful-purchase rules and do not incorrectly treat an invalid/refunded purchase as successful.
Same Order + Product submitted twice → second review rejected.
Same Customer + Product with a second different successful order → second review allowed.
Same Customer + Product with three different successful orders → up to three review opportunities.
Direct API/curl attempts must follow exactly the same rules as the UI.
Attempted forged IDs must fail.
Attempted forged isVerified=true must fail.
Attempted forged customer/user identity must fail.
Attempted product substitution must fail.
Rate limiting remains enabled.
Review text remains safely escaped.
Validate reasonable input lengths and reject abusive payloads.
Do not expose full purchase/license codes unnecessarily.
3. Advertisement System
Implement the approved manageable advertisement system.
Supported types:
IMAGE
TEXT
IFRAME
Do NOT support arbitrary HTML injection or arbitrary JavaScript execution on the main website origin.
Security requirements
Protect all advertisement management APIs with the existing admin authorization system.
Do not weaken the site’s CSP.
IFRAME advertisements must use a secure sandbox.
External iframe sources must use HTTPS.
Use appropriate referrerPolicy.
Lazy-load external frames.
Advertisement content must not gain access to:
authentication cookies
admin sessions
localStorage containing sensitive data
private APIs
checkout/payment information
account/security information
Use the existing secure media upload system for advertisement images.
Initial ad placements
Implement only these placements for now:
HOME_BANNER
PRODUCTS_LIST
PRODUCT_DETAIL
Do not add advertisements everywhere.
Do not use:
Popups
Full-screen ads
Ads covering navigation
Ads covering product purchase buttons
Ads covering checkout/payment UI
Ads covering account/security controls
Admin controls
The admin should be able to:
Create advertisement
Edit advertisement
Delete advertisement
Activate/deactivate
Set placement
Set order/priority
Set start date
Set end date
Upload image
Set target URL
Select ad type
Preview advertisement
Use the existing admin UI patterns and authorization.
Do not create unnecessary redesigns.
Performance
Avoid N+1 queries.
Use indexed ad queries.
Lazy-load images/iframes where appropriate.
Use responsive sizing.
Do not negatively affect checkout or storefront performance.
Basic impression/click counters may be implemented if practical and safe, but do not introduce invasive tracking.
4. Database Changes
Implement the planned Prisma changes safely.
Expected changes:
Add Ad model.
Add Review.customerId.
Ensure reviews can correctly reference the specific orderId and productId needed for the per-purchase review rule.
IMPORTANT:
The system must support:
Customer + Product + Order → one review
while allowing:
Customer + Product + Order 1 → Review
and:
Customer + Product + Order 2 → another Review
when both orders are valid successful purchases.
Do not delete existing reviews.
Keep existing guest reviews in the database as historical data.
Do not unnecessarily invalidate or modify old reviews.
Do not delete existing orders, customers, payments, products, categories, Telegram data, or other live data.
Do not modify old Prisma migration history.
5. UI / UX
Review UI:
Guest
Show a clear message asking the visitor to sign in/register before submitting a review.
Authenticated customer
Show:
Purchase/order number field
Rating
Review title if supported by the existing UI
Comment
Clearly explain that the order number must belong to the customer and must contain the product being reviewed.
If the customer already used that particular order for a review, show an appropriate message.
If the customer has another valid purchase of the same product, they should still be able to use that different order.
Keep the existing moderation workflow.
Support:
EN
AR
RU
RTL
Light Mode
Dark Mode
Mobile
Desktop
Purchase count should also use proper translations and RTL handling.
6. Minimal-Diff Requirement
Preserve all unrelated functionality.
Do NOT modify unnecessarily:
Telegram bot
Telegram integrations
AppNav/NavApps
Product deletion system
Payment providers
Authentication architecture
Cart
Checkout
Existing admin permissions
Existing moderation functionality
Existing media upload architecture
Do not perform unrelated refactoring.
Do not redesign the website.
Do not introduce unnecessary dependencies.
Only change what is required for these three features and their security.
7. Testing & Validation
After implementation, perform real functional and security testing.
Purchase Count
Test:
No purchases
One successful purchase
Multiple successful purchases
Pending order
Failed order
Cancelled order
Refunded order
Multiple quantities
Multiple different successful orders
Double-increment protection
Reviews
Test:
Guest
Authenticated non-buyer
Valid buyer
Wrong product
Wrong customer/order ownership
Fake order
Pending payment
Failed payment
Cancelled order
Refunded order
Same Order + Product twice
Same Customer + Product using different successful orders
Multiple valid purchases → multiple valid review opportunities
Direct API/curl bypass
Forged IDs
Forged verification fields
XSS payloads
Input length limits
Rate limiting
Concurrent duplicate submissions where practical
Advertisements
Test:
Admin create
Admin edit
Admin delete
Activate/deactivate
Scheduling
IMAGE
TEXT
IFRAME
Invalid iframe URL
Unauthorized API access
Placement rendering
Mobile/desktop
RTL
Light/Dark
CSP/security headers
No interference with purchase/checkout
No N+1 queries
Build checks
Run:
npx tsc --noEmit
npx next build
Run Prisma/schema validation and the project’s relevant tests.
Also perform a regression check of the existing storefront and admin functionality.
8. Final Report
When finished, provide a clear final report containing:
Files created
Files modified
Prisma/schema/migration changes
Purchase Count implementation
Double-increment protection result
Verified Buyer Review implementation
Exact Customer + Product + Order review rule
Advertisement system implementation
Security protections
Tests performed
Test results
TypeScript result
Production build result
Any remaining warnings or risks
Do not claim a test passed unless it was actually executed.
Proceed with implementation now.