MAX AUTOMATION — FINAL STRICT BRANDING, REAL-FUNCTIONALITY A...

Prompt

MAX AUTOMATION — FINAL STRICT BRANDING, REAL-FUNCTIONALITY AND PRODUCTION AUDIT Project: MAX Automation Organization: RAMAPATI AI Labs You must repair the existing project in place. Do not create a new project, replace working features with a demo, or report unverified functionality as complete. A. FIX THE GOOGLE SIGN-IN BRANDING The Google account chooser currently displays: "refined-courier-v5wls.firebaseapp.com" I want the user-facing authentication experience to identify my application as MAX Automation by RAMAPATI AI Labs wherever Google and Firebase support custom branding. Inspect the actual Firebase configuration and authentication flow. 1. Inspect "firebase-applet-config.json", "src/services/firebase.ts", Firebase Authentication settings, Google OAuth configuration and the authentication redirect flow. 2. Configure the supported Google OAuth consent-screen branding so the application name is MAX Automation, with the correct application logo and support details where available. 3. Verify the Google Auth Platform branding and authorized-domain configuration. 4. Investigate whether Firebase's default "firebaseapp.com" authentication domain can be replaced with a custom authentication domain. 5. If a custom domain is required, explain the exact Firebase settings, domain ownership and DNS configuration required. Do not invent a domain or pretend DNS has been configured. 6. Update the application's Firebase "authDomain" only after the custom domain is correctly configured and supported. 7. Ensure all required redirect URLs and authorized domains are valid. 8. Preserve the existing working Google Sign-In flow. 9. Do not remove or disable authentication merely to hide the Firebase domain. 10. Do not claim the domain has been replaced unless the actual Google account chooser has been tested and shows the expected branding. The goal is for users to recognize MAX Automation, not an unfamiliar project identifier. If a particular Google screen cannot display a custom name or logo under the current configuration, explain that limitation accurately and implement every supported branding improvement. B. AUDIT THE ENTIRE EXISTING CODEBASE Inspect every source file and connected feature, not just the authentication files. Verify the real implementation of: - Google Sign-In. - Email/password registration and login. - Email verification and password recovery. - User profiles and account settings. - Dashboard and navigation. - Cloud Firestore persistence. - AI assistant and Gemini integration. - Workflow creation and execution. - Workflow templates. - Integrations and external services. - Notifications. - Security and access control. - Subscription management. - Razorpay and PayPal. - Web and Android compatibility. Do not assume that a feature works because a button, component, endpoint or test name exists. Trace every important user action from the interface through the backend to its real result. C. REPAIR THE DATABASE ARCHITECTURE The current "server/firebaseAdmin.ts" uses Firebase client SDK modules rather than the official Firebase Admin SDK, despite its name and comments. Inspect and correct this implementation. The current "server/db.ts" also contains JavaScript Maps and local JSON disk persistence. Firestore helper functions catch errors and can conceal failed writes. Requirements: 1. Use a supported, properly configured server-side Firebase Admin SDK for privileged server-side Firestore operations. 2. Verify Firebase ID tokens securely on the backend. 3. Enforce user and workspace authorization in the backend. 4. Never assume Firestore Security Rules protect Admin SDK operations. 5. Remove local Maps and JSON files as the production source of truth for persistent customer data. 6. Use Firestore consistently for the supported production data model, or document a justified alternative before implementing it. 7. Make database writes fail visibly when required persistence fails. 8. Verify real reads, creates, updates and deletes. 9. Confirm data remains available after reloads, server restarts and login from another device. 10. Do not use fabricated connection checks as proof of database availability. D. MAKE EVERY FEATURE ACTUALLY WORK For every existing feature: 1. Identify the expected user behavior. 2. Inspect the complete frontend-to-backend implementation. 3. Repair missing handlers, incorrect endpoints, incomplete data persistence and broken error handling. 4. Connect the feature to its real provider or service when required. 5. Implement loading, success and failure states. 6. Verify authorization and data ownership. 7. Add meaningful tests. 8. Report the exact result. No dead buttons, fabricated results, simulated integrations or fake success messages. For real web searches, use an actual configured search provider or documented web-search integration. Do not pretend that Gemini alone guarantees live internet search. For external integrations, execute real operations only when valid credentials, permissions and provider configuration are available. For automation, implement actual triggers, execution handlers, failure handling and execution history. Do not mark an action successful unless it actually succeeded. For AI, use the real configured provider, protect API keys on the server, and show honest errors when the provider is unavailable. For payments, verify actual provider transactions, ownership, amount, currency and order status before granting paid entitlements. Never activate a subscription merely because the browser reports success. E. HANDLE SECRETS SAFELY Use the supported secret manager for private credentials. Never write private secrets into source files, frontend bundles, logs, reports or committed configuration files. Never ask the user to paste passwords, private API keys, payment secrets or service-account private keys into the conversation or a source-code prompt. Use clear configuration instructions and report only whether a required variable is configured, not its secret value. If a credential has been exposed, explain how to revoke and replace it. F. MANDATORY TESTING Run real tests for: - Google authentication and visible branding. - Successful login and dashboard navigation. - Session restoration and logout. - Invalid-token rejection. - Database persistence. - User and workspace isolation. - AI provider success and failure. - Workflow execution and execution errors. - External integration failure handling. - Payment signature and transaction verification. - Mobile-browser behavior. - Production build and available type checks. Use appropriate test environments and Firebase emulators where supported. Do not charge real money during tests. Do not label a test PASS unless it was actually executed and passed. G. REQUIRED FINAL REPORT Provide: 1. Exact files changed. 2. Google branding configuration completed. 3. Whether the default Firebase domain remains visible. 4. Whether custom authentication-domain configuration is still required. 5. Database changes and persistence test results. 6. Each feature's real implementation status. 7. Exact tests executed and their results. 8. Missing credentials, permissions or account-owner actions. 9. Security issues that remain. 10. Whether the application is ready for private testing, public deployment, or neither. Use PASS, FAIL, BLOCKED or NOT IMPLEMENTED. A successful build alone does not prove that the application works. Do not claim that every feature is complete when any critical path remains unverified. Start by auditing the current project, fix the branding and architectural defects, implement the required changes, and verify the real application behavior before reporting completion.