Merge origin/main and resolve conflicts

- Keep hasPolicies variable from main with Onyx.connect
- Remove allBetas block as it was removed in main

Co-authored-by: Cursor <[email protected]>

Author: justinpersaud

.claude/agents/code-inline-reviewer.md

@@ -66,58 +66,48 @@ Bad:
 
 ---
 
-### [PERF-2] Use early returns in array iteration methods
+### [PERF-2] Return early before expensive work
 
-- **Search patterns**: `.every(`, `.some(`, `.find(`, `.filter(`
+- **Search patterns**: Function bodies where `if (!param)` or `if (param === undefined)` appears AFTER function calls that use `param`
 
 - **Condition**: Flag ONLY when ALL of these are true:
 
-  - Using .every(), .some(), .find(), .filter() or similar function
-  - Function contains an "expensive operation" (defined below)
-  - There exists a simple property check that could eliminate items earlier
-  - The simple check is performed AFTER the expensive operation
-
-  **Expensive operations are**:
-
-  - Function calls (except simple getters/property access)
-  - Regular expressions
-  - Object/array iterations
-  - Math calculations beyond basic arithmetic
-
-  **Simple checks are**:
-
-  - Property existence (!obj.prop, obj.prop === undefined)
-  - Boolean checks (obj.isActive)
-  - Primitive comparisons (obj.id === 5)
-  - Type checks (typeof, Array.isArray)
+  - Code performs expensive work (function calls, iterations, API/Onyx reads)
+  - A simple check could short-circuit earlier
+  - The simple check happens AFTER the expensive work
 
   **DO NOT flag if**:
 
-  - No expensive operations exist
-  - Simple checks are already done first
-  - The expensive operation MUST run for all items (e.g., for side effects)
+  - Simple checks already come first
+  - Validation requires the computed result
+  - Expensive work must run for side effects
 
-- **Reasoning**: Expensive operations can be any long-running synchronous tasks (like complex calculations) and should be avoided when simple property checks can eliminate items early. This reduces unnecessary computation and improves iteration performance, especially on large datasets.
+- **Reasoning**: Early returns prevent wasted computation. Validate inputs before passing them to expensive operations.
 
 Good:
 
 ```ts
-const areAllTransactionsValid = transactions.every((transaction) => {
-    if (!transaction.rawData || transaction.amount <= 0) {
-        return false;
+function clearReportActionErrors(reportID: string, reportAction: ReportAction) {
+    if (!reportAction?.reportActionID) {
+        return;
     }
-    const validation = validateTransaction(transaction);
-    return validation.isValid;
-});
+
+    const originalReportID = getOriginalReportID(reportID, reportAction);
+    // ...
+}
 ```
 
 Bad:
 
 ```ts
-const areAllTransactionsValid = transactions.every((transaction) => {
-    const validation = validateTransaction(transaction);
-    return validation.isValid;
-});
+function clearReportActionErrors(reportID: string, reportAction: ReportAction) {
+    const originalReportID = getOriginalReportID(reportID, reportAction);
+
+    if (!reportAction?.reportActionID) {
+        return;
+    }
+    // ...
+}
 ```
 
 ---
@@ -996,6 +986,8 @@ function ReportScreen({ params: { reportID }}) {
 
 - **Reasoning**: When parent components compute and pass behavioral state to children, if a child's requirements change, then parent components must change as well, increasing coupling and causing behavior to leak across concerns. Letting components own their behavior keeps logic local, allows independent evolution, and follows the principle: "If removing a child breaks parent behavior, coupling exists."
 
+**Distinction from CLEAN-REACT-PATTERNS-3**: This rule is about data flow DOWN (parent → child) — "Don't pass data the child can get itself."
+
 Good (component owns its behavior):
 
 - Component receives only IDs and handlers
@@ -1079,6 +1071,226 @@ In this example:
 
 ---
 
+### [CLEAN-REACT-PATTERNS-3] Design context-free component contracts
+
+- **Search patterns**: Callback props with consumer-specific signatures like `(index: number) => void`, props used only to extract values for callbacks, refs used to access external component state, useImperativeHandle
+
+- **Condition**: Flag ONLY when BOTH of these are true:
+
+  1. A component's interface is shaped around a specific consumer's implementation rather than abstract capabilities
+  2. AND at least ONE of the following manifestations is present:
+     - The component receives data only to extract values for callbacks (doesn't use it for rendering)
+     - Callback signatures encode consumer-specific assumptions (e.g., `(index: number) => void` for navigation)
+     - The component accesses external state through refs or imperative handles
+
+  **Signs of violation:**
+  - Callback signatures that encode consumer assumptions: `navigateToWaypoint(index: number)` instead of `onAddWaypoint()`
+  - Props passed only to extract values for callbacks, not for rendering (e.g., `transaction` passed just to compute `waypoints.length`)
+  - Imperative access to external state via refs or `useImperativeHandle`
+  - Component requires modification to work in a different context
+
+  **DO NOT flag if:**
+  - Component signals events with data it naturally owns (e.g., `onChange(value)` for an input, `onSelectItem(item)` for a list)
+  - Callbacks are abstract actions the component can trigger (e.g., `onAddStop()`, `onSubmit()`)
+  - State coordination happens at a higher level with clear data flow
+
+  **What makes a contract "abstract":**
+  - Callback describes *what happened* in component terms: `onAddStop`, `onSelect`, `onChange`
+  - Callback does NOT describe *what consumer should do*: `navigateToWaypoint(index)`, `updateParentState(value)`
+  - Props are used for rendering or internal logic, not just to compute callback arguments
+  - Component works without modification in a different context
+
+- **Reasoning**: A component's contract should expose its capabilities abstractly, not encode assumptions about how it will be used. When interfaces leak consumer-specific details, the component becomes coupled to that context and requires modification for reuse. Good contracts signal *what the component can do*, not *what the consumer needs*.
+
+**Distinction from CLEAN-REACT-PATTERNS-2**: PATTERNS-2 ensures components fetch their own data. This rule ensures components expose abstract capabilities, not consumer-specific interfaces.
+
+Good (abstract contract):
+
+- Interface exposes capability: "user can add a stop"
+- Implementation details (index computation, navigation) stay with consumer
+- Component is reusable in any context needing an "add stop" action
+
+```tsx
+<DistanceRequestFooter
+    onAddStop={() => {
+        const nextIndex = Object.keys(transaction?.comment?.waypoints ?? {}).length;
+        Navigation.navigate(ROUTES.MONEY_REQUEST_STEP_WAYPOINT.getRoute(..., nextIndex.toString(), ...));
+    }}
+/>
+
+// in DistanceRequestFooter
+<Button onPress={onAddStop}>{translate('distance.addStop')}</Button>
+```
+
+Bad (contract leaks consumer assumptions):
+
+- Callback `navigateToWaypointEditPage(index: number)` encodes routing assumption
+- `transaction` prop exists only to compute index for callback
+- Requires modification if consumer navigates differently
+
+```tsx
+type DistanceRequestFooterProps = {
+    waypoints?: WaypointCollection;
+    navigateToWaypointEditPage: (index: number) => void;  // Encodes routing assumption
+    transaction: OnyxEntry<Transaction>;
+    policy: OnyxEntry<Policy>;
+};
+
+// in IOURequestStepDistance
+<DistanceRequestFooter
+    waypoints={waypoints}
+    navigateToWaypointEditPage={navigateToWaypointEditPage}
+    transaction={transaction}
+    policy={policy}
+/>
+
+// in DistanceRequestFooter - computes value for consumer's callback
+<Button
+    onPress={() => navigateToWaypointEditPage(Object.keys(transaction?.comment?.waypoints ?? {}).length)}
+    text={translate('distance.addStop')}
+/>
+```
+
+Good (independent contracts):
+
+- Each component has a self-contained interface
+- State coordination happens at composition level
+
+```tsx
+function EditProfile() {
+    const [formData, setFormData] = useState<FormData>();
+    return (
+        <>
+            <Form onChangeFormData={setFormData} />
+            <SaveButton onSave={() => API.save(formData)} />
+        </>
+    );
+}
+```
+
+Bad (coupled contracts):
+
+- `SaveButton` interface requires knowledge of `Form`'s internals
+- Neither component works independently
+
+```tsx
+function SaveButton({ getSiblingFormData }: { getSiblingFormData: () => FormData }) {
+    const handleSave = () => {
+        const formData = getSiblingFormData(); // Reaches into sibling
+        API.save(formData);
+    };
+    return <Button onPress={handleSave}>Save</Button>;
+}
+
+// Parent wires siblings together
+<Form ref={formRef} />
+<SaveButton getSiblingFormData={() => formRef.current?.getData()} />
+```
+
+---
+
+### [CLEAN-REACT-PATTERNS-5] Keep state and subscriptions narrow
+
+- **Search patterns**: Contexts/hooks/stores exposing large bundled objects, providers with many unrelated `useOnyx` calls, state structures mixing unrelated concerns
+
+- **Condition**: Flag when a state structure (context, hook, store, or subscription) bundles unrelated concerns together, causing consumers to re-render when data they don't use changes.
+
+  **Signs of violation:**
+  - State provider (context, hook, or store) that bundles unrelated data (e.g., navigation state + list data + cache utilities in one structure)
+  - State object where properties serve different purposes and change independently
+  - Multiple unrelated subscriptions (`useOnyx`, `useContext`, store selectors) aggregated into a single exposed value
+  - Consumers of a state source that only use a subset of the provided values
+
+  **DO NOT flag if:**
+  - State values are cohesive — they change together and serve the same purpose (e.g., `keyboardHeight` + `isKeyboardShown` both relate to keyboard state)
+  - The state structure is intentionally designed as an aggregation point and consumers use most/all values
+  - Individual `useOnyx` calls without selectors — this is covered by [PERF-11]
+
+- **Reasoning**: When unrelated pieces of data are grouped into a single state structure, if an unused part changes, then all consumers re-render unnecessarily. This silently expands render scope, increases coupling, and makes performance regressions hard to detect. Structuring state around cohesive concerns ensures render scope stays predictable and changes remain local.
+
+**Distinction from PERF-11**: PERF-11 addresses individual `useOnyx` selector usage. This rule addresses state structure — how multiple values are grouped and exposed to consumers via contexts, hooks, or stores.
+
+**Distinction from CLEAN-REACT-PATTERNS-2**: PATTERNS-2 addresses data flow direction — parent shouldn't fetch data just to pass to children. This rule addresses how state is structured and grouped within any state provider.
+
+Good (cohesive state — all values serve one purpose):
+
+- All state relates to one concern (keyboard)
+- Values change together — no wasted re-renders
+- Derived state computed inline, not stored separately
+
+```tsx
+type KeyboardStateContextValue = {
+    isKeyboardShown: boolean;
+    isKeyboardActive: boolean;
+    keyboardHeight: number;
+};
+
+function KeyboardStateProvider({children}: ChildrenProps) {
+    const [keyboardHeight, setKeyboardHeight] = useState(0);
+    const [isKeyboardActive, setIsKeyboardActive] = useState(false);
+
+    useEffect(() => {
+        const showListener = KeyboardEvents.addListener('keyboardDidShow', (e) => {
+            setKeyboardHeight(e.height);
+            setIsKeyboardActive(true);
+        });
+        const hideListener = KeyboardEvents.addListener('keyboardDidHide', () => {
+            setKeyboardHeight(0);
+            setIsKeyboardActive(false);
+        });
+        return () => {
+            showListener.remove();
+            hideListener.remove();
+        };
+    }, []);
+
+    const contextValue = useMemo(() => ({
+        keyboardHeight,
+        isKeyboardShown: keyboardHeight !== 0,  // Derived, not separate state
+        isKeyboardActive,
+    }), [keyboardHeight, isKeyboardActive]);
+
+    return <KeyboardStateContext.Provider value={contextValue}>{children}</KeyboardStateContext.Provider>;
+}
+```
+
+Bad (grab-bag state — bundles unrelated concerns):
+
+- State provider subscribes to many unrelated Onyx collections
+- Exposed value mixes navigation state, list data, membership data, and cache utilities
+- Any consumer re-renders when ANY subscribed value changes
+
+```tsx
+function SidebarOrderedReportsContextProvider({children}) {
+    // ❌ Many unrelated Onyx subscriptions bundled together
+    const [priorityMode] = useOnyx(ONYXKEYS.NVP_PRIORITY_MODE);
+    const [chatReports] = useOnyx(ONYXKEYS.COLLECTION.REPORT);
+    const [policies] = useOnyx(ONYXKEYS.COLLECTION.POLICY);
+    const [transactions] = useOnyx(ONYXKEYS.COLLECTION.TRANSACTION);
+    const [transactionViolations] = useOnyx(ONYXKEYS.COLLECTION.TRANSACTION_VIOLATIONS);
+    const [reportNameValuePairs] = useOnyx(ONYXKEYS.COLLECTION.REPORT_NAME_VALUE_PAIRS);
+    const [reportsDrafts] = useOnyx(ONYXKEYS.COLLECTION.REPORT_DRAFT_COMMENT);
+    const [betas] = useOnyx(ONYXKEYS.BETAS);
+    const [reportAttributes] = useOnyx(ONYXKEYS.DERIVED.REPORT_ATTRIBUTES);
+
+    // ❌ Context value mixes unrelated concerns
+    const contextValue = {
+        orderedReports,         // List data
+        orderedReportIDs,       // List data
+        currentReportID,        // Navigation state
+        policyMemberAccountIDs, // Policy membership
+        clearLHNCache,          // Cache management utility
+    };
+
+    return <Context.Provider value={contextValue}>{children}</Context.Provider>;
+}
+
+// A component needing only currentReportID re-renders when orderedReports changes
+// A component needing only policyMemberAccountIDs re-renders when navigation changes
+```
+
+---
+
 ## Instructions
 
 1. **First, get the list of changed files and their diffs:**

.claude/agents/deploy-blocker-investigator.md

@@ -207,6 +207,8 @@ Technical explanation of what went wrong in the code.
 
 **DO NOT:**
 - Remove `DeployBlockerCash` if there's an App PR that caused or contributed to the issue
+- Remove `DeployBlockerCash` if the issue is not reproducible on production
+- Remove any of the blocker labels if it has been added by an internal employee
 - Remove both blocker labels simultaneously
 - Make assumptions about code you haven't read
 - Recommend DEMOTE for bugs affecting core functionality (auth, payments, data loss)

.github/workflows/testBuildOnPush.yml

@@ -5,6 +5,10 @@ on:
     branches: [main]
     paths-ignore: ['docs/**', 'contributingGuides/**', 'help/**', '.github/**', 'scripts/**', 'tests/**', 'jest/**', '.claude/**']
 
+concurrency:
+  group: 'testBuildOnPush'
+  cancel-in-progress: false
+
 jobs:
   prep:
     runs-on: ubuntu-latest
@@ -432,7 +436,6 @@ jobs:
               summary.addRaw(`\n**Mobile-Expensify Submodule SHA:** [${submoduleSHA}](${submoduleUrl})`);
             }
             
-
             const prUrl = '${{ needs.prep.outputs.PR_URL }}';
 
             if (prUrl) {
@@ -441,5 +444,4 @@ jobs:
               summary.addRaw(`\n**PR Link:** No PR associated with this commit.`);
             }
             
-            
             summary.write();

Mobile-Expensify

@@ -114,8 +114,8 @@ android {
         minSdkVersion rootProject.ext.minSdkVersion
         targetSdkVersion rootProject.ext.targetSdkVersion
         multiDexEnabled rootProject.ext.multiDexEnabled
-        versionCode 1009031148
-        versionName "9.3.11-48"
+        versionCode 1009031301
+        versionName "9.3.13-1"
         // Supported language variants must be declared here to avoid from being removed during the compilation.
         // This also helps us to not include unnecessary language variants in the APK.
         resConfigs "en", "es"