🧑‍💼 WHO: Ayush Bisen ⚙️ WHAT: Fix screen layout/scroll issues after closing modals on iOS. Preserve the correct scroll position and content visibility. Ensure the screen remains fully accessible after modal dismissal. 🚨 WHY: To prevent screen shifting and ensure a smooth iOS experience.

🧑‍💼 WHO: Ayush Bisen ⚙️ WHAT: Add country-based phone number validation in the Mobile App. Validate numbers based on the selected country. Show proper errors and prevent invalid submissions. Keep validation consistent with the Web App. 🚨 WHY: To prevent invalid phone numbers while adding contacts.

🧑‍💼 WHO: Ayush Bisen ⚙️ WHAT: Implement a built-in Camera in the Mobile App. Support photo capture and video recording with essential camera controls. Attach captured media directly to the chat. Handle camera/microphone permissions and light/dark modes. 🚨 WHY: To provide a faster and seamless media-sharing experience within chats.

🧑‍💼 WHO: Ayush Bisen ⚙️ WHAT: Optimize FlashList performance in the Inbox Screen. Set proper estimatedItemSize and improve item layout handling. Prevent unnecessary layout recalculations during scrolling. 🚨 WHY: To improve scrolling performance and ensure accurate scroll behavior.

🧑‍💼 WHO: Ayush Bisen ⚙️ WHAT: Fix the ExpoSystemUI.setBackgroundColorAsync rejection error. Add proper app lifecycle and activity-state checks. Prevent native UI calls when the app is inactive. 🚨 WHY: To prevent runtime errors and improve Mobile App stability.

🧑‍💼 WHO: Ayush Bisen ⚙️ WHAT: Remove the push notification Player ID before team member logout. Re-register the Player ID with the owner account after logout. Ensure logout continues even if notification cleanup fails. 🚨 WHY: To prevent incorrect notifications after switching accounts.

🧑‍💼 WHO: PO ⚙️ WHAT: Currently, the WhatsApp interactive form is not handled in the mobile app. This feature needs to be integrated to allow users to interact with forms through WhatsApp within the mobile application. 🚨 WHY: Implementing this feature will enhance user engagement and streamline communication through the mobile app.

🧑‍💼 WHO: POC ⚙️ WHAT: Implement backend API support for filtering broadcasts by broadcast type, message type, and other criteria to enable the frontend to display filtered broadcast lists based on user-selected filter options. 🚨 WHY: Currently, the broadcast listing API does not support filtering by broadcast type (scheduled, sent, draft) or message type (text, image, video, template, carousel, etc.), forcing users to manually search through all broadcasts to find specific ones. This creates poor user experience when managing large numbers of broadcasts, makes it difficult to analyze specific broadcast categories, and wastes time scrolling through irrelevant results. Adding backend filter support will allow the frontend to implement filter UI that enables users to quickly find broadcasts by type, status, message format, or other criteria, significantly improving broadcast management efficiency and user productivity.

🧑‍💼 WHO: POC ⚙️ WHAT: Expand the "Choose Content Type" menu in Flow Builder to include additional node options beyond the current nine types (Text Button, Media, List, Single Product Message, Multi Product Message, Single AI Message, Template, WhatsApp Pay, Date and Time) to provide users with more functionality and ease of use when building flows. 🚨 WHY: The current content type menu has limited options that may not cover all the messaging and automation capabilities users need when building WhatsApp flows, forcing users to work around limitations or use inappropriate node types for their use cases. Adding more node options such as delay nodes, condition nodes, variable assignment, webhook calls, API integrations, form messages, location requests, contact card sharing, or other WhatsApp-supported message types will provide users with more powerful flow building capabilities, reduce workarounds, enable more complex automation scenarios, and improve overall user experience and product competitiveness.

🧑‍💼 WHO:POC ⚙️ WHAT: Create a compound index on the contacts collection for { userId: 1, settingId: 1, createdAt: -1 } to optimize the faceted listing aggregation query that currently loads 204,738 documents and sorts them in-memory, taking 1,842ms. 🚨 WHY: The contact faceted listing query filters by userId and settingId using an existing index, but then must load all 204,738 matching contact documents into memory to sort by createdAt because the index does not include the sort field, causing massive memory consumption, slow query execution taking nearly 2 seconds just to return 10 results, and contributing significantly to the contact-related libuv pool blocking issues seen in profiling. Adding createdAt to the compound index allows MongoDB to return pre-sorted results directly from the index without loading all documents into memory, reducing query time from 1.8 seconds to milliseconds, eliminating memory pressure, and resolving a major contact performance bottleneck affecting list display and navigation