I want to add THREE separate improvements to the existing digital-products store.
IMPORTANT:
This is a separate task from the previous full security/bug audit prompt.
Do NOT mix this task with unrelated fixes from the previous prompt.
The three requested features are:
Product Purchase Count
Verified Buyer Comments/Reviews
Flexible Advertisement Spaces
Before changing ANY file, do:
FULL ANALYSIS
TRACE THE EXISTING IMPLEMENTATION
CREATE A DETAILED IMPLEMENTATION PLAN
SHOW ALL FILES, DATABASE MODELS, API ROUTES, COMPONENTS, AND LOGIC THAT WOULD BE AFFECTED
EXPLAIN HOW YOU WILL PRESERVE EXISTING FUNCTIONALITY
ANALYSIS + PLAN ONLY.
DO NOT MODIFY, CREATE, DELETE, MIGRATE, OR REFACTOR ANYTHING YET.
Wait for my explicit approval before implementing.
==================================================
FEATURE 1 — PRODUCT PURCHASE COUNT
Add a reliable “Purchase Count” / “Times Purchased” statistic for every product.
The purpose is to show customers how many times a product has actually been purchased.
IMPORTANT:
Do NOT simply count all Order records.
First inspect the existing database schema and order/payment status system and determine exactly which order/payment statuses represent a successful/confirmed purchase.
The purchase count must:
Count only successfully paid/confirmed purchases.
NOT count abandoned orders.
NOT count cancelled orders.
NOT count failed payments.
NOT count pending/unpaid orders.
NOT count test/invalid orders if the existing system has such a concept.
Follow the existing payment/order logic instead of creating a second incompatible definition.
If an order contains multiple quantities of the same product, determine from the existing schema whether “purchase count” should represent:
number of successful orders containing the product, OR
total quantity purchased.
Prefer the interpretation that is most consistent with the current store’s existing order model, but explain your choice in the analysis before implementation.
The value must be calculated server-side from trusted database data.
Do NOT allow users to manipulate the purchase count from the client.
==================================================
WHERE PURCHASE COUNT SHOULD APPEAR
Inspect the existing storefront UI and determine the appropriate locations.
At minimum, evaluate:
Product cards/grid
Product details page
Search results if they reuse product cards
Category/filter results if they reuse product cards
Use the existing design system and components.
Do NOT create a completely new visual style.
The purchase count should look natural and professional.
Example:
“125 purchases”
or an appropriate translated equivalent.
The exact wording must support:
English
Arabic
Russian
Add proper translation keys instead of hardcoded text.
Make sure Arabic RTL layout remains correct.
==================================================
FEATURE 2 — VERIFIED BUYER PRODUCT COMMENTS/REVIEWS
Fix and improve the existing product comments/reviews system.
The new rule must be:
ONLY REGISTERED USERS WHO CAN PROVE THEY PURCHASED THE SPECIFIC PRODUCT MAY POST A COMMENT/REVIEW.
Simply having an account must NOT be enough.
A random registered user must not be able to comment on any product.
A visitor/guest must not be able to comment.
==================================================
PURCHASE CODE VERIFICATION
When a registered user attempts to submit a comment/review, require them to enter the purchase/product code they received from their purchase.
IMPORTANT:
Do NOT trust the submitted code merely because it has the correct format.
The server must verify the code against trusted database records.
The verification must establish that:
The user is authenticated.
The submitted purchase code exists.
The purchase code belongs to the authenticated user/customer.
The purchase/order is associated with the product being reviewed.
The purchase/order represents a successful/valid purchase according to the existing payment/order status system.
The purchase code has not been invalidated/revoked if the existing system supports this.
The product actually belongs to that purchase/order.
Never rely on client-side validation for these checks.
All important verification must happen server-side.
==================================================
VERY IMPORTANT — DO NOT ACCEPT A RANDOM PRODUCT CODE
Do NOT implement something like:
“if code exists, allow comment.”
The system must prove that the authenticated user owns a valid purchase for THAT SPECIFIC PRODUCT.
Example:
User A purchases Product X.
User A receives Purchase Code X.
User A can use that valid code to review Product X.
User A must NOT be able to use that code to review Product Y.
User B must NOT be able to use User A’s code to review Product X.
An unauthenticated visitor must not be able to use the code.
==================================================
DUPLICATE REVIEW / CODE REUSE
Inspect the existing review/comment rules before deciding how to handle duplicate reviews.
Determine whether the current system allows:
one review per user per product
multiple reviews
review editing
review deletion
replies/moderation
Do not unnecessarily change existing behavior.
However, prevent abuse of the purchase verification code.
If the existing system is designed for one verified review per purchase/product, enforce that safely.
If multiple purchases of the same product should allow multiple reviews, explain how that will work.
Do NOT silently introduce a restrictive rule without analyzing the current behavior first.
==================================================
SECURITY REQUIREMENTS FOR COMMENTS
Audit the entire comment/review submission flow:
UI
→ API request
→ authentication
→ authorization
→ purchase-code validation
→ product ownership
→ database write
→ cache/revalidation
Check for:
IDOR
forged product IDs
forged customer IDs
forged order IDs
forged purchase codes
client-side-only validation
unauthenticated POST requests
bypassing the UI and directly calling the API
changing the product ID in the request
using another customer’s purchase code
replaying a purchase code
duplicate submissions
XSS through comment text
HTML/script injection
missing length limits
rate limiting
spam/abuse
race conditions where relevant
The API must enforce the same rules even if someone completely bypasses the frontend.
Never trust:
userId sent from the browser
customerId sent from the browser
orderId sent from the browser
productId alone
“isVerified” flags from the client
any other client-controlled authorization field
Derive sensitive identity/authorization information from the authenticated server-side session and trusted database relationships.
==================================================
PURCHASE CODE PRIVACY
Inspect how purchase/delivery codes are currently stored and displayed.
Do not expose sensitive codes unnecessarily.
Do not include full purchase codes in public API responses, HTML, logs, analytics, or public product pages unless the existing architecture absolutely requires it.
If possible, provide a safe verification flow where the server checks the code without exposing it publicly.
==================================================
COMMENTS DISPLAY
Inspect the current comments/reviews display.
Make sure:
only legitimate submitted reviews are accepted
existing valid reviews are preserved
existing moderation functionality remains intact
existing admin review management remains intact
review text is safely rendered
Arabic/English/Russian content works correctly
RTL works correctly
mobile layout remains correct
Light/Dark Mode remains correct
Do not redesign the entire review system.
==================================================
FEATURE 3 — FLEXIBLE ADVERTISEMENT SPACES
Add a flexible advertising system to the storefront that allows me, as the site owner/admin, to place and manage my own advertisements.
The goal is NOT to force a specific advertising provider.
The system should allow me to use my own advertising content and, where appropriate, external advertising networks in the future.
Before implementation, inspect the existing layout and identify suitable advertising placements without disrupting the current UX.
==================================================
AD SPACE MANAGEMENT
Create manageable advertising slots/placements.
The admin should be able to control advertisements without editing source code every time.
Each ad placement should support, where practical:
unique placement/slot identifier
title/name
active/inactive status
display order/priority
start date/time
optional end date/time
target URL
image/banner
custom HTML
custom JavaScript when explicitly enabled
iframe/embed code
text advertisement
CTA/button
optional mobile-specific creative
optional desktop-specific creative
Do NOT assume every advertisement needs all of these fields.
Design the data model according to what the existing application can safely support.
Explain the proposed structure before implementation.
==================================================
AD TYPES
The advertising system should be flexible enough to support common ad formats, including:
Image/banner ads
Text ads
HTML ads
Custom embed/iframe ads
JavaScript-based ad snippets where appropriate
External ad-network snippets
Promotional cards
Link-based advertisements
Responsive advertisements
Desktop/mobile-specific advertisements
If some ad types introduce security risks, explain how they will be sandboxed or restricted.
Do NOT blindly allow arbitrary JavaScript to execute with full access to the website origin.
==================================================
SECURITY — VERY IMPORTANT
Because advertisements may contain external or custom code, carefully analyze the security implications.
Do NOT create an admin feature that accidentally gives arbitrary users a stored-XSS capability.
The admin ad system must be protected by the existing admin authentication/authorization system.
Never allow normal customers to create or modify advertisements.
Inspect the existing CSP/security-header configuration.
Determine the safest way to support:
external images
external links
iframe embeds
trusted advertising providers
custom HTML
JavaScript ad snippets
If arbitrary JavaScript is supported, strongly consider isolation such as:
sandboxed iframe
separate ad rendering context
strict allowlists
controlled CSP
provider/domain allowlisting
Do NOT weaken the entire site’s CSP simply to make advertisements work.
Do NOT allow an advertisement to access:
user authentication cookies
admin sessions
local storage containing sensitive information
private API data
checkout/payment information
Explain the security model in the analysis.
==================================================
AD PLACEMENTS
Inspect the existing storefront and propose suitable ad slots.
Potential examples include:
homepage banner
homepage content section
between product sections
product listing page
between product cards
product details page
sidebar on desktop
footer/banner area
mobile-specific banner area
Do NOT automatically add advertisements everywhere.
Recommend a reasonable initial set of placements based on the existing UI.
The advertisements must not destroy the current product browsing experience.
Do not place ads over:
navigation
checkout controls
payment buttons
product purchase buttons
important account/security UI
Avoid intrusive popups unless I explicitly request them.
==================================================
ADMIN AD MANAGEMENT UI
Create or extend the appropriate admin functionality so I can manage ads from the admin panel.
The admin should be able to:
create an advertisement
edit an advertisement
activate/deactivate an advertisement
select its placement
reorder advertisements if applicable
schedule an advertisement
upload an image if applicable
enter a target URL
select the advertisement type
preview the advertisement when practical
delete an advertisement when appropriate
Use the existing admin design patterns.
Do NOT create a completely separate admin design system.
Protect all ad-management API routes using the existing authorization system.
==================================================
AD IMAGE UPLOADS
If the existing media/upload system can be reused, prefer reusing it.
Inspect existing upload validation.
For advertisement images:
validate MIME type
validate file extension
enforce reasonable size limits
sanitize filenames
prevent dangerous file types
prevent path traversal
do not allow executable files
preserve the existing secure upload architecture
Do not duplicate an existing upload system unnecessarily.
==================================================
AD TRACKING
Do NOT automatically add invasive user tracking.
If implementing basic statistics is practical, analyze whether the system can safely support:
impressions
clicks
without collecting unnecessary personal information.
Do not add third-party tracking unless explicitly requested.
If click/impression tracking is proposed, explain:
what data is stored
how it is aggregated
how abuse is prevented
performance implications
Do not make analytics a requirement if it would significantly complicate the existing system.
==================================================
INTERNATIONALIZATION
Any admin/storefront text added by this feature must support:
English
Arabic
Russian
Use the existing translation architecture.
Do not hardcode user-facing labels.
Check:
RTL
mobile
Light Mode
Dark Mode
==================================================
PERFORMANCE
Advertisement loading must not significantly slow down the website.
Analyze:
image lazy loading
responsive image sizing
external scripts
iframe loading
caching
database queries
SSR/CSR behavior
Avoid unnecessary database queries on every product card.
If advertisements are fetched from the database, use an efficient query and reuse existing caching/data-fetching patterns where possible.
Do not create an N+1 query problem.
==================================================
DATABASE / PRISMA
Inspect the existing Prisma schema before proposing changes.
Determine whether database changes are required for:
purchase count
verified purchase reviews
advertisements
Do NOT add unnecessary fields/tables.
If schema changes are required, explain:
models
relations
indexes
constraints
migration impact
backward compatibility
Do not delete existing orders, purchases, products, customers, or reviews.
Do not modify Prisma migration history unnecessarily.
==================================================
API DESIGN
Inspect the existing APIs first.
Prefer extending existing APIs where appropriate rather than creating duplicate systems.
All sensitive authorization must be server-side.
Advertisement management APIs must be admin-protected.
Review APIs must require authentication and verified purchase authorization.
Purchase count must be derived from trusted server/database data.
==================================================
TESTING PLAN
Before implementation, provide a detailed test plan.
PURCHASE COUNT:
Product with zero successful purchases.
Product with one successful purchase.
Product with multiple successful purchases.
Pending order must not increase count.
Cancelled order must not increase count.
Failed payment must not increase count.
Successful payment must increase count.
Refresh/reload shows correct count.
Search/category pages show correct count if implemented there.
No N+1 query problem.
REVIEW AUTHORIZATION:
Guest tries to comment → rejected.
Registered user without purchase → rejected.
Registered user with valid purchase code for Product A → allowed for Product A.
Same user tries to use Product A code on Product B → rejected.
User A tries to use User B’s purchase code → rejected.
Invalid/random code → rejected.
Valid-looking forged code → rejected.
Cancelled/unpaid purchase code → rejected.
Direct API request without frontend → still protected.
Modified product ID → rejected.
Modified user/customer ID → ignored/rejected.
Duplicate/replayed code behavior follows the approved design.
Malicious HTML/script in comment → safely handled.
Excessively long comment → rejected safely.
Rate limiting/spam protection works according to the existing system.
ADVERTISEMENT SYSTEM:
Admin can create an ad.
Unauthorized user cannot create an ad.
Unauthorized user cannot modify an ad.
Unauthorized user cannot delete an ad.
Active ad appears in its assigned placement.
Inactive ad does not appear.
Scheduled ad respects start date.
Expired ad stops displaying.
Image advertisement renders correctly.
Text advertisement renders correctly.
HTML advertisement follows the approved security model.
Iframe/embed advertisement is isolated appropriately.
External links work safely.
Mobile-specific creative works correctly.
Desktop-specific creative works correctly.
Arabic/RTL layout works.
Light/Dark Mode works.
Advertisement does not cover purchase/payment/navigation controls.
Advertisement does not expose private user/admin data.
CSP/security headers remain appropriately restrictive.
No major performance regression.
No N+1 database queries.
Existing storefront functionality remains intact.
==================================================
MINIMAL-DIFF RULE
Do not:
redesign the website
change unrelated UI
change the Telegram system
change AppNav/NavApps
change product deletion behavior
change payment providers
change authentication architecture unnecessarily
upgrade dependencies unnecessarily
rewrite unrelated components
remove existing functionality
Only make changes required for:
Purchase Count
Verified Buyer Comments/Reviews
Flexible Advertisement Spaces
Preserve all existing behavior outside these features.
==================================================
ANALYSIS OUTPUT FORMAT
Before implementation, return:
A. CURRENT PURCHASE COUNT / ORDER ARCHITECTURE
B. CURRENT REVIEW/COMMENT ARCHITECTURE
C. CURRENT PURCHASE CODE / DELIVERY CODE ARCHITECTURE
D. CURRENT ADVERTISEMENT / MEDIA ARCHITECTURE
E. SECURITY RISKS FOUND
F. EXACT FILES THAT NEED CHANGES
G. DATABASE CHANGES, IF ANY
H. API CHANGES
I. UI CHANGES
J. AD PLACEMENTS PROPOSED
K. SUPPORTED AD TYPES AND SECURITY MODEL
L. INTERNATIONALIZATION CHANGES
M. PERFORMANCE CONSIDERATIONS
N. TEST PLAN
O. BACKWARD-COMPATIBILITY RISKS
P. EXACT IMPLEMENTATION STEPS
Then STOP.
Do not implement anything until I explicitly approve the plan.
After approval, implement only the approved changes with minimal diff and provide a final summary of:
files changed
database changes
API changes
purchase count logic
verified buyer logic
advertisement system
advertisement security model
security protections
tests performed
build/type-check results
any remaining limitations