[No QA] Update help docs for Release 1: Date-based mileage rates

[MelvinBot]

Explanation of Change

Help site updates for Release 1: Date-based mileage rates of the Date-bound mileage rates project. Release 1 lets admins set optional start/end dates on distance rates so Expensify automatically applies the rate matching an expense's date, and flags a violation when a manually selected rate doesn't match.

This PR documents that behavior in the two relevant New Expensify help articles:

• docs/articles/new-expensify/workspaces/Set-distance-rates.md (admin-facing)
  • Added an optional Start date / End date step when adding a rate.
  • Added a step to update effective dates when editing a rate.
  • Added a new section explaining how Expensify selects a rate when multiple rates exist, including the date-mismatch violation.
• docs/articles/new-expensify/reports-and-expenses/Distance-Expenses.md (member-facing)
  • Noted that when a workspace has multiple dated rates, the rate matching the expense date is applied automatically.
  • Updated the "Can I update the Distance expense unit or rate?" FAQ to explain the date-mismatch violation.

Fixed Issues

$ https://github.com/Expensify/Expensify/issues/639702
PROPOSAL:

Tests

// TODO: The human co-author must fill out the tests you ran before marking this PR as "ready for review".
// This is a docs-only change. Please review the rendered help articles for accuracy against the current Expensify UI (exact field/label names, start/end date behavior, and violation wording).

• Verify that no errors appear in the JS console

Offline tests

N/A — documentation-only change.

QA Steps

// TODO: The human co-author must fill out the QA tests you ran before marking this PR as "ready for review".

• 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 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
• I followed the guidelines as stated in the Review Guidelines
• 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

N/A — documentation-only change.

[stephanieelliott]

Content was drafted based on the design doc - will test this and take off hold once the feature hits staging.

[JmillsExpensify]

Nice, thank you! Both look great to me.

[melvin-bot]

Concierge reviewer checklist:

• I have verified the accuracy of the article
  • The article is within a hub that makes sense, and the navigation is correct
  • All processes, screenshots, and examples align with current product behavior.
  • All links within the doc have been verified for correct destination and functionality.
• I have verified the readability of the article
  • The article's language is clear, concise, and free of jargon.
  • The grammar, spelling, and punctuation are correct.
  • The article contains at least one image, or that an image is not necessary
• I have verified the formatting of the article
  • The article has consistent formatting (headings, bullet points, etc.) with other HelpDot articles and that aligns with the HelpDot formatting standards.
  • The article has proper text spacing and breaks for readability.
• I have verified the article has the appropriate tone and style
  • The article's tone is professional, friendly, and suitable for the target audience.
  • The article's tone, terminology, and voice are consistent throughout.
• I have verified the overall quality of the article
  • The article is not missing any information, nor does it contain redundant information.
  • The article fully addresses user needs.
• I have verified that all requested improvements have been addressed

For more detailed instructions on completing this checklist, see How do I review a HelpDot PR as a Concierge Team member?

cc @Kel-Expensify

[melvin-bot]

@Kel-Expensify 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]

[github-actions]

Structure violation (multiple # headings): Per HELP_AUTHORING_GUIDELINES.md Section 4, an article may have exactly one # heading (the title), plus an optional # FAQ — no other # headings. This adds a second # section heading. Demote it to ## (e.g. ## How Expensify selects a rate when multiple rates exist).

Heading case/task-based violation: Headings must use sentence case and be task-based. Use ## How Expensify selects a rate when multiple rates exist instead of Title Case.

[github-actions]

HelpDot Documentation Review

Overall Assessment

This PR documents Release 1 of date-based mileage rates across two New Expensify articles: Set-distance-rates.md (admin) and Distance-Expenses.md (member). The added copy is accurate, benefit-focused, and clearly explains the new Start date/End date behavior and the informational date-mismatch violation. The prose quality is strong, but one structural rule in the admin article needs correction before merge.

Scores Summary

• Readability: 9/10 - Added sentences are clear, concise, and scannable. Steps are sequential and action-oriented. The "This is informational and does not block submission" clarification is a nice touch that pre-empts user confusion.
• AI Readiness: 6/10 - Added copy uses full feature names and realistic search phrasing, but the new admin section is introduced as a second # (H1) heading (# How Expensify Selects a Rate When Multiple Rates Exist). Per HELP_AUTHORING_GUIDELINES.md Section 4, an article may contain exactly one # title plus an optional # FAQ and nothing else — all other sections must be ##. This must be demoted to ##.
• Style Compliance: 8/10 - Button/field names (Add Rate, Save, Delete, Start date, End date) are correctly bolded and match sentence case. The new H1 uses Title Case (How Expensify Selects a Rate When Multiple Rates Exist), which is inconsistent with the task-based sentence-style headings used elsewhere in the file (e.g., ## How to add Distance rates).

Key Findings

• Must fix: The new admin section # How Expensify Selects a Rate When Multiple Rates Exist is a second H1. Demote it to ## How Expensify selects a rate when multiple rates exist and drop the --- horizontal rule above it (the single-H1 rule is the primary violation). Update the in-article anchor link accordingly.
• Positive: Both additions correctly reuse the exact UI labels Start date / End date and consistently frame the violation as informational and non-blocking, which matches the described product behavior.
• Positive: The member-facing FAQ update and the admin cross-reference are well scoped and reinforce the primary workflow without over-linking.
• Minor: Heading casing — align the new heading to sentence case to match the rest of the article and the naming conventions.

Recommendations

• Convert the new # heading to ## and rephrase to sentence case; verify the anchor #how-expensify-selects-a-rate-when-multiple-rates-exist still resolves after the change.
• Optionally tighten the long member-facing bullet in Distance-Expenses.md (the sentence ending "...so you don't need to pick the right one manually") for parallel phrasing with the admin article.

Files Reviewed

• docs/articles/new-expensify/workspaces/Set-distance-rates.md - Content accurate; needs the second-H1 fix and heading-casing correction.
• docs/articles/new-expensify/reports-and-expenses/Distance-Expenses.md - Clean; additions comply with guidelines.

Note: Detailed line-by-line feedback has been provided as inline comments.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 665fa80d7c

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[OSBotify]

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

Updated articles:

• articles/new-expensify/reports-and-expenses/Distance-Expenses
• articles/new-expensify/workspaces/Set-distance-rates

[MelvinBot]

✅ All checks are now passing — the failure was transient and unrelated to this PR's changes.

What happened: The only failing check was validateSchemas. This PR is docs-only (it touches just Distance-Expenses.md and Set-distance-rates.md), so it changes no workflow or action files. The failure came from the check downloading the github-workflow.json JSON schema from schemastore.org and getting a corrupted/truncated response:

error: /tmp/.../github-workflow.json: Unexpected non-whitespace character after JSON at position 3 (line 1 column 4)
💥 Some actions and/or workflows are invalid

That's an environmental/network flake in the schema download step, not a problem with any file in the branch.

Resolution: A subsequent commit on the branch (9454f28) re-ran the check, which now passes. No code change was needed. The PR is green.

[OSBotify]

🚀 Deployed to staging by https://github.com/VictoriaExpensify in version: 9.4.32-0 🚀

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

[OSBotify]

🚀 Deployed to production by https://github.com/grgia in version: 9.4.32-3 🚀

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

Bundle Size Analysis (Sentry):

• Android