[No QA] Update reviewer bot to reference helpsite governance files

[stephanieelliott]

Explanation of Change

Update helpdot reviewer prompt to replace the static rules and point to help site governance files instead.

I tested these changes on a fake file to confirm this works, see this comment for results: #85172 (comment)

Fixed Issues

$ none
PROPOSAL:

Tests

1. Create a helpdot article that breaks helpdot rules (### headings and includes policy for example)
2. Confirm the reviewer flags it as a violation

I tested this already on this branch to confirm it works correctly: #85172 (comment)

• Verify that no errors appear in the JS console

Offline tests

N/A

QA Steps

Same as tests.

• Verify that no errors appear in the JS console

PR Author Checklist

• I linked the correct issue in the ### Fixed Issues section above
• I wrote clear testing steps that cover the changes made in this PR
  • I added steps for local testing in the Tests section
  • I added steps for the expected offline behavior in the Offline steps section
  • I added steps for Staging and/or Production testing in the QA steps section
  • I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
  • I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
  • I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).
• I included screenshots or videos for tests on all platforms
• I ran the tests on all platforms & verified they passed on:
  • Android: Native
  • Android: mWeb Chrome
  • iOS: Native
  • iOS: mWeb Safari
  • MacOS: Chrome / Safari
• I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
• I followed proper code patterns (see Reviewing the code)
  • I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
  • I verified that comments were added to code that is not self explanatory
  • I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
  • I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method
    • If any non-english text was added/modified, I used JaimeGPT to get English > Spanish translation. I then posted it in #expensify-open-source and it was approved by an internal Expensify engineer. Link to Slack message:
  • I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
  • I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
  • I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
  • I verified the JSDocs style guidelines (in STYLE.md) were followed
• If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
• I followed the guidelines as stated in the Review Guidelines
• I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
• I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
• I verified any variables that can be defined as constants (ie. in CONST.ts or at the top of the file that uses the constant) are defined as such
• I verified that if a function's arguments changed that all usages have also been updated correctly
• If any new file was added I verified that:
  • The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory
• If a new CSS style is added I verified that:
  • A similar style doesn't already exist
  • The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))
• If new assets were added or existing ones were modified, I verified that:
  • The assets are optimized and compressed (for SVG files, run npm run compress-svg)
  • The assets load correctly across all supported platforms.
• If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
• If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
• If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
• If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
• If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:
  • I verified that all the inputs inside a form are aligned with each other.
  • I added Design label and/or tagged @Expensify/design so the design team can review the changes.
• If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
• I added unit tests for any new feature or bug fix in this PR to help automatically prevent regressions in this user flow.
• If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.

Screenshots/Videos

[melvin-bot]

@inimaga Please copy/paste the Reviewer Checklist from here into a new comment on this PR and complete it. If you have the K2 extension, you can simply click: [this button]

[OSBotify]

A preview of your ExpensifyHelp changes have been deployed to https://25e8292d.helpdot.pages.dev ⚡️

Updated articles:

• articles/new-expensify/settings/fake-article

[github-actions]

HelpDot Documentation Review

Overall Assessment

This PR has two distinct parts: (1) updates to the reviewer bot agents and workflow configuration to reference centralized governance files, and (2) a new test article (fake-article.md) that appears intentionally designed to contain violations for testing the reviewer. The agent/workflow changes are well-structured improvements that centralize rule definitions. The fake article contains numerous governance violations across all three scoring dimensions, which is documented below for completeness.

Scores Summary (fake-article.md only)

• Readability: 3/10 - Multiple vague pronoun references ("it," "this"), prohibited navigation phrases ("Navigate to the area," "Go to the section," "Find the setting"), inconsistent step clarity, and placeholder description text that provides no useful information to the reader.
• AI Readiness: 2/10 - Four out of five headings use explicitly forbidden generic names (Introduction, Overview, Setup, Options). The title is not task-based. YAML metadata is missing the mandatory internalScope field, the description is a placeholder, and keywords are minimal. One heading uses ### depth, which is prohibited. Vague pronoun "it" appears in headings, preventing semantic retrieval.
• Style Compliance: 2/10 - Pervasive terminology violations ("Users" instead of "Members," "Policy" instead of "Workspace" in four instances), button names not bolded, button names wrapped in quotation marks, "Continue" used instead of "Next," "More menu" used instead of the required three dots notation with visual symbol, full URLs instead of relative links, vague anchor text ("click here," "Read more"), tab names not bolded, and FAQ sub-questions use ### instead of ##.

Key Findings

Governance file violations in fake-article.md (by category):

Heading violations (HELP_AUTHORING_GUIDELINES.md Section 2):

• # Introduction, ## Overview, ## Setup, # Options are all explicitly listed as forbidden generic headings.
• ### Where to find it uses prohibited ### depth and contains a vague pronoun.
• No heading includes the feature name "SmartMatch" in a task-based phrase (e.g., "How to enable SmartMatch in your Workspace").

Metadata violations (HELP_AUTHORING_GUIDELINES.md Section 3, TEMPLATE.md):

• internalScope field is entirely missing from YAML frontmatter (mandatory).
• description contains placeholder text rather than a benefit-focused summary.
• keywords should include task phrases and relevant roles, not just the feature name.

Terminology violations (HELPSITE_NAMING_CONVENTIONS.md):

• "Users" appears where "Members" is required (line 8).
• "Policy" appears where "Workspace" is required (lines 8, 16, 43).
• "Click Continue" should be "Click Next" (line 43).

UI referencing violations (HELPSITE_NAMING_CONVENTIONS.md):

• "Open the More menu" is explicitly prohibited; must use: Select the three dots (vertical-three-dots-symbol) (line 23).
• "tap the three dots" is missing the required bold visual symbol (line 31).
• Button names lack bold formatting: "Click Save" should be "Click Save" (line 24).
• Button name in quotation marks: "Save" should be Save without quotes (line 25).
• Tab name "Chat" not bolded (line 31).

Navigation violations (HELPSITE_NAMING_CONVENTIONS.md - Prohibited Language):

• "Navigate to the area where this is configured" (line 16).
• "Find the setting under your Policy settings" (line 16).
• "Go to the section for Workspace settings" (line 22).
• "go to the section and look for the options button" (line 37).

Cross-linking violations (HELP_AUTHORING_GUIDELINES.md Section 7):

• "click here" is explicitly listed as a prohibited anchor phrase (line 26).
• "Read more for details" is a vague anchor (line 49).
• Full URL used instead of relative link (line 37).
• Link placed inside a numbered step instruction (line 26), which is prohibited.

Positive aspects of the agent/workflow changes:

• Centralizing rules into governance files is a strong architectural improvement that ensures consistency between inline and summary reviewers.
• The workflow now triggers on synchronize events, catching re-pushes to a PR.
• The docs glob pattern change from docs/**/*.md + docs/**/*.csv to docs/** is broader and will catch all file types in the docs directory.
• The three governance files (HELPSITE_NAMING_CONVENTIONS.md, HELP_AUTHORING_GUIDELINES.md, TEMPLATE.md) are well-structured and provide clear, unambiguous rules.

Recommendations

1. If fake-article.md is intentionally a test fixture for validating the reviewer bot, consider adding a comment at the top of the file (or in the PR description) stating that it is intentionally non-compliant. This prevents confusion for future contributors.
2. If the fake article will persist in the repo, consider moving it to a test fixtures directory (e.g., docs/_test/ or .claude/test-fixtures/) so it is not accidentally published.
3. The fake-article.md should not be merged into the live docs path (docs/articles/new-expensify/settings/) as-is, since it would appear on the help site.

Files Reviewed

• .claude/agents/helpdot-inline-reviewer.md - Refactored to reference governance files as source of truth. Inline rule definitions replaced with pointers. Clean improvement.
• .claude/agents/helpdot-summary-reviewer.md - Parallel refactoring for summary reviewer. Scoring criteria now derived from governance files. Clean improvement.
• .claude/commands/review-helpdot-pr.md - Updated to list governance files as context for both subagents. Clean improvement.
• .github/workflows/claude-review.yml - Added synchronize trigger and broadened docs glob. Functional improvement.
• docs/articles/new-expensify/settings/fake-article.md - New test article with numerous intentional(?) governance violations across all three scoring dimensions (detailed above).

Note: Scoring applies only to the documentation content in fake-article.md. The agent configuration and workflow changes are well-structured and do not require scoring.

[github-actions]

Removing test comment - please ignore

[github-actions]

(test comment - please disregard)

[github-actions]

HelpDot Inline Review: docs/articles/new-expensify/settings/fake-article.md

This review identifies specific violations of the governance files (HELP_AUTHORING_GUIDELINES.md, HELPSITE_NAMING_CONVENTIONS.md, TEMPLATE.md) found in the newly added fake-article.md. All references are to lines in the diff.

---

Line 2 -- YAML title uses forbidden generic heading

title: Overview of SmartMatch

"Overview" is a forbidden heading per HELP_AUTHORING_GUIDELINES Section 2. Titles must be task-based, searchable, and explicit. Replace with a task-based title such as title: How to match expenses with SmartMatch or title: How to enable SmartMatch in Expensify.

---

Line 3 -- YAML description is template placeholder text

description: This is used for SEO purposes.

This is the raw TEMPLATE.md placeholder, not a real description. Per HELP_AUTHORING_GUIDELINES Section 3, provide a 1-2 sentence summary of the outcome. Example: description: Learn how to use SmartMatch to automatically match expenses to company card transactions.

---

Line 4 -- YAML keywords are too sparse

keywords: [smartmatch, expenses]

Per TEMPLATE.md, keywords should follow the pattern [how to primary task, feature name, related task phrases]. Add task-based phrases and roles, e.g., keywords: [SmartMatch, how to match expenses, expense matching, automatic matching, Workspace Admin].

---

Line 5 -- Missing required internalScope field

The YAML frontmatter is missing internalScope, which is mandatory per HELP_AUTHORING_GUIDELINES Section 3 and TEMPLATE.md. Add it following:

internalScope: Audience is [target role]. Covers [single workflow]. Does not cover [excluded workflows].

---

Line 7 -- Forbidden generic H1 heading

# Introduction

"Introduction" is a forbidden heading per HELP_AUTHORING_GUIDELINES Section 2 (alongside Overview, Notes, Setup, Options, Step 1). The H1 must match the article title and be a task-based, feature-specific phrase.

---

Line 9 -- Multiple violations: vague references, wrong terminology

This article explains how to enable it and where to find the options. Users in a Policy can turn on this feature.

1. Vague reference: "enable it" and "this feature" -- specify "SmartMatch" by name.
2. Terminology violation: "Users" must be "Members" (per HELPSITE_NAMING_CONVENTIONS).
3. Terminology violation: "Policy" must be "Workspace" (per HELPSITE_NAMING_CONVENTIONS).
4. Prohibited language: "find the options" is vague -- use exact UI labels.

---

Line 13 -- Forbidden generic heading

## Overview

"Overview" is explicitly listed as a forbidden heading in HELP_AUTHORING_GUIDELINES Section 2. Replace with a task-based heading, e.g., ## How SmartMatch matches expenses automatically.

---

Line 15 -- Multiple prohibited language violations

SmartMatch helps you match expenses. Navigate to the area where this is configured. Find the setting under your Policy settings.

1. Prohibited language: "Navigate to the area" -- listed in HELPSITE_NAMING_CONVENTIONS prohibited phrases. Use exact UI path.
2. Prohibited language: "Find the setting" -- listed in HELPSITE_NAMING_CONVENTIONS prohibited phrases. Reference the exact setting name.
3. Vague reference: "this is configured" -- specify what "this" refers to.
4. Terminology violation: "Policy" must be "Workspace".

---

Line 19 -- Forbidden generic heading

## Setup

"Setup" is explicitly listed as a forbidden heading in HELP_AUTHORING_GUIDELINES Section 2. Replace with a task-based heading, e.g., ## How to enable SmartMatch in a Workspace.

---

Line 21 -- Prohibited language in step

1. Go to the section for Workspace settings.

"Go to the section" is prohibited language per HELPSITE_NAMING_CONVENTIONS. Provide the exact navigation path, e.g., 1. Go to **Settings** > **Workspaces** > **[Workspace Name]** > **[Section Name]**.

---

Line 22 -- Prohibited "More menu" reference

2. Open the More menu next to the expense.

Per HELPSITE_NAMING_CONVENTIONS (Three Dots Menu Rule), "More menu" is prohibited. Always write: Select the three dots **(⋮)** next to the expense. The symbol must be bolded and in parentheses.

---

Line 23 -- Button name not bolded

3. Click Save to apply your changes.

Per HELPSITE_NAMING_CONVENTIONS (Button Naming Standards), all button names must be bolded. Write: 3. Click **Save** to apply your changes.

---

Line 24 -- Button name in quotation marks

4. At the end of the flow, click "Save" to finish.

Per HELPSITE_NAMING_CONVENTIONS, button names must not be wrapped in quotation marks and must be bolded. Write: 4. At the end of the flow, click **Save** to finish.

---

Line 25 -- Prohibited anchor text plus link inside step

5. For more info, [click here](/articles/new-expensify/workspaces/Workspaces.md).

Two violations:

1. Prohibited anchor text: "click here" is forbidden per HELP_AUTHORING_GUIDELINES Section 7. Use descriptive text like [Learn how to configure Workspaces].
2. Link inside numbered step: Per HELP_AUTHORING_GUIDELINES, do not place links inside numbered step instructions. Move the link outside the step sequence.

---

Line 29 -- Forbidden heading plus extra H1

# Options

Two violations:

1. Forbidden heading: "Options" is explicitly listed in HELP_AUTHORING_GUIDELINES Section 2.
2. Heading hierarchy: Per HELP_AUTHORING_GUIDELINES Section 4, there should be only one primary # heading. This should be ## and use a task-based phrase, e.g., ## SmartMatch configuration options for Workspace Admins.

---

Line 31 -- Tab names not bolded plus prohibited three dots phrasing

You can configure various options here. Go to Settings and select Chat to get started. On mobile, tap the three dots to open the menu.

1. Tab names not bolded: "Settings" and "Chat" are UI tab names and must be bolded: Settings, Chat (per HELPSITE_NAMING_CONVENTIONS Tab Naming Standards).
2. Prohibited three dots phrasing: "tap the three dots to open the menu" must use the standard format: Select the three dots **(⋮)** -- must include the bolded symbol, and must not say "open the menu" (HELPSITE_NAMING_CONVENTIONS).
3. Vague language: "various options here" -- specify what can be configured.

---

Line 35 -- Forbidden heading level (###) plus vague heading

### Where to find it

Two violations:

1. Wrong heading level: Per HELP_AUTHORING_GUIDELINES Section 2 and TEMPLATE.md, only # and ## are allowed. ### is forbidden.
2. Vague heading: "Where to find it" uses the vague pronoun "it." Replace with a feature-specific heading, e.g., ## Where to find SmartMatch settings.

---

Line 37 -- Multiple prohibited language violations plus full URL

If you cannot see it, go to the section and look for the options button. Learn more at https://help.expensify.com/articles/new-expensify/workspaces/Workspaces.md.

1. Prohibited language: "go to the section" and "the options button" are both in the HELPSITE_NAMING_CONVENTIONS prohibited list.
2. Vague reference: "it" -- specify "SmartMatch."
3. Full URL instead of relative link: Per HELP_AUTHORING_GUIDELINES Section 7, use relative links only. Do not use full URLs.
4. Prohibited anchor text: "Learn more" is a vague anchor phrase per HELP_AUTHORING_GUIDELINES. Use descriptive text like [Learn how to configure Workspace settings](/articles/new-expensify/workspaces/Workspaces.md).

---

Line 43 -- FAQ question uses ### instead of

### How do I enable SmartMatch?

Per TEMPLATE.md, FAQ questions must use ## subheadings, not ###. Change to ## How do I enable SmartMatch?

---

Line 45 -- Terminology plus button label violations

Turn on the toggle in your Policy. Click Continue when you are done with each step.

1. Terminology violation: "Policy" must be "Workspace."
2. Button label violation: "Continue" should be Next per HELPSITE_NAMING_CONVENTIONS (the UI button is Next, not Continue). Also must be bolded: Click **Next**.

---

Line 47 -- FAQ question uses ### instead of ## plus vague reference

### Why cannot I see it?

1. Wrong heading level: Must be ##, not ###.
2. Vague reference: "it" should be the feature name. Per TEMPLATE.md pattern: ## Why cannot I see SmartMatch?

---

Line 49 -- Prohibited anchor text phrase

You might not be a Workspace Admin. Read more for details.

"Read more" is a prohibited anchor text phrase per HELP_AUTHORING_GUIDELINES Section 7. If linking, use descriptive text like [Learn about Workspace Admin roles and permissions]. If not linking, remove the vague phrase and provide the actual details inline.

---

Additional structural violation -- Missing "How to" heading

Per HELP_AUTHORING_GUIDELINES Section 6, every article must include at least one full "How to..." heading using the feature name. This article has none. Add a heading like ## How to enable SmartMatch in your Workspace.

---

Summary: 25+ individual violations found across terminology, prohibited language, heading hierarchy, generic headings, YAML metadata, button formatting, link standards, and structural requirements. The article needs significant rework to comply with the governance files.

[melvin-bot]

@mjasikowski Please copy/paste the Reviewer Checklist from here into a new comment on this PR and complete it. If you have the K2 extension, you can simply click: [this button]

[rushatgabhane]

LGTM

[mjasikowski]

Reviewer Checklist

• I have verified the author checklist is complete (all boxes are checked off).
• I verified the correct issue is linked in the ### Fixed Issues section above
• I verified testing steps are clear and they cover the changes made in this PR
  • I verified the steps for local testing are in the Tests section
  • I verified the steps for Staging and/or Production testing are in the QA steps section
  • I verified the steps cover any possible failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
  • I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
• I checked that screenshots or videos are included for tests on all platforms
• I included screenshots or videos for tests on all platforms
• I verified that the composer does not automatically focus or open the keyboard on mobile unless explicitly intended. This includes checking that returning the app from the background does not unexpectedly open the keyboard.
• I verified tests pass on all platforms & I tested again on:
  • Android: HybridApp
  • Android: mWeb Chrome
  • iOS: HybridApp
  • iOS: mWeb Safari
  • MacOS: Chrome / Safari
  • MacOS: Desktop
• If there are any errors in the console that are unrelated to this PR, I either fixed them (preferred) or linked to where I reported them in Slack
• I verified there are no new alerts related to the canBeMissing param for useOnyx
• I verified proper code patterns were followed (see Reviewing the code)
  • I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick).
  • I verified that comments were added to code that is not self explanatory
  • I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
  • I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method
  • I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
  • I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
  • I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
  • I verified the JSDocs style guidelines (in STYLE.md) were followed
• If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
• I verified that this PR follows the guidelines as stated in the Review Guidelines
• I verified other components that can be impacted by these changes have been tested, and I retested again (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar have been tested & I retested again)
• I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
• I verified any variables that can be defined as constants (ie. in CONST.ts or at the top of the file that uses the constant) are defined as such
• If a new component is created I verified that:
  • A similar component doesn't exist in the codebase
  • All props are defined accurately and each prop has a /** comment above it */
  • The file is named correctly
  • The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
  • The only data being stored in the state is data necessary for rendering and nothing else
  • For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
  • Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
  • All JSX used for rendering exists in the render method
  • The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions
• If any new file was added I verified that:
  • The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory
• If a new CSS style is added I verified that:
  • A similar style doesn't already exist
  • The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG)
• If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
• If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
• If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
• If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
• If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:
  • I verified that all the inputs inside a form are aligned with each other.
  • I added Design label and/or tagged @Expensify/design so the design team can review the changes.
• If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
• For any bug fix or new feature in this PR, I verified that sufficient unit tests are included to prevent regressions in this flow.
• If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
• I have checked off every checkbox in the PR reviewer checklist, including those that don't apply to this PR.

Screenshots/Videos

Android: HybridApp

Android: mWeb Chrome

iOS: HybridApp

iOS: mWeb Safari

MacOS: Chrome / Safari

MacOS: Desktop

[OSBotify]

✋ This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

[OSBotify]

🚀 Deployed to staging by https://github.com/mjasikowski in version: 9.3.38-0 🚀

platform	result
🕸 web 🕸	success ✅
🤖 android 🤖	success ✅
🍎 iOS 🍎	success ✅

[OSBotify]

🚀 Deployed to production by https://github.com/cristipaval in version: 9.3.38-4 🚀

platform	result
🕸 web 🕸	success ✅
🤖 android 🤖	success ✅
🍎 iOS 🍎	success ✅