IMPORTANT — FULL BUG + SECURITY AUDIT, SAFE CLEANUP, AND SPECIFIC UI REMOVALS
I want you to perform a professional production-level audit of the entire project.
The highest-priority issue is the product deletion functionality.
I discovered that when I click the “Delete Product” button in the admin panel, the product does NOT actually get deleted.
Do NOT assume the cause. Trace the complete deletion flow and identify the real root cause.
1. FIRST: ANALYSIS ONLY
Before modifying anything:
Inspect the complete product deletion flow.
Identify the UI component/button responsible for deletion.
Identify the frontend request/action triggered by deletion.
Identify the corresponding API/server action.
Inspect authentication and authorization checks.
Inspect Prisma/database deletion logic.
Inspect foreign-key relationships and dependent records.
Inspect validation and error handling.
Inspect whether the deletion request is actually sent.
Inspect the HTTP response/status.
Inspect server logs/error handling where applicable.
Check whether the UI incorrectly reports success even when the database operation fails.
Check whether cache/revalidation causes a deleted product to appear again.
Then inspect the rest of the project for other functional bugs and security issues.
DO NOT MODIFY ANY FILE YET.
At the end of the analysis, provide:
Root cause of the product deletion problem.
Exact files/components involved.
Other bugs discovered.
Security vulnerabilities discovered.
Unnecessary/orphaned data discovered.
UI components requested for removal.
Severity of each issue: Critical / High / Medium / Low.
Exact minimal-diff fix plan.
Files that will be modified.
Files that will NOT be modified.
Data that is safe to remove.
How each fix will be tested.
Then STOP and wait for my approval.
2. PRODUCT DELETE — HIGH PRIORITY
The delete operation must be a REAL database deletion when the admin confirms deletion.
Verify the entire flow:
Admin UI
→ delete confirmation
→ request/server action
→ authentication
→ authorization
→ validation
→ database operation
→ related records
→ cache invalidation/revalidation
→ updated UI
The final result must guarantee that:
Unauthorized users cannot delete products.
Non-admin users cannot bypass the UI and call the deletion endpoint directly.
Invalid product IDs are rejected safely.
Missing products return an appropriate error.
Related database records are handled correctly.
The database transaction does not leave orphaned records.
The UI only shows success when deletion actually succeeds.
Failed deletion shows a clear error.
The deleted product does not reappear after refresh.
Search/filter/category pages no longer return the deleted product.
Admin product lists update correctly after deletion.
Do NOT solve the problem by merely hiding the product from the frontend.
The database state must be correct.
3. SECURITY AUDIT
Perform a defensive security audit of the entire application.
Look specifically for:
Authentication
Authentication bypass
Missing authentication checks
Broken session handling
Insecure logout/session invalidation
Password/reset flow weaknesses
Email verification weaknesses
Privilege escalation
Authorization / IDOR
Check every admin-sensitive operation for proper server-side authorization.
Especially:
Products
Categories
Orders
Users
Admin accounts
Media/files
Telegram-related administration
Settings
Any API endpoint containing an ID
Any mutation endpoint
Do NOT trust frontend checks.
Authorization must be enforced server-side.
API Security
Inspect API routes for:
Missing authentication
Missing authorization
IDOR
Improper input validation
Unsafe parameters
Mass assignment
Missing rate limiting where appropriate
Excessive data exposure
Incorrect HTTP methods
Information leakage through error messages
Unsafe handling of user-controlled values
Database Security
Inspect Prisma/database operations for:
Unsafe queries
Missing validation
Incorrect cascade behavior
Orphaned records
Race conditions
Transaction problems
Data integrity issues
Sensitive data exposure
Do NOT replace Prisma with raw SQL unless there is a demonstrated technical requirement.
File / Upload Security
Inspect image/media upload functionality for:
File type validation
MIME validation
File extension validation
File size limits
Dangerous file uploads
Path traversal
Filename manipulation
Unauthorized access to uploaded files
XSS / Injection
Inspect user-controlled data rendered into:
Product names
Product descriptions
Category names
User profiles
Telegram-related content
Admin interfaces
Search/filter parameters
Check for XSS, HTML injection, command injection, and other injection risks where applicable.
Do NOT introduce unsafe dangerouslySetInnerHTML.
If HTML rendering is intentionally required, ensure it is properly sanitized.
CSRF / Request Protection
Inspect state-changing operations and determine whether CSRF protection is required by the application’s authentication architecture.
Secrets
Search the project for:
API keys
Tokens
Passwords
Private keys
Hardcoded credentials
Secrets accidentally exposed to client-side code
Sensitive environment variables imported into browser/client components
Never expose server-only secrets to the client.
Do NOT print actual secret values in the audit report.
Security Headers / Configuration
Inspect production configuration for appropriate protections such as:
Content Security Policy where practical
X-Content-Type-Options
Referrer-Policy
Frame protections
Secure cookie configuration
Appropriate CORS configuration
Production error handling
Debug information exposure
Only add security headers that are compatible with the existing application and do not break legitimate functionality.
4. GENERAL BUG AUDIT
Also inspect the project for functional problems in:
Product creation
Product editing
Product deletion
Product publishing
Categories
Search
Filters
Pagination
Authentication
Registration
Login/logout
Password reset
Email verification
User profiles
Orders
Checkout/payment-related flows
Telegram integration
Admin dashboard
Media uploads
Multilingual UI
Arabic RTL
Light/Dark mode
Mobile responsiveness
API routes
Database operations
Cache/revalidation
Error states
Loading states
Do not change functionality simply because you prefer a different implementation.
Only fix actual bugs, security vulnerabilities, or clearly requested changes.
5. REQUESTED UI REMOVALS
These are intentional changes I explicitly want.
A. Remove the Categories entry from the homepage sidebar
Find the sidebar/navigation menu on the main homepage of the website.
There is a Categories / التصنيفات / Категории entry in the sidebar.
Remove the Categories entry from that sidebar completely.
Important:
Remove only the sidebar navigation entry.
Do NOT delete the Categories page itself.
Do NOT delete the Category database table/model.
Do NOT delete product-category relationships.
Do NOT break category filtering.
Do NOT remove the category filter tiles from /products.
Do NOT remove category management from the admin panel.
Do NOT delete category data.
The requirement is specifically to remove the Categories navigation item from the homepage sidebar.
B. Remove the App Navigation management section from the Admin Panel
Find the App Navigation / NavApp management section in the admin dashboard.
Remove the Admin Panel UI section/page/menu entry used to manage App Navigation/NavApps.
This is specifically requested.
However:
Do NOT delete unrelated application navigation functionality.
Do NOT delete products.
Do NOT delete categories.
Do NOT delete the product category/filter system.
Do NOT modify Telegram functionality.
Do NOT modify the storefront category tiles.
Do NOT modify unrelated admin sections.
Before removing it, identify exactly which files/components/routes are responsible for the App Navigation management UI.
If removing the admin management UI would break the existing storefront AppNav bar, report that dependency during ANALYSIS and PLAN.
Do NOT blindly delete shared NavApp backend/database code if it is still required elsewhere.
The objective is to remove the unwanted Admin Panel management interface, while preserving unrelated functionality unless it is confirmed to be unused.
6. UNUSED DATA / DATABASE CLEANUP
Inspect the project for unnecessary, obsolete, duplicated, or orphaned data.
This includes:
Unused database records
Orphaned records
Products/categories/media that are no longer referenced
Old test/demo data
Duplicate records
Deprecated configuration records
Unused database fields or legacy structures
Unused files/assets
Temporary files
Old logs/cache data where safe to remove
Database records created by previous testing
Broken references
Records belonging to deleted entities
VERY IMPORTANT — DO NOT DELETE DATA BLINDLY
First perform a complete inventory.
For every candidate item, determine:
What is it?
Where is it referenced?
Is it used by the application?
Is it required by another feature?
Is it required for historical records?
Is it required for Telegram/order/payment functionality?
Is it required for authentication or security?
Is it safe to remove?
What would break if it were removed?
Classify each candidate as:
SAFE TO DELETE
KEEP
NEEDS MANUAL REVIEW
During the initial ANALYSIS + PLAN phase:
DO NOT DELETE ANY DATA, FILES, DATABASE RECORDS, TABLES, COLUMNS, USERS, PRODUCTS, ORDERS, PAYMENTS, MEDIA, OR MIGRATIONS.
Only report what can potentially be removed.
After I approve the cleanup plan, delete ONLY items explicitly determined to be safe.
Never delete users, orders, payment records, or transaction history merely because they are not currently displayed.
Do NOT remove Prisma migration history unless there is an explicit, separately approved migration strategy.
7. IMPORTANT — PRESERVE EXISTING FUNCTIONALITY
Do NOT redesign the website.
Do NOT change:
Existing visual identity
Product business logic
Telegram bot functionality
Product category/filter design that was recently approved
Existing translations
Existing payment logic
Existing integrations
Existing storefront functionality
unless the audit proves that a change is necessary to fix a bug/security vulnerability or it is explicitly requested above.
Use a minimal-diff approach.
Do not refactor unrelated code.
Do not upgrade dependencies unless required for a specific security issue or compatibility problem.
If a dependency has a security vulnerability, identify:
Package
Current version
Vulnerability
Safe version
Compatibility impact
before changing it.
8. ERROR HANDLING
Make sure server-side failures are handled properly.
Never silently swallow errors.
For every important mutation:
Return an appropriate status/error.
Log useful diagnostic information server-side.
Never expose secrets or sensitive internal information to users.
Show the admin a useful but safe error message.
For deletion specifically, distinguish between:
Successful deletion
Product not found
Unauthorized
Validation failure
Database failure
Related-record constraint failure
Unexpected server error
9. TESTING
After fixes are approved and implemented, test the actual behavior.
Product deletion
Delete an existing product as an authorized admin.
Confirm the product disappears from the admin list.
Refresh the page.
Confirm it does not return.
Open its direct product URL.
Confirm it is no longer available.
Search for it.
Filter by its category.
Confirm it is gone.
Attempt deletion of a nonexistent product.
Attempt the deletion request without proper authorization.
Confirm unauthorized deletion is rejected.
UI removals
Verify:
Categories is no longer shown in the homepage sidebar.
The Categories page itself still works.
Category filtering on /products still works.
Category management in Admin still works.
The App Navigation/NavApp management UI is removed from Admin.
No unrelated Admin functionality disappears.
Existing storefront functionality that depends on NavApp is not accidentally broken unless explicitly approved.
Regression testing
Verify:
Product creation still works.
Product editing still works.
Product loading still works.
Search still works.
Filters still work.
Categories still work.
Orders still work.
Authentication still works.
Telegram functionality still works.
Arabic/English/Russian still work.
Light/Dark mode still work.
Run appropriate checks such as:
TypeScript check
Lint
Production build
Relevant tests
Database/schema validation
If possible, test the real production build rather than relying only on static analysis.
10. SECURITY PRIORITY
Do not attempt destructive security testing against external systems.
Only inspect and test this project’s own code and local/development environment.
Use safe, non-destructive verification.
Do not create malware, exploit payloads, persistence mechanisms, credential theft mechanisms, or attack tooling.
The goal is to identify and securely fix vulnerabilities in this application.
11. FINAL REPORT
After implementation, provide a concise final report containing:
Bugs Fixed
Issue
Root cause
Fix
Files changed
Security Issues Fixed
Vulnerability
Severity
Root cause
Fix
Requested UI Changes
Categories sidebar entry removed
Admin App Navigation management UI removed
Cleanup
Data/files removed
Why they were safe to remove
Tests
TypeScript
Lint
Build
Functional tests
Security checks
Remaining Issues
Clearly list anything that could not be verified or fixed.
IMPORTANT:
Do not claim something is secure merely because no obvious vulnerability was found.
State what was actually inspected and tested.
MOST IMPORTANT:
Do not start modifying the project yet.
Start with:
ANALYSIS + PLAN ONLY
and wait for my explicit approval.
::