[Payment due @truph01] Docs updates for E/A#96567 note Smart Limit needs approval workflow

[MelvinBot]

Docs updates for E/A#96567

Why

Expensify/App#96567 changes the Expensify Card limit type selector so that Smart Limit is no longer hidden when a workspace uses Optional approvals — instead it is always shown but disabled, with a note that an approval workflow must be enabled to select it.

The New Expensify card setup articles listed Smart Limit as a selectable limit type but never mentioned that it depends on an approval workflow. This update documents that requirement so the help site matches the new UI behavior.

Changes

• docs/articles/new-expensify/expensify-card/Set-Up-and-Manage-the-Expensify-Card-US.md — updated the Smart Limit limit-type bullet to note it requires an approval workflow and appears disabled when approvals are Optional.
• docs/articles/new-expensify/expensify-card/Set-Up-and-Manage-the-Expensify-Card-UK-EU.md — same update.

I also corrected the label capitalization to Smart Limit (capital L) to match the product UI (smartLimit: 'Smart Limit'), per the naming conventions.

Notes

• Verified the exact UI strings against the source of truth in src/languages/en.ts (smartLimit, smartLimitDescription, smartLimitDisabledDescription). I was not able to confirm against a live UI session because the test session landed logged-out, so please double-check the wording against the current UI.
• Cardholder-facing articles (Cardholder-Settings-and-Features.md, Troubleshoot-Expensify-Card-issues.md) describe Smart Limit from the cardholder's perspective and are not affected by this admin-facing selector change, so they were left unchanged.

---

@truph01, please review the files changed and confirm they reflect the current behavior. Then post a new comment saying @MelvinBot mark this PR as ready for review.

[MelvinBot]

The only failing check is Check independent approval, and there's nothing to push a fix for.

That check isn't a build/lint/test failure — it's an approval gate that stays red until someone other than the PR author approves the PR. Every actual CI check (verify, check, spellcheck, dryRun, validate, CLA, verifySignedCommits, etc.) is passing.

To clear it: have a reviewer approve the PR. Once this docs update is reviewed and confirmed accurate, it'll go green on its own — no code change is needed from me.

[truph01]

@MelvinBot mark this PR as ready

[MelvinBot]

🤖 Done — this PR is now marked Ready for review (draft status removed).

Since this is a docs-only change (two .md files under docs/articles/), no app testing was needed to flip it out of draft.

[github-actions]

Cross-linking violation (HELP_AUTHORING_GUIDELINES.md Section 7): "Enable approvals" is a dependency the reader must act on to unblock this option, and in the UI it is a hyperlink. Per the Cross-Linking Standards it should be a relative cross-link with descriptive anchor text (e.g. [learn how to enable approvals](/articles/new-expensify/workspaces/Add-Approvals.md)) rather than plain prose. Also, per the Deterministic Writing Rule, avoid the vague pronoun "select it" — mirror the UI wording "select this option".

[github-actions]

Cross-linking violation (HELP_AUTHORING_GUIDELINES.md Section 7): "Enable approvals" is a dependency the reader must act on to unblock this option, and in the UI it is a hyperlink. Per the Cross-Linking Standards it should be a relative cross-link with descriptive anchor text (e.g. [learn how to enable approvals](/articles/new-expensify/workspaces/Add-Approvals.md)) rather than plain prose. Also, per the Deterministic Writing Rule, avoid the vague pronoun "select it" — mirror the UI wording "select this option".

[github-actions]

HelpDot Documentation Review

Overall Assessment
This is a small, well-scoped PR that updates the Smart Limit limit-type bullet in the two Expensify Card setup articles (US and UK-EU) to document that Smart Limit requires an approval workflow and appears disabled when a workspace's approvals are set to Optional. The change accurately reflects the new UI behavior from E/A#96567 and corrects the label casing to match the product UI. Two files changed, 2 additions and 2 deletions.

Scores Summary

• Readability: 9/10 - The added sentence is clear, concise, and action-oriented ("Enable approvals to select it."). It reads naturally within the existing bullet list.
• AI Readiness: 8/10 - Full feature name ("Smart Limit") and UI-exact terminology are used, improving retrieval. No headings/metadata were touched, so no structural regressions; the change is neutral-to-positive here.
• Style Compliance: 8/10 - The casing fix ("Smart limit" to "Smart Limit") correctly follows the exact-UI-text rule in HELPSITE_NAMING_CONVENTIONS.md, and Optional is bolded as a UI value. Minor deductions noted below.

Key Findings

• Strength: Correctly aligns the label with the product UI string (smartLimit: 'Smart Limit') per the core UI referencing rules, and both files receive the identical update for consistency.
• Strength: The new sentence is deterministic and explicit about the dependency (approval workflow required, disabled under Optional), matching the exact-terminology and cross-platform clarity intent of the governance docs.
• Minor: A typographic/curly apostrophe is used in "workspace's". Prefer a straight apostrophe for consistency and to avoid encoding issues.
• Minor: Only the changed bullet was recapitalized. The sibling bullets ("Monthly limit", "Fixed limit", "Single-use") remain lowercase and now differ in casing from "Smart Limit". These are outside the diff and not required for this PR, but the inconsistency is worth flagging to product/UI to confirm the true UI casing for all limit types.
• Note: Per the PR description, the wording was verified against src/languages/en.ts but not against a live UI session. A reviewer should confirm the final phrasing against the current product UI.

Recommendations

• Replace the curly apostrophe in "workspace's" with a straight apostrophe in both files.
• Confirm with the reviewer whether the other limit-type labels should also be capitalized to match the UI, for consistency with the "Smart Limit" fix (can be a follow-up).
• Confirm the added phrasing against a live UI session before merge, as flagged in the PR notes.

Files Reviewed

• docs/articles/new-expensify/expensify-card/Set-Up-and-Manage-the-Expensify-Card-US.md - Approved with minor apostrophe nit.
• docs/articles/new-expensify/expensify-card/Set-Up-and-Manage-the-Expensify-Card-UK-EU.md - Approved with minor apostrophe nit.

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

[MelvinBot]

I looked into the failing checks. There's nothing to fix in the code — all substantive checks (review, validate, spellcheck, check, dryRun, verify, CLA, signed commits) are passing.

The only red check is Check independent approval, which isn't a code failure. It's a policy gate that stays red until a human reviewer other than the PR author approves the PR. Because this PR was opened by MelvinBot, it has no independent approval yet, so the check will keep failing until someone reviews and approves it.

Next step: truph01, please review the docs changes and approve the PR. Once there's an independent approval, that check will go green — no push from me is needed.

[melvin-bot]

🎯 @truph01, thanks for reviewing and testing this PR! 🎉

A payment issue will be created for your review once this PR is deployed to production.
E/E issue linked to the PR - no internal issue.

If payment is not needed (e.g., regression PR review fix etc), react with 👎 to this comment to prevent the payment issue from being created.

[MelvinBot]

Re-checked — nothing changed and there's still no code fix to push. Every substantive check passes (review, validate, spellcheck, check, dryRun, verify, checklist, CLA, signed commits).

The only red check is Check independent approval, which is a policy gate, not a code failure. It stays red until a reviewer other than the PR author approves this PR. Since it was opened by MelvinBot, it has no independent approval yet.

Next step: truph01, please review the docs changes and approve the PR — that check will then go green. No push from me is needed (and one wouldn't clear this check).