Mobile — Individual

Verify the Favorites system (POST /favorites/:propertyId toggle, GET /favorites, GET /favorites/ids, GET /favorites/check/:propertyId, useFavoritesStore) behaves correctly end to end, so that a saved property reliably shows as saved everywhere in the app and survives logout/login.

Home-feed favoriting is broken across THREE surfaces, each in a slightly different way — track them as distinct findings, not one vague 'favorites are broken' ticket. On the عقارات (Properties) tab, PropertyCard.tsx's and PropertyListItem.tsx's heart buttons both call onPress={onFavorite} — but apps/mobile/src/features/individual/components/home/sections/HomeProperties.tsx never passes an onFavorite prop to either component, in Card view or List view. The same file's <PropertyDetailsSheet> instance — the 'عرض تفاصيل' bottom sheet opened from any of those cards — has the identical gap: PropertyDetailsSheet.tsx accepts onFavorite/onShare props and wires its own heart/share buttons to them correctly, but HomeProperties.tsx only ever passes property, onClose, and onViewProperty when rendering it. Three tap targets, one missing prop, zero functionality, and none of them show any disabled state to hint that. On the مكاتب عقارية (Offices) tab, HomeOffices.tsx DOES wire onToggleFavorite — but only into a local `favoriteOverrides` useState dictionary with no API call behind it, so the heart visually fills in and then silently reverts the moment the screen unmounts. That Offices variant is the most dangerous of the three because it's the only one that will pass a five-second smoke test.

Verify HomeScreen's tab/filter state machine (activeTab: 'properties'|'offices', activePropFilter: 'all'|'sale'|'rent'|'exchange', viewMode: 'card'|'list') correctly re-triggers HomeProperties' fetch effect on every filter change and never leaks stale data from the previous filter into the newly-rendered list — this is exactly the class of state-transition bug that sails through a slow, deliberate manual pass and only shows up under real usage patterns like a user impatiently tapping between tabs.

Flag that PropertyListItem.tsx declares `propertyIncome = 150_000` as a destructured default parameter — meaning any listing where the API's item.propertyIncome comes back undefined renders 'مدخول العقار 150,000 د.ك' in the exact same confident green styling as a genuine figure, with zero visual distinction between 'this property really yields 150,000' and 'we have no income data for this property at all.' On a financial field specifically, a senior QA pass can't stop at 'a number displays' — the number's provenance is the actual thing under test, and right now the UI has no way to tell a real value from a fabricated placeholder that happens to look completely plausible. Worth noting for the fix: PropertyDetailsSheet.tsx renders the identical field correctly — its `property.propertyIncome !== undefined && property.propertyIncome !== null` guard has no default-parameter fallback poisoning it, so the details sheet is the reference implementation to copy, not a second place that needs the same fix.

Flag that PropertyDetailsSheet.tsx's formattedPrice logic renders the exact same markup — `{property.price.toLocaleString()} د.ك` — regardless of property.type, with no branch for 'RENT' at all, even though the Figma frame for a rental listing explicitly appends '/ شهرياً' (per month) after the price. This isn't a cosmetic omission: showing '150,000 د.ك' with no qualifier on a RENT-type listing is actively misleading — a real user has to infer from context (or the category label alone) whether that figure is a lump sum or a monthly recurring cost, and 150,000 KD/month is an absurd number that could easily be misread as a data-entry error rather than correctly understood as '150,000 KD total, paid monthly' being wrong on either reading. A senior QA pass treats price-unit ambiguity on a financial figure as a functional bug, not a copy nit.

Flag this as the sharpest finding in this whole batch, and it just got sharper: PropertyDetailsDto (apps/mobile/src/types/property.ts) already declares `requestYear?: number` and `requiredYear?: number` — almost certainly the backing fields for the design's 'طلب 2021' / 'مع 2023' rows on Exchange listings — but neither PropertyDetailsSheet.tsx nor PropertyCard.tsx ever reads or renders property.requestYear or property.requiredYear anywhere in their JSX. The Exchange Home-feed frame shows طلب/مع rendered directly on the card itself, in place of beds/baths — but PropertyCard.tsx's specs row only ever renders 'شقة {type} • {area} م²', beds, and baths, with no branch for type === 'EXCHANGE' at all. So this isn't a details-sheet-only gap anymore — it's the same two DTO fields missing from BOTH places a user would ever see them, meaning an Exchange listing's one defining trait is currently invisible everywhere in the app except the raw database.

Flag three concrete, code-verifiable mismatches between PropertyCard.tsx (the Home feed's Card view) and its Figma frame, none of which require guessing — they're each a direct line-by-line contradiction: (1) the 'مميز' badge is styled `absolute right-3 top-3` in code but appears on the LEFT edge of the image in the design; the heart icon is styled `absolute left-3 top-3` in code but appears on the RIGHT, paired with a share icon, in the design — the two elements are positioned as exact mirror images of the design. (2) The code's heart-icon container comment literally reads '/* Absolute Top Left: Actions (Heart & Share) */' but only a single heart TouchableOpacity is actually implemented underneath it — there's no share button in Card view at all, despite the comment writer's evident intent and despite List view (PropertyListItem.tsx) having one. (3) PropertyCardProps has no propertyIncome field and the JSX never renders a 'مدخول العقار' row anywhere, even though every card in both Figma frames shows one directly under the specs row, and PropertyListItem.tsx (List view) already implements this exact row correctly — meaning there's a working reference implementation sitting one file away that Card view simply never adopted.

Verify the Individual Login screen (identifier + password, 'تذكري' remember-me checkbox, 'هل نسيت كلمة المرور؟' link, 'المتابعة بحساب محفوظ' saved-account entry point) behaves correctly end to end, while flagging that the rememberMe value captured in IndividualLoginForm is passed to onLogin but never actually used — session persistence/token lifetime doesn't currently change based on it.

Verify the Individual Signup screen's single 'رقم الهاتف أو البريد الالكتروني' identifier field (previously two separate email + optional-phone fields, now merged to match both the Figma frame and the Login screen's existing identifier field) against signupSchema (identifier required, matching either the email regex or the Kuwaiti phone regex ^(?:+?965)?[569]\d{7}$, password 8-char min, confirmPassword must match), and confirm the backend's RegisterIndividualDto/registerIndividual now accepts the same single `identifier` field and classifies it server-side via the shared isEmail/isPhone helpers — so this closes out the design/code drift the previous version of this story flagged (design showed one required field; code had two, one optional).

Verify that IndividualAuthScreen's onSignup only advances to the OTP step (IndividualSignupOtpStep) when the identifier entered is phone-shaped (checked client-side via isPhoneIdentifier, mirroring the backend's own isEmail/isPhone classification of the same value) — if the identifier is email-shaped, the app immediately calls POST /auth/login with the new credentials and shows the success sheet with zero verification of any kind. Also confirm the previously-fixed 'no Identity row after registration' bug stays fixed here specifically: this immediate post-signup POST /auth/login (and the phone path's POST /auth/register/verify-otp, which also internally logs the user in) must succeed on the very first attempt, since registerIndividual now creates the User + IndividualProfile + Identity together in one transaction.

Verify the new SocialAuthButtons component (the 'أو قم بالتسجيل باستخدام' divider + Google icon button + Apple's native AppleAuthenticationButton, rendered on both IndividualLoginForm and IndividualSignupForm) correctly drives POST /auth/google and POST /auth/apple, and — critically for this environment — confirm whether GOOGLE_CLIENT_ID/APPLE_CLIENT_ID are actually configured on the target API environment before treating any failure here as a bug: both services are designed to fail closed with a clear 'غير مُفعّل حالياً' (not currently enabled) error rather than silently succeeding when unconfigured, and the buttons themselves are native modules that do not work inside Expo Go — they require a build produced by `eas build`/`expo prebuild` with the Google/Apple config plugins applied.

Verify the OTP screen's 6-box input and 45-second resend countdown (ForgotPasswordStep2, and the equivalent IndividualSignupOtpStep) match the Figma frame exactly and handle the boundary correctly, so that a user is never stuck unable to resend and never able to spam resends before the timer expires.

Flag that the Figma design for step 1 of Forgot Password shows an inline error message under the field ('لم نتمكن من العثور على حساب مرتبط بهذه البيانات') for an unrecognized identifier, but ForgotPasswordStep1.tsx has no inline error rendering at all — the actual implementation only surfaces failures via a native Alert.alert('خطأ', ...) popup — so this is a real design/implementation mismatch worth a product decision, not just a QA pass/fail.

Flag that the Figma frame for the final 'إنشاء كلمة مرور جديدة' (create new password) step shows a 'تخطي' (skip) link in the top-right corner, but ForgotPasswordStep3.tsx has no skip affordance at all — the user must set a new password to proceed, there's no way to abandon the reset and keep the old password from this screen — so this is a design/implementation mismatch that should be resolved deliberately rather than left ambiguous.

Flag a small copy drift: the Figma frame for 'تم إنشاء حسابك بنجاح' (account created) shows a button labeled 'ابدأ الاستكشاف' (start exploring), while the actual SuccessBottomSheet rendered in individual-auth.tsx uses buttonText='ابدأ الآن' (start now) — a minor but real inconsistency worth a one-line fix. Confirm the password-reset success screen ('تم تحديث كلمة المرور بنجاح' / 'تسجيل الدخول') matches its Figma frame exactly.

Verify ProfileBottomSheet (opened via 'المتابعة بحساب محفوظ' on login, or the profile icon elsewhere) correctly lists all of a user's identities with type badges and lets them switch or add a new one, matching the Figma 'اختر الملف الشخصي' frame functionally, while noting the add-account button reads 'إضافة هوية جديدة' (add new identity) in code versus 'اضافة حساب جديد' (add new account) in the design — a wording nit, not a functional gap.