[No QA] merge main with my branch

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

@@ -9,52 +9,25 @@ model: inherit
 
 You are **Support Doc Optimizer** — an AI trained to evaluate HelpDot articles written for Expensify and create inline comments for specific violations.
 
-Your job is to scan through changed documentation files and create **inline comments** for specific violations based on the three core criteria below.
+Your job is to scan through changed documentation files and create **inline comments** for specific violations. **All rules and criteria come from the help site governance files** — you must use them as the single source of truth.
+
+## Governance (source of truth)
+
+**Before reviewing, read these files and use them as the authoritative source for all rules and violations:**
+
+1. **docs/HELPSITE_NAMING_CONVENTIONS.md** — UI referencing (buttons, tabs, menus, navigation), button/tab naming standards, three dots menu rule, navigation instructions, prohibited language, deterministic writing.
+2. **docs/HELP_AUTHORING_GUIDELINES.md** — Article structure, heading rules, metadata requirements, step formatting, AI retrieval optimization, cross-linking, screenshot placeholders, pre-publish validation.
+3. **docs/TEMPLATE.md** — Required YAML frontmatter pattern, heading guidance, FAQ structure, and structural expectations.
+
+Create inline comments for any violation of the rules defined in those governance files. When in doubt, the governance docs override any other guidance.
 
 **CRITICAL — Review only the proposed changes:** You must evaluate and comment only on the **diff** (the lines added or modified in the PR). Do NOT create inline comments on lines that are unchanged—those belong to the old file and are not part of the proposal. Use `gh pr diff` to know exactly which lines were changed; only create comments on those line numbers. Commenting on unchanged lines is out of scope and can fail or confuse the author.
 
-## 1. Readability Violations (Create inline comments for)
-- Poor sentence clarity, grammar, or scannability issues
-- Illogical flow or ordering of sections  
-- Reading level above 8th grade (complex jargon)
-- Unnecessary filler or verbose language
-- Incorrect use of numbered steps or bullet points
-
-## 2. AI Readiness Violations (Create inline comments for)
-- Vague headings without full feature names (e.g., "Enable it", "Connect to it")
-- Short or generic headings instead of full task phrasing (e.g., "Options" → "Expense Rule options for Workspace Admins"; use the full task and audience in the heading)
-- Non-descriptive headings (e.g., "Where to find it" vs "Where to find Statement Matching")  
-- Vague references like "this," "that," or "it" without clear context
-- Missing or incomplete YAML metadata:
-```yaml
----
-title: [Full article title]
-description: [Concise, benefit-focused summary] 
-keywords: [feature name, related terms, navigation path, etc.]
-internalScope: Audience is [target role]. Covers [main topic]. Does not cover [excluded areas].
----
-```
-  - **internalScope** must always be present. If the article does not specify it, use a clear default following the pattern: `Audience is [target role]. Covers [main topic]. Does not cover [excluded areas].`
-- Wrong heading levels (using ### or deeper instead of # or ##)
-
-**Note:** A breadcrumb path after the H1 heading is **not** required. Do not flag missing breadcrumbs as a violation.
-
-## 3. Expensify Style Compliance Violations (Create inline comments for)
-- Voice and tone issues:
-  - Not casual yet professional
-  - Excessive exclamation marks (max 1 per 400 words)
-- Terminology violations:
-  - "Policy" instead of "Workspace"
-  - "User" instead of "Member"  
-  - Wrong role names (not "Workspace Admin," "Domain Owner")
-- Button label violations:
-  - "Continue" instead of "Next"
-  - "Save" instead of "Confirm" at end of flows
-- Markdown formatting violations
-- FAQ structure violations:
-  - Not using "# FAQ" as heading
-  - Questions not using ## subheadings
-  - Answers not in plain text
+### Violation categories (aligned with governance)
+
+- **Readability / structure:** Clarity, flow, scannability, step formatting, heading hierarchy — per HELP_AUTHORING_GUIDELINES.md and TEMPLATE.md.
+- **AI readiness:** Task-based headings, full feature names, YAML metadata (title, description, keywords, **internalScope**), no generic headings — per HELP_AUTHORING_GUIDELINES.md and TEMPLATE.md. (Breadcrumb paths after H1 are not required; do not flag their absence.)
+- **Naming and style:** Exact UI labels, button/tab naming, terminology (e.g. Workspace not Policy, Member not User), navigation phrasing, prohibited language — per HELPSITE_NAMING_CONVENTIONS.md and HELP_AUTHORING_GUIDELINES.md. FAQ must use `# FAQ` and ## for questions per TEMPLATE.md.
 
 ## Instructions
 

.claude/agents/helpdot-summary-reviewer.md

@@ -9,33 +9,30 @@ model: inherit
 
 You are a documentation quality specialist that provides comprehensive assessments of HelpDot documentation changes.
 
-Your job is to analyze all changed files and provide a single, comprehensive summary review with scores and overall recommendations.
+Your job is to analyze all changed files and provide a single, comprehensive summary review with scores and overall recommendations. **All scoring criteria and rules come from the help site governance files** — use them as the single source of truth.
+
+## Governance (source of truth)
+
+**Before reviewing, read these files and use them as the authoritative source for scoring and recommendations:**
+
+1. **docs/HELPSITE_NAMING_CONVENTIONS.md** — UI referencing, button/tab naming, navigation rules, prohibited language.
+2. **docs/HELP_AUTHORING_GUIDELINES.md** — Structure, heading rules, metadata, steps, AI retrieval, cross-linking, validation checklist.
+3. **docs/TEMPLATE.md** — YAML frontmatter, heading guidance, FAQ structure.
 
 **CRITICAL — Review only the proposed changes:** Base your assessment, scores, and recommendations **only on the changes being proposed** in the PR (the diff). Use `gh pr diff` to see what was added or modified. Do not score or critique unchanged portions of the file—those are from the old version and are not part of the proposal. Evaluate and feedback only on the diff.
 
 ## Scoring Criteria
 
-### 1. Readability (1-10)
-- Sentence clarity and grammar
-- Logical flow and organization  
-- Appropriate reading level (8th grade or below)
-- Clear, jargon-free language
-- Proper use of formatting elements
+Derive your scores from the governance files above:
 
-### 2. AI Readiness (1-10) 
-- Descriptive headings with full feature names and full task phrasing (e.g., "Expense Rule options for Workspace Admins" not "Options")
-- Clear context without vague references
-- Proper YAML metadata structure, including **internalScope** in the form: `Audience is [target role]. Covers [main topic]. Does not cover [excluded areas].` (use a clear default if not provided)
-- Consistent heading hierarchy (# and ## only)
+### 1. Readability (1-10)
+- Sentence clarity, flow, scannability, step formatting — per HELP_AUTHORING_GUIDELINES.md and TEMPLATE.md.
 
-**Note:** Breadcrumb paths after H1 are not required; do not penalize for their absence.
+### 2. AI Readiness (1-10)
+- Task-based headings, full feature names, YAML metadata (including **internalScope**), heading hierarchy (# and ## only) — per HELP_AUTHORING_GUIDELINES.md and TEMPLATE.md. (Breadcrumb paths after H1 are not required; do not penalize for their absence.)
 
 ### 3. Style Compliance (1-10)
-- Expensify voice and tone standards
-- Correct terminology (workspace, member, etc.)
-- Proper button labels and UI terms
-- Markdown formatting compliance
-- FAQ structure adherence
+- Exact UI terminology, button/tab naming, terminology (e.g. Workspace, Member), navigation phrasing, FAQ structure — per HELPSITE_NAMING_CONVENTIONS.md and HELP_AUTHORING_GUIDELINES.md.
 
 ## Output Format
 

.claude/commands/review-helpdot-pr.md

@@ -3,17 +3,21 @@ allowed-tools: Bash(gh pr comment:*),Bash(gh pr diff:*),Bash(gh pr view:*),mcp__
 description: Review a HelpDot documentation pull request
 ---
 
-Perform a comprehensive HelpDot documentation review using two specialized subagents:
+Perform a comprehensive HelpDot documentation review using two specialized subagents. Both reviewers use the **help site governance files** in the repo as the source of truth for rules and scoring:
+
+- **docs/HELPSITE_NAMING_CONVENTIONS.md** — UI referencing, button/tab naming, navigation
+- **docs/HELP_AUTHORING_GUIDELINES.md** — Structure, headings, metadata, AI retrieval, validation
+- **docs/TEMPLATE.md** — YAML frontmatter, heading guidance, FAQ structure
 
 ## Step 1: Inline Review
 Use the helpdot-inline-reviewer agent to:
 - Scan all changed documentation files
-- Create inline comments for specific HelpDot rule violations
+- Create inline comments for violations of the governance rules above
 - Focus on line-specific, actionable feedback
 
 ## Step 2: Summary Review  
 Use the helpdot-summary-reviewer agent to:
-- Analyze the overall quality of all changes
+- Analyze the overall quality of all changes using the governance criteria
 - Provide comprehensive assessment with scoring
 - Post one top-level PR comment with summary and recommendations
 

__mocks__/react-native-permissions.ts

@@ -1,15 +1,23 @@
-import {PERMISSIONS, RESULTS} from 'react-native-permissions/dist/commonjs/permissions';
+import {PERMISSIONS} from 'react-native-permissions/dist/commonjs/permissions';
 import type {ValueOf} from 'type-fest';
 
+const RESULTS = {
+    UNAVAILABLE: 'unavailable',
+    BLOCKED: 'blocked',
+    DENIED: 'denied',
+    GRANTED: 'granted',
+    LIMITED: 'limited',
+} as const;
+
 type Results = ValueOf<typeof RESULTS>;
 type ResultsCollection = Record<string, Results>;
 type NotificationSettings = Record<string, boolean>;
 type Notification = {status: Results; settings: NotificationSettings};
 
 const openLimitedPhotoLibraryPicker: jest.Mock<void> = jest.fn(() => {});
 const openSettings: jest.Mock<void> = jest.fn(() => {});
-const check = jest.fn(() => RESULTS.GRANTED as string);
-const request = jest.fn(() => RESULTS.GRANTED as string);
+const check = jest.fn(() => Promise.resolve(RESULTS.GRANTED as string));
+const request = jest.fn(() => Promise.resolve(RESULTS.GRANTED as string));
 const checkLocationAccuracy: jest.Mock<string> = jest.fn(() => 'full');
 const requestLocationAccuracy: jest.Mock<string> = jest.fn(() => 'full');
 

android/app/build.gradle

@@ -111,8 +111,8 @@ android {
         minSdkVersion rootProject.ext.minSdkVersion
         targetSdkVersion rootProject.ext.targetSdkVersion
         multiDexEnabled rootProject.ext.multiDexEnabled
-        versionCode 1009033600
-        versionName "9.3.36-0"
+        versionCode 1009033709
+        versionName "9.3.37-9"
         // 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"

babel.config.js

@@ -63,7 +63,7 @@ const webpack = {
 };
 
 const metro = {
-    presets: [[require('@react-native/babel-preset'), {disableImportExportTransform: true}]],
+    presets: [require('@react-native/babel-preset')],
     plugins: [
         ['babel-plugin-react-compiler', ReactCompilerConfig], // must run first!
 
@@ -174,14 +174,5 @@ module.exports = (api) => {
     const runningIn = api.caller((args = {}) => args.name);
     console.debug('  - running in: ', runningIn);
 
-    // Jest runs in Node.js without Metro's experimentalImportSupport transform,
-    // so Babel must handle import/export transforms for tests.
-    if (runningIn === 'babel-jest') {
-        return {
-            ...metro,
-            presets: [[require('@react-native/babel-preset'), {disableImportExportTransform: false}]],
-        };
-    }
-
-    return runningIn === 'metro' ? metro : webpack;
+    return ['metro', 'babel-jest'].includes(runningIn) ? metro : webpack;
 };

contributingGuides/AI_ETIQUETTE.md

@@ -0,0 +1,44 @@
+# AI Etiquette
+
+AI is a great tool for drafting, searching, summarizing, and exploring. Humans must own judgment, accountability, and quality.
+
+---
+
+## You Own What You Post
+
+If you submit a message, pull request, comment, or code with AI assistance, you are fully accountable for it. Before posting anything AI helped produce, you should be able to explain it without AI's help and feel confident putting your name behind it.
+
+## Avoid AI Slop
+
+"AI slop" is AI generated content copied and pasted with minimal to no human review. Use AI for brainstorming, research, and drafting, but treat it as a starting point, not the final result. Add your own context and nuance before sharing.
+
+## Don't Trust AI Blindly
+
+AI confidently says things that sound correct but are wrong. Always verify claims against source material. It's your job to understand and validate any AI-generated information you act on or share.
+
+## When AI Isn't Enough
+
+If a task can be fully automated with no human review, it should be automated for everyone, not done manually with AI. Our [AI Reviewers](/contributingGuides/philosophies/AI-REVIEWER.md) are an example: they do a first pass on code review, but they don't replace human review. You should still apply your own judgment when reviewing code, writing updates, or making decisions.
+
+---
+
+## Best Practices
+
+### Don't
+
+- Paste AI output directly without adding your own value
+- Submit AI-generated code you haven't tested, debugged, and confirmed follows our [coding standards](./STYLE.md)
+- Submit AI-generated code you don't fully understand
+- Post poorly formatted AI output or long walls of text without distilling the key points
+- Blame AI for mistakes. The mistake is yours regardless of the source
+- Use AI to generate responses during live conversations instead of engaging directly
+
+### Do
+
+- Use AI to summarize, draft, research, and explore
+- Review and edit all AI output before sharing. Put it in your own voice and make sure it's accurate
+- Verify AI claims against source information
+- Review all AI-generated code and content before asking others to review it
+- Verify AI-written PR descriptions and add context needed to explain the change
+- Provide evidence of manual testing on PRs, especially when test steps were AI-generated
+- Invest time in learning to write effective prompts and recognize quality output

contributingGuides/CONTRIBUTING.md

@@ -211,6 +211,9 @@ This helps future investigators understand the history and current status of err
 ### Important note about JavaScript Style
 - Read our official [JavaScript and React style guide](https://github.com/Expensify/App/blob/main/contributingGuides/STYLE.md). Please refer to our Style Guide before asking for a review.
 
+### Using AI tools
+- If you use AI tools (Copilot, Cursor, ChatGPT, etc.) to help write code or PR descriptions, please read our [AI Etiquette guide](https://github.com/Expensify/App/blob/main/contributingGuides/AI_ETIQUETTE.md). You are accountable for all AI output you submit.
+
 ### For external agencies that Expensify partners with
 Follow all the above above steps and processes. When you find a job you'd like to work on:
 - Post “I’m from [agency], I’d like to work on this job”