jira & branch revalidation

Risk: Root cause is sound and the fix is correct: Reanimated 4 + New Arch leaves a closed @gorhom bottom-sheet's animatedIndex at ~-0.99999996, so BottomSheetBackdrop's `animatedIndex <= disappearsOnIndex(-1)` check is false and a closed sheet keeps an invisible full-screen backdrop with pointerEvents=auto that swallows all taps. The branch fixes it (disappearsOnIndex -1 -> -0.5, enableTouchThrough=true in both duplicate bottomSheetDefaults copies) and removes the ineffective dev-only Object.freeze=noop override. Low risk: opacity interpolation keeps the backdrop transparent below -0.5 so no visual change. Branch was QA-verified on emulator by the author. CRITICAL REGRESSION: although the branch was merged to main via PR #1 (merge b230a37, 2026-06-17), two LATER commits by Mohammed Elhatmi reverted the fix in main's current tree -- 8f8f9ce (2026-06-18) reset disappearsOnIndex back to {-1} and dropped enableTouchThrough in features/common/bottom-sheet/bottomSheetDefaults.tsx (and the shared/ copy), and the Object.freeze dev override is back in app/_layout.tsx. So the QA blocker is currently UN-fixed on main despite the ticket being Done.

Risk: Regression on main: app/main/(tabs)/_layout.tsx currently has only tabBarStyle={{ backgroundColor: "white" }} (line 142) and no longer imports/uses useSafeAreaInsets. The correct fix from 768f553 (paddingTop:12, paddingBottom:insets.bottom, minHeight:60+insets.bottom) was clobbered by the dev main push. On Android 15 gesture-nav devices the tab bar can again be obscured by the system nav area — the exact P2 bug this ticket describes. Root SafeAreaProvider (app/_layout.tsx) and app/index.tsx top insets are intact, but the tab bar bottom-inset handling — the core deliverable — is missing. The QA Verified status is not backed by any QA pass comment; assignee Preji John was asked to verify on 06-18 but has not responded.

Risk: No code to merge: branch carries zero commits ahead of main and its file is byte-identical to main (the pre-TTL version with silentRefresh on visitCount). The TTL guard described in Vineet's "fixed-unverified" comment is not present on the branch ref. Substantively the change is contested: Mohammed (assignee's reviewer/dev) reverted it, arguing the 60s in-memory TTL is a deliberate divergence from iOS — iOS has no cache and refetches on every viewWillAppear, and main's existing silentRefresh-on-visitCount already avoids skeleton flashes while staying closer to iOS parity. Both parties agree the optimization is technically sound; the open question is purely whether to diverge from iOS, now pending Subin's call (cross-ref ANDROID-80). No QA verification; resolution is null; status In Review.

Risk: Change itself is correct and low risk: offersStore.tsx is a verified byte-for-byte re-export stub of @core/providers/StoreProvider, so re-pointing importers is behavior-preserving. The branch covers only the StoreProvider portion of the ticket, but the other two items (dead home Calendar/Deliverables/CalendarBottomSheet components and the unused proceedWithAcceptedInvitations endpoint) are already absent from main, so scope is effectively complete. The branch work is NOT yet in main: offersStore.tsx still exists on main and all 3 importers still reference the stub path. Risk is the merge conflict, not the logic.

Risk: Branch code itself is reasonable and low-risk in isolation, but it is now stale relative to main. Main re-architected both files with a different approach (splashState handshake, reactive auth subscription, Redirect-based navigation, AppState handling). The two designs diverge on the core question: branch removes the playToEnd gate; main intentionally keeps it (matching iOS). Mechanically applying the branch would regress main's newer coordination logic and the SurfaceView-bleed-through fix. The first-splash-load and immediate-form requirements raised by Vineet on 06-18 are not fully addressed by either side and remain open.

Risk: No code has been written — nothing to assess for correctness. The work is genuinely a human decision, not a mechanical fix: it requires deciding whether to adopt expo-updates/runtimeVersion/production channel for OTA hotfixes vs documenting resubmission-only, plus knowing which of the 6 near-identical EAS profiles (preview2/3/4 etc.) QA actually depends on before pruning. Blindly pruning profiles or editing eas.json risks breaking current team/QA builds. Adding an eas.json submit block also needs an Android service account and Play track config (external credentials/access). Ticket is correctly parked in To Do.

Risk: The branch's only change is deleting the 4 dependency lines from package.json (0 additions, 4 deletions, 1 commit d1b8a03). I confirmed git grep over origin/main source finds zero imports of any of the 4 packages, and git show origin/main:package.json shows NONE of the 4 are present — they were already deleted in main. So the change is correct in intent but no longer needed: main already accomplishes the ticket goal (and went further, also dropping picker, country-flag-icons, expo-haptics, navigation deps, etc.). No correctness risk; the work is simply superseded. async-storage was correctly retained per the description.

Risk: Branch change is technically sound and low-risk in isolation: it removes props FlashList v2 ignores at runtime and migrates the ref type (FlashList->FlashListRef) and overrideItemLayout to the v2 signature (layout.span vs layout.size). However it does NOT merge cleanly. Main's commit 162874e rewrote the OffersList FlashList block and surrounding component (removed profileData/displayedCount/totalCount props, perf monitoring, render handlers) so both sides edited overlapping lines -> real content conflict. Main also still carries estimatedItemSize={200} and a stale FlashList<any> ref type, so the v2 migration is genuinely incomplete on main; the fix is still needed. QA never ran (low-end Android scroll perf check requested in ticket was not performed; comment is fixed-unverified).

Risk: The branch's substantive fix is already implemented on main independently by the dev, so it does NOT merge cleanly. merge-tree reports CONFLICT on 6 files (features/profile/types/profile.ts, features/profile/index.ts, app/profile/niches.tsx, features/auth/utils/userVerification.ts, features/profile/hooks/useInfluencerTypes.ts, features/profile/utils/profileUtils.ts, shared/components/feedback/ErrorState.tsx). Verified main already has: features/profile/types/profile.ts as a re-export of the canonical types/profile.ts (consolidation done); code_id present in constants/Types.ts (line 443: code_id?: string|number|null); onSkip + canSkipInvitation on InviteFriendsBottomSheetProps. The only branch delta main lacks is the package.json "typecheck":"tsc --noEmit" script. The branch commit b96ec68 is not in main (cherry: +). The branch also does the @types/profile -> @/types/profile import rename which conflicts with main's @features/profile import style. Mohammed Elhatmi confirms "Already done". Low correctness risk in the code itself, but merging the branch as-is would conflict and largely re-do existing work.

Risk: Technically the change is minimal and clean: a single Git LFS pointer update for alist.mp4 (38.2MB to 3.1MB), no code/require() changes, file path unchanged, merges with no conflict. However the scope is incomplete - only the video half of the ticket was done; the 12MB PNG flag set was left untouched (deferred to a follow-up). More importantly, reviewer Mohammed Elhatmi rejected the fix on quality grounds (compression "guaranteed to lower the quality by a significant margin, not advised") and stated the PNG-over-SVG flag choice was intentional to match iOS. The crf-28 re-encode quality claim rests only on emulator screenshots from the auto-fix bot, with no human sign-off on visual fidelity.

Risk: Instrumentation itself is correct and low-risk: each change adds a non-throwing console.warn(e) inside existing empty catch bodies (authStore.logout x5, session.ts 401 nav+logout, storage.ts saveToken+clearAllAuthData, index.tsx auth-bootstrap), leaving runtime behaviour unchanged. But the branch is stale against main on app/index.tsx: dev commit 1909e6f ("Add/update app/index.tsx", Mohammed, Jun 18) rewrote index.tsx (-70/+35) and moved the auth-bootstrap/initializeAuth logic out of the file ("AnimatedSplashScreen owns initializeAuth()"). The catch the branch instruments at index.tsx:~109 no longer exists in main, so that hunk is both conflicting and obsolete; the highest-risk auth-bootstrap path is therefore NOT covered as-is. Ticket also lists request.ts in-scope; branch left it untouched (defensible but partial). No QA verification; assignee Unassigned, resolution unset, still In Review.

Risk: Code quality of the branch itself is reasonable: componentDidCatch wiring is correct, the root ErrorBoundary logs once per error via useEffect([error]) (no recursion/loop), ErrorLogsViewer is gated behind __DEV__ so logs are never exposed to end users, and the errorLogger truncation hardening (800-char fields, MAX_LOGS 20, fallback 5) sensibly addresses the SecureStore ~2KB concern. BUT it is functionally obsolete: main deleted shared/utils/errorLogger.ts and shared/components/profile/ProfileErrorBoundary.tsx entirely and stripped componentDidCatch from features/profile/components/ProfileErrorBoundary.tsx. Merging this branch would resurrect deleted modules (errorLogger, ErrorLogsViewer) and re-introduce imports of them in app/_layout.tsx, directly contradicting the dev's chosen delete-based resolution. The ticket explicitly allowed EITHER deleting errorLogger/ErrorLogsViewer OR repurposing logError; the dev picked delete, the branch picked repurpose. Verification was static-only (tsc 133->133, eslint clean); no QA sign-off.

Risk: Genuine P1 security gap: intercom.ts supports a userHash but intercomLoginIdentified is called with only {id,email}, never an HMAC. Without server-side Identity Verification, anyone knowing a user's id/email could impersonate them in Intercom and read support history — PII/brand-deal exposure. However, the fix is fundamentally backend-dependent: the backend must expose an HMAC-SHA256 userHash endpoint before any client wiring is meaningful. Shipping client-side changes alone without the backend endpoint would be useless and could lock users out of the messenger. No code exists yet.

Risk: No code work done; nothing to assess for correctness. The ticket itself describes real launch risk: tokenRefresh.ts couples JWT refresh to the /user/fcm_token notifications endpoint, generateTestFCMToken registers a fake 152-char token that silently breaks real push, shouldRefreshToken() always returns false so proactive refresh never runs, and a refresh 401 races clearToken(). These remain unaddressed. Fix is correctly blocked on a backend refresh contract (alist-portal); a frontend-only fix would break session renewal.

Risk: Code quality of the branch is good: the skipAuth design is correct (a 401 on a login endpoint means bad credentials, not an expired session, so bypassing logout teardown is right), call sites were audited, and tsc/eslint show zero delta. The functional risk is the divergence from main. Main now uses getTokenOrLogout() which only guards the missing/expired-token-BEFORE-the-request case; the branch's wrapper additionally centralizes 401-RESPONSE refresh+retry+auto-logout, which is the stronger fix the ticket actually asked for. Merging blindly would clobber one approach with the other. Note ticket scope is also only partially done either way: venue.ts, fcm.ts (incl. the ad-hoc clearToken() at fcm.ts:43 the ticket explicitly calls out), signup.ts, and the remaining offer.ts endpoints are untouched on the branch.

Risk: Zero code risk: the only change is a single new markdown documentation file (CLAUDE.md); no source, build, or config files touched. Content is accurate and matches the ticket: it confirms google-services.json is intentionally committed, explains the Firebase Web API key is a client-side identifier rather than a server secret, and lists the correct mitigations (Android app + SHA-256 restrictions, per-API allowlist, Firebase App Check). Minor scope note: ticket nominally pointed at google-services.json/app.json, but since it explicitly says "no code change" and is a launch-notes documentation task, recording it in CLAUDE.md is appropriate. The documented controls are recommendations to be actioned in Google Cloud Console before launch — they are not (and cannot be) verified from this repo.

Risk: Low risk. Change is a 3-line config-only addition (blockedPermissions array) correctly nested in expo.android of app.json; verified valid JSON and proper placement. blockedPermissions only takes effect in a compiled EAS build, so it cannot be confirmed by static repo inspection alone, but the syntax and permission name are correct. No functionality impact since the app uses no advertising SDKs. The remaining required step is non-code: the Play Console Data Safety form must be manually set to "No" for advertising-ID collection — that cannot be enforced by the branch.

Risk: Low risk, single-file app.json edit. Verified against origin/main: launchCameraAsync / requestCameraPermissionsAsync / useCameraPermissions all return zero hits, so CAMERA is genuinely unused. All image input is gallery-only via ImagePicker.launchImageLibraryAsync (history, profile, license, ImageUploadSlot, UploadBottomSheet). No MediaLibrary/file-write usage, so WRITE_EXTERNAL_STORAGE removal is safe; READ_EXTERNAL_STORAGE is superseded by READ_MEDIA_IMAGES on targetSdk 35 (deprecated on API 33+). READ_MEDIA_IMAGES correctly retained for gallery access. Diff matches the documented fix exactly. Only residual: requires EAS prebuild to regenerate AndroidManifest.xml and Data Safety form must be updated to match the trimmed set; neither is code-blocking.

Risk: Low risk. The change is confined to app.json: adds expo.ios.infoPlist with NSPhotoLibraryUsageDescription, NSCameraUsageDescription, and NSPhotoLibraryAddUsageDescription, plus an expo-image-picker plugin entry with matching photosPermission/cameraPermission. This directly satisfies the ticket (infoPlist was {} and the plugin was absent). The dual approach (infoPlist + plugin) is redundant but harmless and is the safest way to guarantee strings land in Info.plist on prebuild. It also adds ios.bundleIdentifier ae.alist.ios, which is slightly out of the ticket's stated scope but is correct/necessary for an iOS build and not risky. JSON is valid and no new TS errors were introduced. Not runtime-verified: requires an iOS prebuild to confirm injection into Info.plist, which was not possible in the auto-fix environment. No microphone string added, which is correct since no mic usage was found.

Risk: Not a code defect — this is a mandatory Play Store listing compliance task. Real risk is launch-blocking: if the Data Safety declaration, Content Rating, and Target Audience do not match the app's actual data collection (name/email/phone/WhatsApp/DOB/nationality/gender, profile/license/redemption photos, FCM token, Intercom chat, YouTube OAuth) and UGC+live-chat features, Google will reject the listing. Requires declaring encryption in transit, third-party sharing (Intercom/Google/Firebase), a deletion path, "yes" to UGC + in-app communication with a working report/moderation path, and an adult (non-child) audience band. P0 / S6 compliance item; must be done by a human with Console access before launch.

Risk: This is a store-policy/compliance task (S6, P0), not an Android code change. The work is to stand up a public https://alist.ae/delete-account page and confirm a canonical public privacy-policy URL, then enter both in Play Console > App content. Currently deletion is only reachable in-app behind login and the privacy policy is fetched at runtime and rendered behind the auth-gated Profile tab with errors swallowed — Play's Data Safety form cannot be completed, blocking the listing. The fix lives on web/backend + Play Console, not in alist-android, so no branch is expected here. Open question: web/backend ownership for both pages remains unresolved. Status is correctly To Do; no QA signal expected for a console/web task.

Risk: HIGH RISK / unresolved. On origin/main (6929044), deleteUserAccount() (profile.ts:149) still posts to /signup/social-media/profile/delete, identical to the social-profile path the ticket says is wrong. The function's own docstring claims it "schedules account for deletion (90 day recovery period)" while the URL only deletes the linked social profile — exactly the misrepresentation that makes this a Play User Data policy violation, not just a functional bug. Mohammed Elhatmi's comment "Api endpoint is correct" is unsupported and contradicts the code and the triage; if treated as a backend confirmation it would still need (a) proof the backend re-mapped that URL to full account+data deletion, and (b) a distinct response + end-to-end test that the same credentials no longer return profile data. None of that is evidenced. Open question (correct endpoint + retention window) remains open.

Risk: The ticket's core goal is already achieved in main: the dev independently removed both target debug blocks. Main's CustomModal no longer has the per-row "CountryCodeItem Debug" UAE block, and main's InviteFriendsBottomSheet no longer has the "INVITATIONS DEBUG" block. The branch (commit fccdcf2) does the same removals, so its primary value is already delivered. Two divergences remain: (1) Main still contains console.log("Scroll error:", error) at CustomModal line 323 — the branch converts this to a silent catch, so that one cleanup is NOT yet in main. (2) In InviteFriendsBottomSheet, main's refactor went further than the branch and dropped the setInvitedUsers(initialInvitedUsers) sync call inside the useEffect, leaving the effect computing newUsersJson/currentUsersJson but doing nothing with them (dead code, and a possible behavior change since state no longer re-syncs on prop change). That is a pre-existing concern in main, not introduced by this branch. Low overall risk for the launch — the production log spam is gone.

Risk: No code change exists; this is an open investigation ticket, not a deliverable fix. It is blocked on external input — iOS reference screenshots for SL46 (Notifications list) and SL79 (License upload) — which are unavailable in the alist-android repo. The description notes the highest-risk divergence points (native Alert.alert styling, country-code picker using iOS-only presentationStyle='overFullScreen' ignored on Android: CustomModal.tsx:361-366, Modal.tsx:143-148), but nothing has been verified live (visual). Not actionable without a human providing the design/iOS reference.

Risk: NOT REPRODUCED — closed without code change. No fix branch exists. Live Jira: status Done, resolution Done, assignee Unassigned (matches board snapshot). The reported '@'-prefix bug could not be reproduced: code inspection and live emulator QA both confirm no code path prepends '@' to the handle. I spot-checked origin/main app/main/(tabs)/profile.tsx:38-39 — generateUsername returns profileData.instagram_url?.trim() verbatim with no '@' injection, consistent with the ticket's analysis. Display and save paths only apply .trim(). Risk of merging nothing is effectively zero; the desired behaviour already holds in main. Minor residual: there is still no defensive strip of a user-typed leading '@' on save, so if a user manually enters "@handle" it would be stored as-is — but that was out of scope and not the reported defect.

Risk: Correct and minimal fix that matches the ticket recipe exactly. Replaces the asymmetric Animated.spring (tension:60, friction:12) open — the overshoot/bounce that caused the reported "jumping" — with Animated.timing(toValue:0, duration:280, Easing.out(Easing.cubic), useNativeDriver:true), now symmetric with animateOut()'s 280ms timing slide. Easing is properly added to the react-native import. useNativeDriver preserved. Scope is one file, 4/-3 lines, no API or state changes. Low risk. Only caveat: runtime animation smoothness is not statically verifiable and has no human/QA video verification yet, as the ticket itself flags.

Risk: The branch (single commit 829707d) patches the OLD permission-gated picker code, adding a canAskAgain check + "Open Settings" Alert across 5 files. But origin/main has independently refactored ALL of these pickers to NO LONGER call requestMediaLibraryPermissionsAsync() at all — every picker now invokes launchImageLibraryAsync() directly (license.tsx pickFromLibrary, offers/home ImageUploadSlot, profile.tsx openImageLibrary, UploadBottomSheet x4). The branch's core premise (explicit permission request that dead-ends on denial) no longer matches main, so the fix is largely superseded. The change itself is logically correct against the old code and low-risk in isolation (UX-only, static-checked), but it has NOT been runtime-verified and no QA sign-off exists. offers/ImageUploadSlot.tsx on main already imports Linking, hinting the dev addressed settings deep-linking differently.

Risk: ConfirmModal.tsx is a clean new file and the implementation is sound: 250ms Animated.timing translateY (slide up on open, down on close) meeting the SL35/43/65/66/80 requirement, FIFO concurrent-call queue, non-cancelable parity (backdrop pointerEvents none, no-op onRequestClose), and a native Alert.alert fallback when the host is not yet mounted. Imperative confirm() returns Promise<boolean>. Per the author's note, tsc shows zero error delta and eslint is clean on the 4 touched files. Main correctness risk: runtime slide-up/slide-down animation was never visually verified (no QA pass), and only 5 of ~63 Alert.alert sites were migrated (intentionally bounded scope), so the broader popup-animation defect persists app-wide. No QA verification comment exists.

Risk: Change is functionally correct and low-risk in isolation: error booleans set in both catch handlers, reset on item identity change (same effect as the null reset), hasFetchError gates the expandable render per displayTab, and a Toast informs the user. The branch already contains main's shouldFetchNow/fetchKey/refreshVersion fetch-gating, so the fix is layered on the right structure. Minor: error flags are only reset on item.id/reviewStatus change and at fetch start, not on collapse/retry, so the inline "tap to collapse and try again" message is the recovery path — acceptable. New react-native-toast-message import assumed already a project dep. No type/lint regressions reported.

Risk: Low risk. The diff is a precise match for the ticket's prescribed fix and touches only CommentInput.tsx styling/props. Correctness is sound: minHeight allows growth, maxHeight+scrollEnabled prevents unbounded expansion while keeping overflow scrollable, and the unconditional lineHeight fixes the Android-specific tight line wrapping. No logic changes. Only outstanding gap: never visually verified on a release build because UploadBottomSheet crashes on mount in the dev build (separate 'property is not configurable' bug), so the actual on-device scroll/clipping behaviour is unconfirmed.

Risk: Functionally low-risk where applied: getOfferStatus in historyUtils.ts was migrated to named ReviewStatus constants with the exact same numeric mapping (behavior-preserving). The new enum itself is sound and correctly documents 0=approved,1=not_uploaded,2=overdue,3=under_review,4=rejected,5=skip_required,6=exempted, and the misleading Types.ts comment (which wrongly said 2=approved) is fixed. BUT the change does not meet its own acceptance criteria: the ticket requires refactoring getStatusConfig, ReviewStatusRedemption, RequestItem.tsx, and UploadBottomSheet.tsx to use the enum. In reality only historyUtils.ts imports it. UploadBottomSheet.tsx still has 10+ magic-number comparisons (reviewStatus===0/4/6, etc.) with only a comment changed; RequestItem.tsx is entirely untouched; getStatusConfig/ReviewStatusRedemption not migrated. The exported RedemptionStatus union and ReviewStatusValue type are defined but never used. Also all doc comments (ReviewStatus.ts header, Types.ts, UploadBottomSheet) point to a non-existent path "types/reviewStatus.ts" — the actual file is constants/ReviewStatus.ts, which is misleading for the next dev. Net: the cross-file disagreement the ticket targets is only ~25% resolved.

Risk: The new reviewStatus===4 guard correctly closes the reported hole (text-only resubmission when all slot statuses default to 0 after URL-regex match failure) and reuses the existing perUploadStatusOverride session-freshness signal already used by the per-slot guard directly above it. All referenced symbols (storySlotCount, hasReviewScreenshot, reviewStatus, setSwiperIndex, perUploadStatusOverride) exist in scope; code is internally consistent. Two gaps vs. ticket spec: (1) freshStoryUploaded uses .some(Boolean) so it requires only AT LEAST ONE fresh story upload, not EVERY required slot as the ticket demands — a multi-slot rejected review can still resubmit after replacing just one image; (2) no server-side backstop and no Submit-button gating, both explicitly requested. Low runtime risk (additive guard, no behavior change for non-rejected reviews) but partial correctness. QA never verified live (data + release-build blocked).

Risk: Fix is well-implemented and matches the ticket intent: a single deriveOfferStatus() (shared/utils/offerStatus.ts) is consumed by both History list transforms (transformRedeemedOffers/transformPendingOffers in historyUtils.ts) and the offer detail screen (offer.tsx), so list and detail can no longer derive status independently. Rejection flags (review_rejected_status===1 || insta_stories_rejected_status===1) now map to "rejected" - addressing the core defect where unmapped review_status (incl. 1) silently defaulted to "pending". Unknown status_title/review_status values are logged via console.warn instead of silently defaulting. Logic and precedence ordering are sound. Main remaining risk: NOT verified at runtime - no rejected request/review existed in dev data, so the actual list-vs-detail reconciliation was never observed live; QA verification is still outstanding. A residual backend gap (full rejection not reflected in redeemedOffers) is correctly identified as out of client scope.

Risk: Low risk. Change is purely defensive: it attaches rejection handlers and adds logging, no behavioral/control-flow change to the happy path. The catch blocks still treat permission/token errors as non-fatal (return false / no-op) which matches existing intent, just no longer swallowing silently. One gap vs. ticket intent: it uses console.warn instead of Sentry.captureException (Sentry not installed), so launch-day FCM/push-registration failures surface only in device/Metro logs, not in a remote error monitor — failures are no longer unhandled but remain harder to observe in production. Acceptable for merge; remote reporting is a follow-up once Sentry exists.

Risk: The change is correct and directly addresses the ticket: channel is created unconditionally on Android at app start (before permission/token), so backgrounded/killed FCM messages have a channel. setNotificationChannelAsync is idempotent, so the double-call from registerForPushNotificationsAsync and initializeNotifications is safe. lightColor corrected to brand teal #00A4B6. Only verification gap: no runtime/FCM background-delivery test was performed (author noted this). Low correctness risk; main concern is the merge conflict, not the code itself.

Risk: Change is config-only (app.json) plus one new LFS image asset; low blast radius and the diff matches the ticket's prescribed fix (icon swap + #00A4B6 tint). Correctness of the config is high. Two open risks: (1) the entire fix is unverified at runtime - it requires expo prebuild --clean + an actual FCM push to confirm the status-bar icon renders as a proper tinted silhouette rather than a white box; no live test or QA sign-off exists. (2) The dev reused the tightly-cropped notification silhouette as adaptiveIcon.monochromeImage; that glyph may fall outside the adaptive-icon safe zone on Android 13+ themed launchers and ideally wants a separately padded monochrome asset. Neither is a blocker for merge but both should be eyeballed post-build.

Risk: The fix itself is correct and well-reasoned. Single commit 2fcbab9 touches 4 files (+94/-46). Logic: (1) RequestItem.tsx dedupes invitedusers[] by user id, preferring the record with a real name, before mapping to Invitation[] — sound, fixes SL53/SL56 avatar collapse and icon mismapping; (2) history.tsx dedupes invitations[] before formatting for the sheet; (3) InviteFriendsBottomSheet.tsx adds a dedupeInvitedUsers helper applied to initial state + a content-signature-keyed sync effect that no longer compares against local state (so it can't clobber in-flight edits) and drops debug logs; (4) Types.ts adds documentation comments confirming the id namespace and status enum. No new runtime risk; static checks pass per the dev comment. The open question is resolved correctly. Caveat: never runtime-verified (DEV-build bottom-sheet deepFreeze crash + needs a 2+ invite offer), and QA has not signed off — needs a release-build verification before it can be called done.

Risk: Low risk and correct. refreshInvitedUsers mirrors the existing, proven handleShowInvitedUsers mapping exactly (same fetchOffer call, same status 0/1/2->pending/accepted/declined mapping, same setPendingInviteDetails + setCurrentInvitedUsers), so it directly fixes the stale-list root cause described in the ticket. Refetch failures are swallowed with a comment (acceptable — next sheet open refetches). All referenced symbols (fetchOffer, OfferDetailsApiResponse, setCurrentInvitedUsers, setPendingInviteDetails, currentCodeId) are in scope; Toast is imported in the sheet. Toast wording is sensibly differentiated (Invitation sent vs Companion added/removed) by mode. Minor: the inline ternary carries a redundant "as" cast and refetch adds a network round-trip per mutation, but neither is a defect. Caveat from dev comment: not runtime-verified — Invite-Friends sheet crashes on dev build (deepFreeze, gated by ANDROID-9), so behavior was only statically validated (tsc/eslint clean, no new errors).

Risk: Premise of the bug appears to be wrong: per the backend-source analysis, the client already sends the companion USER id where the add/remove endpoints expect it, and uses the invitation RECORD id only for accept/reject — so there is likely nothing to fix in the Android client. If the user-reported symptoms (SL48/SL51/SL78: re-invite/remove silently no-ops, no push) are real, the root cause is most plausibly server-side (push queue delivery, or add/remove returning business-rule status:false). Runtime verification was never completed: the DEV build cannot mount InviteFriendsBottomSheet due to a @gorhom/bottom-sheet "property is not configurable" crash (tracked separately, ANDROID-9), so the flow was never observed live. The "Already fixed" comment is unsubstantiated — no branch, no commit, no QA pass backs it. Low residual risk for the Android launch since there is no code change to ship; main risk is mis-triage if the real (backend) issue is closed as fixed without a release-build re-test.

Risk: Correct and low-risk. Multiple layers of defense against double-tap: synchronous lock acquisition before the async block+accept, functional gate (no-op handler + early return in handleDeliverablesButtonPress), and visual/functional disable on the button. Lock-release coverage is thorough across success/error branches and the pan-dismiss path, addressing the stuck-lock concern the ticket flagged. Minor theoretical risk: the onChange(index===-1) release could race if the sheet momentarily reports -1 during the confirm transition, but handleDeliverablesConfirm manages its own lock state on confirm, so impact is negligible. No new TS/ESLint issues. Not exercised on a throttled connection (ticket asked for that); QA still pending.

Risk: The branch change itself is correct and low-risk in isolation (proper error surfacing, processing-flag reset, 401 suppression kept). But it does not apply to current main: the offer.tsx hunks target a handleDedicatedOfferApply function that has been refactored away, and the DeliverablesBottomSheetContent fix is already present in main (Toast.show with 401 guard; main uses text1 only vs branch's text1+text2). Merging as-is is impossible (conflicts) and unnecessary — the underlying bugs appear already resolved in main by the dev's refactor. No QA verification; assignee Unassigned; resolution unset.

Risk: Low risk. Inline Text renders inside the sheet container so it has no z-index dependency — a robust fix for the portal-occlusion bug. Text is already imported; state lifecycle is correct (set on guard, cleared on date select and confirm); button marginTop adapts 40->12 to preserve layout. Only nit: copy differs slightly from spec ("Please select an offer date" vs. original "Please select offer date") — cosmetic, not a defect. Runtime/device verification not done (gated by ANDROID-9 dev build); tsc shows no new errors, eslint clean.

Risk: The branch is STALE relative to main. git merge-tree reports a real CONFLICT in app/main/offer.tsx. The branch patches the OLD showDummyOfferAlert — a simple two-line ternary (isInstagram ? instagram_url : tiktok) — but main has since rewritten showDummyOfferAlert into an "iOS pattern" function that fetches a fresh profile and branches across 4 states (declined/missing/notApproved/pendingVerification) per platform, with only an isInstagram check and a tiktok else-branch. main's showDummyOfferAlert has NO youtube handling, so the original bug (YouTube offers falling into the tiktok `missing = !fresh.tiktok?.trim()` path, wrongly showing the Connect popup) STILL exists in main. The branch's core fix therefore targets code that no longer exists. The three helper changes (userVerification.ts isYouTubeConnected + youtube branch; offerFiltering.ts getVerificationRequirementMessage youtube branch; types/profile.ts youtube_verified) are absent from main and would apply, but they are secondary; offerFiltering's getVerificationRequirementMessage in main still has no youtube branch. The "Already fixed" dev comment is misleading: only handleVerificationCheck got a youtube branch in main, not the showDummyOfferAlert redemption gate cited as the root cause. Not QA-verified (live note: not reachable on test data); status In Review, Unassigned, unresolved.

Risk: Correctness of the change itself is good: each of the 5 call sites had an identical anti-pattern (fall back to literal id 54168 when no userId), and throwing on missing userId is the right behavior — it stops redemption actions being sent against someone else's account. Replacing the silent fallback with a thrown error is a behavior change callers (React Query/UI) must surface, but that is the intended fix per the ticket. No tests added; ticket is static-only and no QA verification recorded. Main still contains 4 of the 54168 occurrences (one site was restructured away in a628f8e), confirming the fix is genuinely not yet in main.

Risk: The fix is correct and well-targeted. getLicenseAlertShown/setLicenseAlertShown/clearLicenseAlertShown use SecureStore (mobile) / localStorage (web), matching the rest of the app's persistence; getLicenseAlertShown fails open (returns false -> shows alert) on read error, and home.tsx adds a .catch that also fails open, directly fixing the original bug where AsyncStorage.getItem could reject and silently suppress the alert. clearLicenseAlertShown is added to clearAllAuthData so the flag resets on logout, and the redundant AsyncStorage.removeItem was removed from authStore — state is now unified in one store. All three AsyncStorage references in home.tsx are replaced (none left); the second useEffect (niche alert) also uses the new helper consistently. Minor: setLicenseAlertShown swallows write errors silently, so a failed write could re-show the alert next launch, but that is fail-safe (annoying, not broken). Not runtime/QA verified on a fresh install — the comment explicitly skipped emulator verification, and the only Jira live-test note is a PARTIAL observation, so behavior on true first-launch state is unconfirmed.

Risk: The branch fix is well-formed in isolation (clears timeout in finally and via useEffect cleanup, correct loader styling), but it targets code that no longer exists in main. Main's commit 1909e6f removed isCheckingAuth and checkAuthStatus entirely, moving initializeAuth() ownership to AnimatedSplashScreen and using a reactive store subscription + splashDone gate. The blank-screen concern is now handled differently: index.tsx intentionally returns null while the splash overlay is still on screen (not actually blank). Applying this branch would reintroduce a duplicate/competing auth-check loop and a setTimeout against state that no longer drives the gate. High confidence: conflict and supersession both verified directly.

Risk: Change is correct and tightly scoped to the ticket. The root cause (credential wipe buried after FCM unregister and gated behind isLoggingOut bail checks, so a fast re-login or storage error could skip it) is fixed: clearAllAuthData() and the in-memory reset both run unconditionally at the top. Bail guards correctly remain only on best-effort side effects. useLogout awaits authLogout() before navigating, so the "navigate before wipe" race is closed. Storage errors are now logged rather than swallowed (ticket asked for Sentry; console.error is a partial fulfillment — acceptable but not ideal). Low risk: 2 files, no API/signature changes. Note ticket mentioned app/index.tsx fromLogout auth-skip and storage.ts but those were not touched — the unconditional disk wipe makes the fromLogout skip safe, so this is reasonable. Not runtime/QA verified (emulator regression skipped, no human verification on the ticket).

Risk: Low risk. Change is scoped to one component, additive styling plus UX feedback. Logic is correct: InteractionManager focus is properly cancelled on cleanup; disabled/focused styles are pure presentation. One external dependency to confirm at integration: it now calls Toast.show from react-native-toast-message, which requires a Toast root provider mounted in the app (if not present, the toast silently no-ops but does not crash). Cursor visibility under New Arch (a ticket open question) is unchanged by this diff and not verified here. No QA verification on Jira yet — comment explicitly flags runtime QA was not done in CI and needs manual device testing on the Profile OTP screen.

Risk: Low risk and correct. Import swapped to react-native-keyboard-controller's KeyboardAwareScrollView, the same component already used in signUp.tsx on main. Unsupported props (enableOnAndroid, enableAutomaticScroll, extraScrollHeight, resetScrollToCoords) correctly removed; OTP's extraScrollHeight={50} correctly remapped to bottomOffset={50}. The critical layout fix is sound: login.tsx keyboardScrollView height:600->flex:1 PLUS innerContainer flex:1 (a flex:1 child in an auto-height parent would collapse to 0 and itself cause a blank login, so the parent flex:1 is necessary and present). Legacy pure-JS dep removed from package.json (no native rebuild needed). No lingering legacy imports remain. Residual risk: profile/otp.tsx runtime path was not exercised on-device (only login+signUp verified), and the only verification claim is from the fix author rather than an independent QA signoff. Note the ticket's own live-test stated the bug was NOT reproduced on the dev build, suggesting it may be intermittent/build-dependent; the fix is still correct regardless.

Risk: Fix is correct and minimal. Branch is a pure git mv of app/auth/signUp.tsx -> app/auth/signup.tsx (diff shows similarity index 100%, 0 insertions/0 deletions). Verified on origin/main the file is still signUp.tsx (capital U) while _layout.tsx:213 (Stack.Screen name="auth/signup"), index.tsx:195 and login.tsx:392 (router.replace("/auth/signup")) all use lowercase. Expo Router is case-sensitive, so the rename makes the file match the references — exactly resolving the unreachable-route bug. Single-file rename, no logic change, very low risk. Note: the Jira "Done" status is stale/incorrect — the fix lives only on the branch, never merged (merge-base --is-ancestor confirms adcc3c8 is NOT in main), so the shipping code on main is still broken.

Risk: This is a real launch blocker but not a code task. An unverified OAuth app requesting the sensitive youtube.readonly scope shows an 'unverified app' warning and is capped at 100 users, which would block real launch usage. The gate lives in Google Cloud Console (consent screen publishing/verification, brand verification, scope justification), not in alist-android. The only repo-side decision is whether to keep or drop the scope at YouTubeConnectButton.tsx:43 — if YouTube connect is not required for v1, dropping the scope removes the verification dependency entirely. Note related ANDROID-51 (fix/android-51-youtube-redemption-gate) touches YouTube redemption logic; coordinate the connect/scope decision with that work.

Risk: P1 release-blocker that is genuinely unaddressed — no code exists. Risk is real: per the ticket, RootLayout has no top-level error boundary (only 3 feature-scoped ones) and no global ErrorUtils handler, so any uncaught render error white-screens the app with zero telemetry, compounded by pervasive silent catch blocks. Day-one production failures would be invisible. The Sentry DSN portion is blocked on an external account/console decision, but the root ErrorBoundary in _layout.tsx and ErrorUtils.setGlobalHandler + unhandledrejection listener are pure in-repo work that could ship independently of Sentry to at least prevent white-screens.

Risk: Low code risk: pure deletions of a dead config field (auto-fix audit confirms zero runtime call sites; corroborated — nothing in main references intercom.token either). The real residual risk is operational, not code: the leaked Intercom server Access Token is a read/write credential still present in git history. Removing it from working files (already done in main for eas.json) does NOT mitigate the breach — the token must be REVOKED/rotated in Intercom and history purged (BFG/filter-repo). This branch does neither and cannot. No QA verification on the ticket; assignee Unassigned.

Risk: The fix is correct and high-value: babel.config.js adds babel-plugin-transform-remove-console for env.production (exclude 'error'), the actual mechanism that strips ~97 console.* from release bundles — and this is NOT yet in main. The preset is resolved via expo's package.json path to survive a non-hoisted node_modules layout (sensible). formHandler.ts correctly deletes the signup DEV-OTP log and re-gates the login OTP toast on __DEV__ instead of the broken baseUrl.includes('dev-') heuristic (which was true in prod) — the key security correctness win. auth.ts/profile.ts/OfferVoucher manual log deletions are clean and apply without conflict. Requires npm install after pull (new devDependency). Note Mohammed's comment contends the logging is intentional for testing — but gating on __DEV__ preserves dev-time visibility while stripping release, so the fix accommodates that concern. No correctness defects found.

Risk: P1 release blocker that is genuinely a deployment/config concern, not a code bug a branch can resolve. The build.gradle release config points at the debug keystore, but EAS prebuild overrides signing with managed credentials, so the real risk is only if someone builds prod locally from the checked-out android/ folder (would ship a debug-signed, Play-rejected APK). Verification requires confirming a non-debug upload keystore exists in the EAS dashboard and that Play App Signing is enrolled — both outside the repo. No QA signal present. Correctly classified as needing human/console action.

Risk: Correct and complete for the stated goal. cli.appVersionSource="remote" delegates the versionCode counter to EAS, and autoIncrement=true on the production profile bumps it per build, eliminating Play Store duplicate-versionCode rejections. JSON is valid and there is no competing android.versionCode in app.json. Low risk. Minor unrelated note: production buildType is "apk"; Play Store prefers "aab", but that is out of scope for this versionCode ticket and not a defect introduced here. Ticket description also asked to add an owner to app.json; that was not done, but it is non-blocking for the versionCode fix.

Risk: Code is correct and low-risk in isolation: only the production.android.buildType:'apk' block is removed; preview/preview4 APK side-load profiles are unchanged, and EAS defaults production to app-bundle. Diff is +0/-3, valid JSON. The real risk is process/product, not code: the most recent comment (Mohammed Elhatmi) explicitly states the team must stay on APK during current testing, so merging now would break the team's test/distribution workflow. Separately (pre-existing, not introduced here), the production profile's EXPO_PUBLIC_API_BASE_URL points to dev-api.alist.ae — worth confirming before any production AAB is actually published, but out of scope for this diff.

Risk: Change is correctly scoped: only the production profile (eas.json line 80) is modified; all 5 dev/preview profiles remain on dev-api.alist.ae. Setting EXPO_PUBLIC_VENUE_IMAGE_BASE_URL is necessary because environment.ts falls back to dev-creator.alist.ae when unset. Mechanically clean and low-risk to the file. The real risk is value correctness, not code: the prod URLs (api.alist.ae/v1, creator.alist.ae/assets/uploads/venues/) were sourced from HTTP probes per the dev's own comment and were never confirmed with backend, and there is no QA/runtime verification of a prod build. Reviewer Mohammed Elhatmi's "Correct apis as we are still developing" further signals the prod values are not yet endorsed. No QA sign-off (qaSignal none). Cannot be marked ready until backend confirms the canonical prod hosts and a prod build verifies traffic.

Risk: Low-risk, correct, minimal fix. Single-file change: swaps the plain RN TextInput for @gorhom/bottom-sheet's BottomSheetTextInput in features/offers/components/CommentInput.tsx — the standard New-Arch/Fabric fix for inputs mounted inside a gorhom sheet. forwardRef type updated to React.ComponentRef<typeof BottomSheetTextInput>; all props are drop-in compatible. QA (Preji John, 06-16) explicitly confirmed the crash is resolved. IMPORTANT: that same QA comment reports a SEPARATE regression — after submitting a review the offer disappears from the History page. This branch touches no submit/history logic, so it neither causes nor fixes that regression; it remains open and should be tracked before the ticket is closed. The home/ duplicate Vineet flagged does not exist on main, so that heads-up is moot.

Risk: Status discrepancy: ticket sits in "QA Verified" (statusCategory In Progress, resolution=null) yet there is no fix branch and zero comments documenting the fix or QA pass. There is no code artifact to evidence the cancel-event fix, and no QA comment from Preji John or anyone confirming verification. The "QA Verified" label is therefore unsubstantiated by any traceable change. Cannot assess code correctness because no branch/diff exists to review.

Risk: Cannot assess code correctness: no fix branch exists in alist-android, so nothing to diff or review. The bug is a state-management/UI-refresh issue (stale list after a remove/cancel mutation) — typically a missing list invalidation or state emission after the cancel call. Status reads "QA Verified" but resolution is unset and there are zero comments on the ticket, so there is no evidence trail (no QA author, date, or pass/fail note) backing the verified status. Treat the QA-verified label as unsubstantiated until the corresponding code change is located.

Risk: Status discrepancy: the board shows "QA Verified" yet no fix branch exists and the ticket carries zero comments and no resolution. There is no traceable code change implementing or verifying the YouTube-connect error fix, and no QA evidence (no comment from Preji John or anyone confirming a pass). The "QA Verified" label is therefore unsubstantiated from a code/audit standpoint. Possible the fix landed directly on main via another ticket/commit, but that cannot be confirmed here since branch review was skipped per instructions.

Risk: Cannot assess code correctness: no fix branch exists, so the actual navigation fix (likely a post-redemption routing/tab-index change) cannot be inspected. The board/Jira status of "QA Verified" is unsupported by any comment trail (zero comments) and resolution is null, so the "verified" claim cannot be corroborated from Jira and qaSignal is "none." Status category is still "In Progress" (indeterminate), which is inconsistent with a fully verified/closed bug. Treat the QA Verified label with caution until a branch or commit implementing the fix is located.

Risk: Status mislabeling risk is high. Board says "QA Verified" yet the latest QA comment (Preji John, 2026-06-16) explicitly reports the thumbnail issue still reproduces, and resolution is null with no fix branch present. There is no code to merge and, more importantly, the underlying bug is apparently unresolved. Treating this as launch-ready would ship a known, QA-confirmed defect. Recommend reopening / kicking back to the developer (Mohammed Elhatmi) for an actual fix before launch.

Risk: Board and live Jira both show "QA Verified", but there is NO fix branch and NO commits associated with this ticket, and the Jira resolution field is still null with zero comments. There is no traceable code change implementing the fix, and no QA comment documenting what was verified or how. This is a verification gap: a permissions/photo-picker bug marked QA Verified with no linked code and no resolution recorded. Cannot confirm any actual fix landed; treat as unverified at the code level until a branch/commit or merged change is identified.

Risk: Not ready by any measure. No fix branch exists, so there is no code to review or merge. QA has actively rejected the attempted fix three times in a row (6/16-6/18), with the latest 6/18 comment confirming the UI still does not match iOS and an earlier 6/17 comment noting an error appearing in the Select Category flow. Status remains In Progress with no resolution. This is an open, regressing bug, not a launch-ready item.

Risk: Change is logically correct and low-risk in isolation: it adds one Stack.Screen entry (presentation card, animation slide_from_right, gestureEnabled false) consistent with sibling auth screens, and addresses the stated root cause (route missing from the navigator so it fell back to the default transition). No logic touched beyond navigation config. Main does not yet contain this route, so the fix is still needed. Caveat: PM comment recommends dismissing the ticket entirely; product decision may override merge.

Risk: Two-part bug. Per QA (Preji John, 2026-06-16) the push-notification half is now functioning, but the badge/unread-count indicator on the notification icon is still not displayed, so the second symptom remains unfixed. Ticket is correctly still In Progress with no resolution. Nothing is verified-passed; the remaining badge work is not done.

Risk: Single-file change to shared/components/feedback/AnimatedSplashScreen.tsx adding three safeguards: 4s soft cap (mark video complete), 7s hard cap (force-dismiss + hideAsync + onFinish), AppState foreground-resume, and status==="error" handling to release the gate on decode failure. The logic correctly prevents an infinite hang. HOWEVER it treats the symptom, not the root cause: the soft/hard caps merely time-bound the white splash rather than ensuring content is ready, which matches QA's 2026-06-18 finding that the white screen still appears, just shorter. The softCap effect depends on [onFinish] but reads hasVideoCompleted/hasFinished without listing them as deps; the hardCap closure captures stale state but uses the hasFinished ref so it stays correct. AppState handler force-sets hasVideoCompleted on every foreground, which could prematurely end the splash animation on a normal resume. Overall: functional safety net, but does not resolve the reported defect.

Risk: Performance/UX bug about tab-switch latency. Status sits at "QA Verified" but resolution is null and there are zero comments documenting what was tested, how the delay was measured, or what the fix was. The original report itself flags the delay as hard to observe, which makes "QA Verified" hard to trust without recorded evidence (e.g., trace/frame timings). No code artifact exists to confirm any change was actually made. Risk that the status was advanced without a verifiable fix.

Risk: Branch adds an AppState "active" listener that resumes the player and force-sets hasVideoCompleted on EVERY foreground event, plus 4s soft / 7s hard timeout caps. Main already solved this better: it uses wasVideoPausedByBackgroundRef so it resumes ONLY on a genuine background-to-foreground transition during the splash, avoiding spurious play() calls during Android's startup AppState sequence, and a single 12s safety timeout. Main also handles the video error status (ANDROID-77) inline. Merging the branch would regress main's more careful background-detection logic and introduce a too-aggressive "complete on any active" behavior plus duplicate/overlapping timeout logic. The fix the ticket asks for is present and correct in main already.

Risk: No fix branch exists, so there is no code to review or merge. The ticket is in active dispute: QA (Preji John) reopened on 2026-06-18 with "Still same (video: not-refresh)", indicating the auto-refresh-on-navigate-back issue is still reproducible on QA's device. The developer counters that the behavior is an intentional "silent refresh" matching iOS (list updates in place without a skeleton reload) and that it works in his own testing of the offer-cancel flow. This is a behavioral/expectation mismatch rather than a confirmed code defect: QA may be expecting a visible refresh indicator while the implementation refreshes silently, OR there is a genuine device/timing-specific bug where the silent refresh does not fire. Unresolved (resolution=null). Not launch-ready until QA re-verifies against the video evidence.

Risk: The fix is technically sound and directly addresses the root cause: main still contains the original buggy block (// Redirect silently only when loading is finished and data is still missing. / if (!isLoadingOfferData && !apiOfferData?.data) { router.replace(backLink); return null; }) which calls router.replace during render and crashes on the New Architecture. The branch moves this into a useEffect with correct dependency array; useEffect is already imported. Low correctness risk. Caveat: despite board status "QA Verified", there is NO QA sign-off comment in Jira (only the dev/AI root-cause note), and the comment itself flags that on-device verification (redeem -> cancel -> reopen) was still pending. So the "QA Verified" status is not corroborated by any QA evidence in the ticket.

Risk: Board says "QA Verified" but the live Jira evidence contradicts it. The single (and latest) comment is from the QA engineer Preji John on 2026-06-16 stating "Still same" with a reproduction video and specific test accounts — i.e. the Intercom user-name bug was still reproducing after the last fix attempt. Resolution is unset (null) and status category is "In Progress" (yellow), not Done. No fix branch exists in the repo (the only intercom branch, fix/android-61-remove-intercom-token, belongs to ANDROID-82's unrelated sibling ANDROID-61). So there is no code to verify and active QA evidence that the bug persists. The "QA Verified" board status appears mislabeled/stale.

Risk: Cosmetic/visual-only defect (transient button flicker on selection); no functional or data-integrity risk and low severity. However there is NO code to validate: no fix branch, no commits, and no QA comment trail despite the "QA Verified" board state. Resolution field is null, so even though the workflow status reads QA Verified, the ticket is not formally resolved and no change set can be traced. Cannot confirm any fix was actually implemented or merged — the QA-Verified status is unsupported by any visible branch, commit, or comment evidence.

Risk: The branch's one-file change (app/index.tsx) defers the two awaited network calls (initializeDeviceToken, testSignupPending) to after router.replace so the index route stops rendering null/white. The change itself is correct and low-risk in isolation. BUT main has since been rewritten by the dev: index.tsx is now a video-splash screen that derives shouldGoHome from auth-store state, calls initializeDeviceToken() fire-and-forget (.catch) at line 56, and no longer calls testSignupPending() or blocks on these calls at all. The white-screen-causing await pattern no longer exists in main, so the fix is effectively already implemented there. Board says QA Verified, but the only Jira comment is the AI root-cause note from Vineet Kumar — no QA person (Preji John) recorded a verified/passed result, so qaSignal=none.

Risk: Live Jira confirms status "QA Verified" (assignee Preji John, type Bug, resolution still null). However the issue has ZERO comments, so there is no documented QA evidence (no tester sign-off, no reproduction/verification note) supporting the "QA Verified" board state. The bug itself is a low-severity cosmetic UI glitch: the "Apply" button briefly flickers when tapping an already-applied dedicated offer. No fix branch exists anywhere (local or origin) for this ticket, so there is no implementation to review and nothing to ship. A "QA Verified" status with no code, no resolution, and no comment trail is inconsistent and should be reconciled before relying on it for launch.

Risk: Cannot assess code correctness: there is NO fix branch and NO commits to review. The board shows QA Verified, but the Jira issue has zero comments, so there is no documented QA evidence (no tester sign-off, no test steps, no reopened/failed signal). Resolution is unset (null), which is inconsistent with a genuinely QA-verified/closed-out bug. Net: the status appears advanced manually with no traceable code or QA artifact backing it.

Risk: Bug is unresolved and actively reopened by QA. The reported behavior is that returning to the home page restores the previous scroll position instead of resetting to top, and the corrective auto-scroll is visible and jarring. Root cause is almost certainly scroll-state restoration / list state being retained across navigation (e.g. a saved LazyList/RecyclerView scroll position or cached page state). No fix code exists yet to assess, so correctness cannot be verified. This is a UX-facing launch-quality issue rather than a crash/data risk.

Risk: The fix itself is correct and low-risk in isolation: it addresses the documented root cause (unguarded data.data.token causing a TypeError, and a tokenless authStore.login causing a post-login white-screen). Notably, main's current code STILL does `const otpToken = data.data.token;` with no guard, so main has NOT fixed this crash on its own — the fix is genuinely still needed. Risk is in integration, not correctness: the branch was cut from merge-base 06b9088 where the success branch still contained the inline FCM block and generateTestFCMToken; main refactored that entire block away, so the branch's diff context no longer exists and a clean apply is impossible.

Risk: The fix itself is technically sound. OffersList.tsx: guards the skeleton with `&& transformedOffers.length === 0` so refetch/pull-to-refresh keeps existing cards (RefreshControl spinner only), and removes dead FlashList v2 props plus the bad overrideItemLayout(200px) that forced a reflow jump — correct for FlashList v2 which auto-measures. Offer.tsx: replaces the manual ActivityIndicator (transition=0, re-toggled on every recycle) with an expo-image transition=250 crossfade and adds a useEffect that resets imageError/retryCount on bannerImage change so a recycled cell can't show the fallback for a good image — sound recycling hygiene. Low correctness risk in isolation. Main still contains all the original buggy code, so the fix has NOT been superseded. Remaining risk is purely the merge conflict and the lack of the on-device visual verification the author flagged as still pending.

Risk: Code itself is correct and low-risk in isolation: void async IIFEs for FCM and Intercom are sound fire-and-forget patterns, setToken/saveToken exist on both refs, and local SecureStore writes stay awaited so the in-session token is set before home makes authenticated requests. The real risk is staleness: the formHandler half of this branch is superseded by main (which already navigates immediately and backgrounds FCM, using a better push-token source). Merging the branch as-is would either conflict or, if force-resolved toward the branch, regress main by reintroducing generateTestFCMToken (a test/placeholder token) over main's registerForPushNotificationsAsync. The genuinely valuable piece is the authStore Intercom de-blocking, which main has not yet adopted.

Risk: Bug is marked "QA Verified" yet has no associated fix branch and no code change to review, so the actual fix cannot be located or validated. Resolution field is unset and there are zero Jira comments, so there is no documented evidence of what was changed or how QA verified it. The status category is still "In Progress" (yellow), not Done. Either the fix was applied elsewhere (e.g., merged directly to main, in a backend repo, or a config change) or the status was advanced without an accompanying code change. Cannot confirm the re-upload-for-rejected-reviews defect is actually fixed.

Risk: Unimplemented bug fix. The issue describes a UX gap: the first device is logged out as expected but no toast informs the user. No code has been written (no branch, no commits), so there is no correctness risk to assess. The fix will likely touch the forced-logout/session-invalidation handling path where the toast should be surfaced. Note this is a "To Do" item with no in-progress work as of 2026-06-19.