I want this project to be **fully finished, polished, production-ready, and reliable before deployment**. Read and follow `guideline.md` and `README.md` completely before making changes. The goal is for this application to look and behave like a **real, reliable food-ordering and cashless-payment system**, not a school/demo project. Do not simply make visual changes. Perform a complete review of the existing system and fix unfinished, placeholder, demo, broken, inconsistent, or unrealistic parts. --- ## 1. CONTROL DEMO ACCOUNT EXPOSURE Keep demo accounts disabled by default on production deployments. If a public demo is explicitly required, enable it only on a separate deployment and database with no real customer or payment data. Public demo credentials grant the configured Administrator, Cashier, and Customer permissions; public demo administrators can change application data. Do not use default or shared demo credentials on a live business instance. Follow the opt-in and account-provisioning instructions in `README.md`. --- ## 2. REMOVE DEMO/PLACEHOLDER CONTENT Search the entire project for development/demo content and remove or replace it where appropriate. Look for: * Demo users * Test users * Fake login credentials * Placeholder names * Dummy customer accounts * Sample transactions * Fake orders * Test payment information * Placeholder addresses * Development messages * "Lorem ipsum" * "Coming soon" sections that are supposed to be functional * Debug information * Development-only UI * Temporary buttons * Unused pages * Unfinished features * Console debugging messages * Hard-coded test data Do not delete legitimate system functionality just because it contains data. Only remove information that is clearly intended as demo/test/development content. --- ## 3. PRODUCTION-READY LOGIN AND REGISTRATION Make the authentication system feel like a real application. ### Login Support the existing authentication system properly. Include: * Login validation * Incorrect credential handling * Forgot password * Registration * OTP verification where required * Logout * Session/authentication protection Do not expose sensitive information through error messages. For example, avoid revealing whether a specific email/contact number exists. ### Registration Keep the existing registration flow: **Create Account → Enter Information → OTP Verification → Account Activated → Login** Password requirement: **Minimum 8 characters** Do not require: * Special symbols * Numbers * Uppercase letters * Specific password patterns Passwords must still be securely hashed. --- ## 4. OTP SYSTEM Keep the existing OTP verification system. The customer should receive an OTP when required. The OTP should: * Be a random 6-digit code sent to the registered email address * Expire after 5 minutes and be usable only once * Be securely hashed in the database * Be invalidated when a new code is generated * Limit incorrect attempts and rate-limit resend requests * Require successful email verification before activating the account Do NOT display: * Attempt counters * Attempts remaining * Attempt countdowns * OTP codes Configure Gmail SMTP over TLS using private server environment variables and a Gmail App Password. Never expose email credentials in frontend code. SMS delivery is not used for customer registration. --- ## 5. REALISTIC CUSTOMER EXPERIENCE Review the complete customer flow: ```text Register ↓ OTP Verification ↓ Login ↓ Browse Menu ↓ Select Food ↓ Add to Cart ↓ Review Cart ↓ Checkout ↓ Select Delivery Address ↓ Select Payment Method ↓ Complete Payment ↓ Order Confirmation ↓ Track/View Order ↓ Order History ↓ Account/Profile ``` Every step should work properly. There should be no dead buttons or unfinished pages. --- ## 6. DELIVERY ADDRESS Keep the existing delivery-address functionality. Customers should be able to choose: ### Use Current Location Allow the customer to grant location permission and use their GPS location. Display: * Map/location marker where supported * Latitude * Longitude * Detected address when available * Confirmation option ### Enter Address Manually Allow: * City/Municipality * Barangay * Street/House Number * Landmark * Delivery instructions The customer must confirm a valid delivery address before placing the order. Do not force location access. If the customer denies location permission, they should still be able to manually enter their address. --- ## 7. GCash-ONLY CUSTOMER PAYMENT Customer checkout uses the configured Xendit one-time GCash Payments API flow when enabled, or manual GCash receipt submission when configured. For Xendit, create the application order only after authenticated server-side verification confirms the correct business, reference, amount, currency, country, GCash channel, and successful status. For manual GCash, keep the payment pending until an Administrator verifies it in the merchant account. Validate webhook callback tokens and independently retrieve provider records. Do not accept a redirect, screenshot, customer reference, or static QR as proof of payment. Cashier and Staff roles are obsolete; historical cash-payment records are retained. Keep GCash checkout disabled until merchant approval, credentials, required migrations, HTTPS webhook setup, and staging tests are complete. Never store: * CVV * Card PIN * GCash PIN * GCash PIN * OTP * Full sensitive payment credentials Never claim that a static QR automatically confirms or encodes an order payment. --- ## 8. CUSTOMER ACCOUNT Keep the Customer Account page. Customers should be able to: * View their information * Edit their information * Update their delivery address * Change their password * Update their contact number * Verify a changed contact number through OTP * View order history * View order details * Logout Only authenticated customers should be able to access their own information. --- ## 9. ADMIN SYSTEM Review the entire admin dashboard. Make sure the admin can properly manage: * Products * Food categories * Customers * Orders * Payments * Delivery information * Order statuses * Successful/completed orders Keep the separate: **Orders** and **Successful Orders** pages. ### Active Orders Show orders that are still being processed: ```text Pending Paid Preparing Ready Out for Delivery ``` ### Successful Orders Only show successfully completed/delivered orders. When an order becomes: **Completed** automatically move it from active Orders to Successful Orders. Preserve all order, customer, delivery, and payment information. --- ## 10. ORDER STATUS Make sure the order status system works consistently. Example: ```text Pending ↓ Paid ↓ Preparing ↓ Ready ↓ Out for Delivery ↓ Completed ``` If the existing project uses different statuses, follow `guideline.md` and `README.md`. Do not allow invalid status transitions. --- ## 11. DATABASE AND DATA INTEGRITY Review the database structure and relationships. Make sure: * Customers are correctly related to orders. * Orders are correctly related to order items. * Payments are correctly related to orders. * Delivery addresses are correctly associated with orders/customers. * Product prices are handled correctly. * Order totals are calculated on the backend. * Deleted products do not break historical orders. * Completed orders remain available for records/history. Do not rely only on frontend calculations for important values. --- ## 12. SECURITY REVIEW Perform a security review before considering the project finished. Check for: * Password hashing * Authentication protection * Authorization/role checking * SQL injection vulnerabilities * XSS vulnerabilities * CSRF protection where appropriate * Input validation * Server-side validation * Secure sessions/tokens * Sensitive information exposure * Hard-coded API keys * Hard-coded passwords * Exposed database credentials * Debug endpoints * Unprotected admin routes * Unauthorized access to customer information * Unauthorized access to other customers' orders Never trust values submitted by the frontend. Important calculations such as: * Product price * Quantity * Order total * Payment amount * User identity * Order ownership must be verified on the backend. --- ## 13. ERROR HANDLING Replace development/debug errors with professional user-friendly messages. Instead of showing: `SQLSTATE[23000]...` or raw server errors to customers, display something like: > Something went wrong. Please try again. Log technical errors securely on the server when appropriate. Do not expose: * Database errors * Stack traces * File paths * API keys * Internal system information * Server configuration --- ## 14. LOADING AND EMPTY STATES Add professional states where appropriate. Examples: **Loading** > Loading your orders... **No Orders** > You don't have any orders yet. **Empty Cart** > Your cart is empty. **No Successful Orders** > No completed orders yet. **Payment Processing** > Processing your payment... Do not leave blank screens. --- ## 15. RESPONSIVE DESIGN Test the application on: * Desktop * Laptop * Tablet * Mobile phone Make sure: * Navigation works on mobile * Food cards resize correctly * Cart works on mobile * Checkout works on mobile * Payment forms work on mobile * Admin tables remain usable * Account pages are responsive * Buttons are easy to tap * Text does not overflow * Modals fit smaller screens --- ## 16. UI/UX POLISH Make the entire system visually consistent. Use consistent: * Typography * Buttons * Colors * Spacing * Icons * Cards * Form fields * Notifications * Status badges * Modal dialogs Remove anything that makes the application look like a prototype. Avoid unnecessary animations or visual effects that reduce usability. The application should feel: **Clean • Professional • Reliable • Fast • Modern** --- ## 17. REALISTIC NOTIFICATIONS Use professional notifications for actions such as: * Registration successful * OTP sent * OTP verified * Profile updated * Password changed * Item added to cart * Order placed * Payment successful * Payment failed * Order status changed Do not use browser `alert()` everywhere if a proper notification/toast system can be implemented. --- ## 18. ENVIRONMENT CONFIGURATION Make sure production secrets are not stored directly in source code. Use environment variables for: * Database credentials * API keys * SMS provider credentials * Payment provider credentials * Application secrets * Authentication secrets Provide/update the appropriate environment example file if needed. Never commit real production credentials. --- ## 19. REMOVE DEVELOPMENT ARTIFACTS Before deployment, check for and remove unnecessary: * Test routes * Debug routes * Development-only buttons * Console logs containing sensitive information * Test credentials * Seed/demo users that should not exist in production * Temporary files * Unused components * Unused imports * Dead code * Duplicate functionality Do not remove necessary production code. --- ## 20. FINAL TESTING Perform a complete end-to-end test before declaring the project finished. ### Customer Test Test: ```text Register → OTP → Login → Browse Food → Add to Cart → Checkout → Delivery Address → Payment → Order Confirmation → Account → Order History ``` ### Admin Test Test: ```text Admin Login → Dashboard → View Orders → Process Order → Update Status → Complete Order → Successful Orders → View Order Details ``` ### Security Test Verify: * Customer cannot access admin pages. * Customer cannot access another customer's account. * Customer cannot access another customer's order. * Unauthenticated users cannot access protected pages. * Admin-only functions require admin authorization. * Passwords are not exposed. * OTPs are not exposed. * Payment-sensitive information is not stored improperly. --- ## 21. FINAL PRODUCTION CHECK Before considering the project complete: * Demo accounts are disabled unless explicitly enabled for an isolated demo deployment. * Public demo credentials are not used on the live business instance. * No placeholder content. * No broken buttons. * No unfinished pages. * No unnecessary debug information. * No exposed secrets. * No raw database errors. * Registration works. * OTP verification works. * Login works. * Customer accounts work. * Profile editing works. * Delivery address works. * Cart works. * Checkout works. * Payment flow works according to the configured integration. * Orders work. * Successful Orders works. * Admin functions work. * Responsive design works. * Database relationships work. * Authentication and authorization work. ### Most Important Instruction **Do not stop at removing the demo accounts.** Review the entire application as if it is about to be deployed and used by real customers. Fix incomplete or unrealistic areas you find while preserving the requirements in `guideline.md` and `README.md`. Do not replace working functionality unnecessarily. Do not create fake production functionality just to make the interface look finished. If a feature requires an external service such as SMS or a payment gateway, make the integration production-ready and configurable through environment variables, while clearly keeping development/test behavior separate. The final result should look and behave like a **real production food-ordering and cashless-payment platform**, not a demonstration or school prototype. After making all changes, run the project, test the important workflows, fix any errors found, and only then consider the implementation complete.