Use a shared 12px border radius for tables and content cards

[MelvinBot]

Explanation of Change

Tables and content cards are both "a surface with a different background that wraps content", but they used two different corner radii: tables were 8px and content cards were 16px. This harmonizes them on a single 12px value.

Adds one new variable, componentBorderRadiusCardAndTable: 12, in src/styles/variables.ts and applies it to the shared styles that every affected surface already routes through, so this is a value change rather than a sweep of individual screens:

• styles.tableTopRadius / styles.tableBottomRadius (8 → 12) — the outer corners of every table: components/Table (Workspace editor, Domain editor and Account tables), the Spend/Search tables, the report transaction table, and the RHP tables such as Merge Expense and Add expense to report. The table loading skeletons use the same styles, so they stay in sync.
• StyleUtils.getSearchTableHighlightBorderRadius (8 → 12) — the row highlight animation on narrow layouts, so it matches the table it sits in.
• styles.cardSectionContainer (16 → 12) — the Section component, which renders the content cards in the Workspace editor (Overview, Reports, Time, etc.), the Domain editor (SAML) and Account. This also covers the trip/reservation detail cards, which are Sections.
• styles.widgetContainer (16 → 12) — the widget cards on the Home page.
• styles.transactionListItemStyle (hardcoded 8 → the new variable) — transaction rows. Inside Search tables this radius is already overridden per row, so the visible effect is on the standalone lists such as Add expense to report.

Chat / Inbox preview cards

Per review feedback, the same 12px is applied to the report-action preview cards that appear in a chat. Each of these cards stacks two views that both carry the corner, so they are changed together:

• styles.reportContainerBorderRadius (16 → 12) — the inner cardBG/hover wrapper of the expense report and invoice preview, its empty and no-access placeholder states, and the scanning/whisper wrapper on the single expense preview.
• styles.borderedContentCardLarge → renamed styles.borderedReportPreviewCard (16 → 12) — the bordered variant of the expense report / invoice preview card. It had exactly one consumer (MoneyRequestReportPreviewBody), and leaving a key named Large on the 12 value while componentBorderRadiusLarge stays 16 would be misleading, hence the rename.
• styles.moneyRequestPreviewBox (16 → 12) — the single expense preview card in a chat, the transaction cards inside the report preview's carousel, and the inner surface of the trip room preview. The carousel cards had to move with their container, otherwise the inner corners would end up rounder than the card holding them.
• styles.reportPreviewBox (16 → 12) — the outer corner of the trip / travel room preview.
• styles.reportActionItemImages (hardcoded 12 → componentBorderRadiusCardAndTable - reportActionItemImagesInset, so 8) — the receipt thumbnail row at the top of a preview card. It is inset 4px from the card edge by reportActionItemImagesContainer, so its radius has to be the card radius minus that inset to stay concentric; the old 12 was 16 - 4. The 4 is now a shared reportActionItemImagesInset constant used by both styles so the two can't drift apart again.

Expense reports and invoices share one component — ActionContentRouter routes every REPORT_PREVIEW action to MoneyRequestReportPreview — so one radius covers both.

Left untouched: componentBorderRadius: 8 and componentBorderRadiusLarge: 16 themselves, styles.borderRadiusComponentLarge (a generic 16px utility used by eight-plus unrelated screens, which only shows up here as the trip card's inner reservations box), and styles.reportActionItemImagesMore (the "+N more receipts" badge corner, which is decorative rather than concentric with the card).

Fixed Issues

$ #101462
PROPOSAL: #101462 (comment)

Tests

// TODO: The human co-author must fill out the tests you ran before marking this PR as "ready for review"
// Please describe what tests you performed that validates your changed worked.

• Verify that no errors appear in the JS console

Offline tests

Not applicable — this is a style-value change with no network behavior.

QA Steps

// TODO: The human co-author must fill out the QA tests you ran before marking this PR as "ready for review".
// Please describe what QA needs to do to validate your changes and what areas do they need to test for regressions.

• 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 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 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)
• If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
• 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.
• 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.

AI Tests

Run locally by MelvinBot on this branch:

• npm run typecheck — passed.
• npm run lint-changed — passed.
• npm run react-compiler-compliance-check on the touched components — passed.
• npm test -- tests/unit/useSearchTableItemHighlightTest.ts tests/unit/useListItemHighlightTest.ts — 12 tests passed (these are the tests that assert on the highlight border radius).
• npm test -- tests/ui/MoneyRequestReportPreview.test.tsx tests/ui/TransactionPreviewContentTest.tsx tests/ui/FlightTripDetailsTest.tsx tests/ui/ReportActionItemTest.tsx — 253 tests passed (the suites covering the chat preview cards).
• Android verification of the tables and content cards — passed, screenshots here.
• Not run: browser verification of the chat preview cards. The CI web session handed to that run was stuck on a blank, unresponsive page and could not be recovered, so no screenshots were captured. Visual confirmation of the new radius on the chat preview cards is still needed.
• Not run: scripts/findUnusedStyles.ts — could not be executed in this environment. The one renamed style key (borderedContentCardLarge → borderedReportPreviewCard) was checked by hand: it had a single consumer, which was updated, and no references to the old name remain.

Screenshots/Videos

Android: Native

Android: mWeb Chrome

iOS: Native

iOS: mWeb Safari

MacOS: Chrome / Safari

[github-actions]

🚧 shawnborton has triggered a test Expensify/App build. You can view the workflow run here.

[MelvinBot]

The typecheck failure is not caused by this PR — main is broken. I did not push a fix.

Root cause: two PRs that each passed on their own collided on main:

• [Phase 2] Part 4 - Migrate deprecatedGetReportName to getReportName in libs made movedFromReportName a required property of getForReportAction (src/libs/ModifiedExpenseMessage.ts:294) and updated every test call site that existed when it was written.
• Render the Concierge system message for an automatic distance rate change added two new getForReportAction call sites to the same test file.

The migration PR merged second, so its sweep never saw those two new call sites. They are still missing the required property on main today, at tests/unit/ModifiedExpenseMessageTest.ts:460 and tests/unit/ModifiedExpenseMessageTest.ts:491 — exactly the two errors CI reported here.

It is already tracked: Investigate workflow job failing on main: typecheck / typecheck, opened 34 minutes before this PR's typecheck run.

Next step: nothing to change on this branch. Once main is green again, re-run the job and typecheck will pass. Merging main in right now would only pull the break onto this branch.

Why this isn't this PR's fault

• This PR only changes style values and two components that consume them. It never touches ModifiedExpenseMessage or its test.
• On this branch alone, getForReportAction still carries the old optional reportAttributes? parameter and the test file contains no reference to movedFromReportName, so the branch typechecks clean — which matches the local run recorded in the PR body.
• CI typechecks the PR-merged-with-main commit. Both failing files resolve to main's version in that merge, which is where the error comes from. The PR's typecheck run started at 20:28 UTC, after the migration PR landed on main at 19:54 UTC.

The other two non-green checks are also unrelated to the code: Check independent approval is failing because the PR does not have an independent approval yet, and ESLint check was still running when I looked.

---

view run

[shawnborton]

@MelvinBot please also implement this change for expense report/invoice/trip previews found in the Inbox in expenses chats.

[MelvinBot]

Still nothing to fix on this branch — both real failures come from main, and one of them has already been fixed there. I pushed no change.

ESLint check finished failing since my last comment, so here is the updated picture.

1. typecheck — main is still broken, and this is what blocks the PR

Unchanged from my previous comment. [Phase 2] Part 4 - Migrate deprecatedGetReportName to getReportName in libs made movedFromReportName a required property of getForReportAction (src/libs/ModifiedExpenseMessage.ts:294), but its sweep missed the two call sites that Render the Concierge system message for an automatic distance rate change had just added. Those two still lack the property on main right now, at tests/unit/ModifiedExpenseMessageTest.ts:460 and tests/unit/ModifiedExpenseMessageTest.ts:491. Tracked by Investigate workflow job failing on main: typecheck / typecheck, still open.

2. ESLint check — same kind of collision, but already fixed on main

The single error is no-unsafe-type-assertion at tests/unit/pages/workspace/accounting/netsuite/NetSuiteTokenInputFormTest.tsx:117 — another file this PR does not touch.

Thread beta overrides into the remaining util call sites added a required isBetaEnabledOrUnknown member to UsePermissions (src/hooks/usePermissions.ts:12). That NetSuite test mocked usePermissions with an object supplying only isBetaEnabled and cast it with as ReturnType<typeof usePermissions>, so the assertion became unsafe the moment the type grew a member.

[No QA] Add a non-production link back to token-based (SOAP) NetSuite setup then deleted that mock, 11 minutes after this PR's lint job started. Current main contains zero occurrences of the cast, so this error no longer exists there.

Next step: wait for the typecheck break on main to be fixed, then merge main into this branch once. That picks up both fixes together and the PR should go green. Merging main right now would clear the lint error but import the still-live typecheck break, so it is not worth doing yet.

Timeline, and why none of this comes from this PR

This PR changes only style values and the two components that consume them. It touches neither ModifiedExpenseMessage, nor usePermissions, nor any test file.

• 19:52:29 — \#100061 lands; UsePermissions gains a required member, making the NetSuite test's cast unsafe
• 19:54:10 — \#98047 lands; movedFromReportName becomes required, so two test call sites now type-error
• 20:26 — this PR's ESLint check starts against that main
• 20:28 — this PR's typecheck starts against that main
• 20:37:31 — \#101283 lands, removing the offending mock, so lint is fixed on main
• now — main is 10 commits further along: lint clean, typecheck still broken

CI lints and typechecks the PR-merged-with-main commit. Both failing files resolve to main's version in that merge rather than this branch's, which is why the branch passes these same checks locally.

Check independent approval is the third red check. It only reflects that the PR does not have an independent approval yet.

---

view run

[MelvinBot]

🤖 Android test steps verification results: ✅ pass

All 7 affected surfaces (home widgets, workspace/account Section cards, tables, money-request transaction rows, and the unreported-expense list) render with the new shared 12px rounded corners with clean clipping and no layout breaks. No JS console errors were observed during the run.

Step	Status
VERIFY 1: No JS console / app errors during the run Captured the full app.log via agent-device logs start; grepped for AndroidRuntime / FATAL EXCEPTION / RCTFatal / RedBox / console.error / LogBox markers and found none. Only benign environment noise was present (CameraX "No available camera can be found" — the emulator has no camera — and transient Onyx retry messages during initial sign-in/onboarding, unrelated to this styling PR).	✅
VERIFY 2: Home page widget cards (styles.widgetContainer) render with rounded corners and correct content clipping Home page "Time sensitive/Account", "Recently added", and "Discover" cards all show clearly rounded corners with content clipped cleanly inside.	✅
VERIFY 3: Workspace editor content cards (styles.cardSectionContainer / Section component) render with rounded corners Workspace > Overview shows the main details card and the "Expense policy" card with rounded corners; Workspace > Reports shows "Report title" and "Report fields" cards with rounded corners.	✅
VERIFY 4: Account settings content cards using the Section component render with rounded corners Account > Profile shows the "Public" and "Private" Section cards with rounded corners, matching the workspace editor cards.	✅
VERIFY 5: A table using styles.tableTopRadius / tableBottomRadius has rounded outer top/bottom corners with rows clipped inside Workspace > Members table: zoomed crops confirm rounded top corners around the "Members" header row and rounded bottom corners around the last member row, with row content clipped cleanly inside the outer radius.	✅
VERIFY 6: A money request report's transaction rows (transactionListItemStyle / MoneyRequestReportTransactionItem) render with rounded corners and no visual break Created a draft expense report with two expenses (Advertising and Benefits categories) and opened the report. The grouped transaction list ("Group by: Category") shows the outer container with rounded top corners above the first category header and rounded bottom corners below the last transaction row, with no overlap or clipping issues between rows.	✅
VERIFY 7: The "Add expense to report" list (UnreportedExpenseListItem) renders rows with rounded corners Created a second, separate draft report with an unreported expense, then from the first report used Add expense > Add existing expense. The resulting UnreportedExpenseListItem row ("Unreported Merchant, $500.00") renders with clearly rounded corners on the row container.	✅

The PR's Tests section is still a TODO placeholder, so the steps above were derived from the surfaces listed in the Explanation of Change. Verified on standalone Android NewDot (developmentDebug APK), not HybridApp.

---

view run · view recording

[MelvinBot]

Done — pushed as efb6578. The chat preview cards now use the same 12px as tables and content cards.

Each preview card stacks two views that both carry the corner, so they move together:

Style	Was	Now	Surface
reportContainerBorderRadius	16	12	Inner cardBG/hover wrapper of the expense report + invoice preview, its empty and no-access states, and the scanning/whisper wrapper on the single expense preview
borderedReportPreviewCard	16	12	Bordered variant of the expense report / invoice preview card
moneyRequestPreviewBox	16	12	Single expense preview in a chat, the carousel cards inside the report preview, and the trip preview's inner surface
reportPreviewBox	16	12	Outer corner of the trip / travel room preview
reportActionItemImages	12	8	Receipt thumbnail row at the top of a preview card

Expense reports and invoices share one component — ActionContentRouter sends every REPORT_PREVIEW action to MoneyRequestReportPreview — so one radius covers both. Trip detail cards were already at 12, since they are Sections.

Three judgement calls worth a look

The receipt thumbnail had to go down, not up. It sits 4px inside the card edge, so its radius is the card radius minus that inset — the old hardcoded 12 was 16 - 4. With the card at 12 it becomes 8, otherwise its corner curve would poke past the card's. The 4 is now a shared reportActionItemImagesInset constant used by both styles so they can't drift apart again.

The carousel cards had to move with their container. moneyRequestPreviewBox is both the standalone expense preview in a chat and the transaction cards inside the report preview's carousel. Leaving it at 16 would have made the inner cards rounder than the card holding them.

One rename. borderedContentCardLarge → borderedReportPreviewCard. It had exactly one consumer, and a key named Large sitting on 12 while componentBorderRadiusLarge stays 16 is a trap for the next person.

Deliberately left alone: borderRadiusComponentLarge (a generic 16px utility used by eight-plus unrelated screens — it only shows up here as the trip card's inner reservations box), and reportActionItemImagesMore (the "+N more receipts" badge corner, which is decorative rather than concentric with the card).

One gap you should know about. I could not visually verify these cards. typecheck, lint-changed and the React Compiler check all pass, and the four suites covering these components pass (253 tests) — but the CI browser session for this run came up on a blank, unresponsive page and could not be recovered, so there are no screenshots of the new radius on the preview cards. The Android screenshots in my earlier comment cover the tables and content cards from the first commit only, not these. Worth a look on your end before this goes up for review.

[MelvinBot]

All checks now pass. Nothing to fix, so I pushed no change.

main was repaired by Fix typecheck: pass movedFromReportName in ModifiedExpenseMessageTest at 20:24 UTC, which added the missing movedFromReportName argument to the two test call sites that were breaking typecheck. The latest CI run on this branch picked up that fixed main, and typecheck and ESLint check both went green — confirming the failures were never caused by this PR.

Current state: 34 passing, 0 pending, 1 failing.

The one red check is Check independent approval, and it is not a code problem. Its only failing step is Verify peer review — it simply gates on the PR having an independent human approval, which it does not have yet. That clears when a reviewer approves; there is nothing I can push to fix it.

---

view run

[shawnborton]

@MelvinBot please also implement this for all of the chart container cards in Spend > Insights

[MelvinBot]

Done — pushed as 3fef26a. The Spend > Insights chart container cards now use the same 12px.

Style	Was	Now	Surface
chartContainer	16	12	The card wrapping every chart in Spend > Insights — Spend over time, Top spenders, Top categories, Top merchants, Violations by submitter — via SearchChartWrapper
chartWebFallback	16	12	The chart's loading spinner surface and its "unable to display chart" state, which sit inside that card

All five Insights charts route through one wrapper, so a single value covers the whole section.

Two things worth a look before you approve

This also moves the charts Concierge posts in chat. chartContainer has three consumers: SearchChartWrapper (Insights) plus the two Victory container paths that render charts embedded in a chat message. I let that move rather than forking the key, because those cards sit next to the chat preview cards this PR already took to 12 — pinning them at 16 would be the odd one out. Say the word if you want Insights scoped on its own key.

I took the chart's own loading surface down too. chartWebFallback is the highlightBG box holding the spinner (and the WebGL-unsupported empty state) inside the chart card. Left at 16 it would be the last 16px surface in the chart stack. It's invisible on Insights, where the card is already highlightBG, but it does show against cardBG in the Home page's Insights widget — which is 12.

Left alone: chartTooltipBox (4 — a tooltip, not a card), pieChartLegendDot (a circle), and the bar chart's roundedCorners={8} (data marks, not a container). No other surface in src/components/Charts/ carries a radius.

One gap, same as last round. I could not visually verify these cards. typecheck passes, lintChanged reports no new violations, and 301 tests across the 19 chart suites pass — but the CI browser session for this run was handed over with a failed onboarding replay and the tab was a blank, unresponsive page for the entire run, so there are no screenshots. The Android screenshots cover the tables and content cards from the first commit only. That leaves both the chat preview cards and these chart cards unconfirmed visually — worth an eye on your end before this goes up for review.

Also: I could not edit the PR description in this environment, so its Explanation of Change and AI Tests sections don't yet mention this commit. The table above is the full scope of it.

[github-actions]

🚧 shawnborton has triggered a test Expensify/App build. You can view the workflow run here.

[MelvinBot]

🤖 There's nothing to fix in code — no check is failing on this PR's changes.

The only red check is Check independent approval, from .github/workflows/verifyPeerReview.yml. It's a review-policy gate, not a build or test failure: it fails because this PR has zero approving reviews. It will stay red until an independent engineer approves. Pushing a commit cannot clear it.

Every other check passed — typecheck, ESLint check, Oxfmt check, React Compiler Compliance, spellcheck, Check for unused styles, Storybook tests, Bun tests, and all 8 test jobs. branch-perf-tests was still running when I looked.

Two things do still need a human, though:

1. An approving review, to clear the failing gate.
2. The Tests and QA Steps sections in the PR body are still // TODO placeholders, and most author-checklist boxes are unchecked. Those are yours to fill in — I don't complete them on someone's behalf. Related: the AI Tests section notes that browser verification of the chat preview cards was never captured (the CI web session was stuck on a blank page), so the new 12px radius on those cards is still visually unconfirmed.

---

Next Steps: Reply with @MelvinBot <your feedback> if you want me to retry the web verification of the chat preview cards, or if a different check has gone red since this comment.

---

view run

[shawnborton]

@MelvinBot for the cards in More features, can we make those use 12px border radius as well?

[MelvinBot]

Done — pushed as ebd8477. One line: workspaceSectionMoreFeaturesItem now uses componentBorderRadiusCardAndTable.

Worth knowing: those cards were at 8px, not 16 — they used componentBorderRadiusNormal. So this one is a small step up rather than down like the rest of the PR. The style key has only two consumers, both on the More features page (the card and the invisible grid filler), so nothing else moves. Nothing inside the card is concentric with its corner — every child is inset by the card's 16/20 padding, and the hover highlight is a background on the card itself, so it picks up the new radius for free.

One question for you. onboardingAccountingItem is a byte-for-byte copy of the same card recipe — same cardBG, same 16/20 padding, same componentBorderRadiusNormal. It's the card used for the Onboarding "Accounting" and interested-features steps. Those cards look identical to More features cards today and will now sit at 8 while More features is 12. I left it alone because you asked specifically about More features — say the word and I'll move it too.

Still not verified visually. typecheck passes, lintChanged reports no new violations, and the 26 tests in tests/ui/WorkspaceMoreFeaturesPageTest.tsx pass — but there are no screenshots again.

This is now the third run in a row where the CI web session was unusable, and it's the same failure each time: the prestart onboarding macro diverges on the Skip button of the "What's your work email?" modal (stale ref, complete-onboarding.ad:9), and the browser tab then goes blank and unresponsive. That looks like a bug in the onboarding macro rather than bad luck, and it's worth someone fixing — it's the reason the chat preview cards, the Insights chart cards and now these cards all lack screenshots. The only visual evidence on this PR remains the Android screenshots of the tables and content cards from the first commit.

As before, I couldn't edit the PR description in this environment, so it doesn't mention this commit.

[github-actions]

🚧 shawnborton has triggered a test Expensify/App build. You can view the workflow run here.

[shawnborton]

@Expensify/design can you take this for a spin please? I think I like this, but I just want to make sure we like it enough to keep making progress (we'll have to find all of the cascading effect of nested border radii, etc).

[dubielzyk-expensify]

Works fine to me. I personally think i prefer the desktop radius to be 16px on the home cards, but fine if y'all wanna make it 12 everywhere.

I do think the spacing here becomes a bit extra odd though:

Here it looks great:

[shawnborton]

@MelvinBot pull main and fix any conflicts please

[shawnborton]

I do think the spacing here becomes a bit extra odd though:

In what sense? Not disagreeing, just not sure I'm seeing what Jon is seeing 😆

[MelvinBot]

⚠️ MelvinBot CI Fix Loop Detected

MelvinBot has made 6 consecutive commits trying to fix CI failures. Automatic CI fix dispatches are now paused for this PR.

Next steps: A human should review the recent commits and resolve the conflicting CI errors manually.

[MelvinBot]

Merged main into this branch — no conflicts. Pushed as d584e0f.

main had moved 817 commits ahead, and it merged cleanly. All six of this PR's changes survived the merge intact (no style key this PR touches was moved or renamed on main, and nothing reintroduced the old borderedContentCardLarge name).

AI tests re-run on the merged branch

• npm run typecheck — passed.
• npm run lint-changed — passed.
• npm run react-compiler-compliance-check on the three changed components — passed.
• npm test -- tests/unit/useSearchTableItemHighlightTest.ts tests/unit/useListItemHighlightTest.ts — 12 tests passed.
• npm test -- tests/ui/MoneyRequestReportPreview.test.tsx tests/ui/TransactionPreviewContentTest.tsx tests/ui/FlightTripDetailsTest.tsx tests/ui/ReportActionItemTest.tsx — 256 tests passed.
• npm run gh-actions-unused-styles — passed, no unused styles. This is the one the earlier run couldn't execute, so the borderedContentCardLarge → borderedReportPreviewCard rename is now verified by the script rather than by hand.

One thing still open from before, unchanged by this merge: browser confirmation of the new radius on the chat preview cards was never captured, so that visual check is still outstanding.

---

view run

[github-actions]

🚧 shawnborton has triggered a test Expensify/App build. You can view the workflow run here.

[dannymcclain]

Noticed that on these grouped tables it looks like the top border-radius is still 8px (but the bottom is 12):

To be honest this really doesn't feel all that different to me, so I'm not against moving forward with it to simplify/consolidate.

I do want to know what Jon meant about the spacing thing though haha, because I'm not sure I'm seeing it right either!

[shawnborton]

Good catch on that! @MelvinBot can you make sure the top header row in any tables on Spend (for grouped results, etc) use 12px border radius? Check things like border-top-left radius and border-top-right radius.

[shawnborton]

@dannymcclain @dubielzyk-expensify I would say if no one is really feelin' strongly about this, then we should just close. I think the idea is good on paper but maybe we can table it until we really feel like we need 12px to come into our lives... I do think it feels really nice on the More features page, and I bet it would be nice for places like New Rule for the card-based options.

[MelvinBot]

Fixed and pushed as 7db973b. The header row's top corners were the one table surface the first pass missed.

styles.searchListHeaderTableStyle — the sticky column-header row on Spend — still hardcoded componentBorderRadius (8), while the last row in the table gets styles.tableBottomRadius (now 12). Hence Danny's 8-on-top / 12-on-bottom mismatch. It now uses componentBorderRadiusCardAndTable:

src/styles/index.ts:3902-3910

That single style is the header for every Spend/Search view — expenses (flat), expenses (grouped), Reports, Tasks and Chats all render it through SelectionTopBar:64, so one change covers grouped results and everything else. It's also the header on SearchStaticList (the RHP pickers). The group sub-headers inside an expanded group are transparent and border-less, so they have no corners of their own.

Checks run

• npm run typecheck — passed.
• npx eslint src/styles/index.ts — 28 errors, all pre-existing no-raw-typography / no-unsafe-type-assertion violations elsewhere in the file (nearest is line 3951), none on the two changed lines. npm run lint-changed couldn't run here — its git merge-base step fails in this environment.
• npm run spell-changed src/styles/index.ts — passed.
• npm run gh-actions-unused-styles — passed.

Not verified in a browser: the web session for this run died during sign-in (blank page, zero DOM nodes) and couldn't be recovered, so I never got to read the computed radius off the live table. The change is a variable swap on the one style that draws those corners, but the visual confirmation is still outstanding — same gap I flagged on the merge commit.

One thing worth saying out loud: I saw your follow-up about closing this if nobody feels strongly. This commit is small and self-contained, so it's easy to keep or drop — it doesn't change the close-or-continue call.

---

view run · no recording available

[shawnborton]

@MelvinBot for the Rules revamp beta, when you go to make a new rule, can you use 12px border radius for these options? Find similar options across the app that need to be updated too please

[dannymcclain]

I do think it feels really nice on the More features page

Ah I forgot to check this spot earlier and now that I have, I agree, the extra radius there does feel really nice.

I would say if no one is really feelin' strongly about this, then we should just close. I think the idea is good on paper but maybe we can table it until we really feel like we need 12px to come into our lives...

The only reason I don't feel super strongly about it is because it's such a subtle change—I don't think it impacts the UI all that much in a super tangible way. So to me it's hard to have a strong opinion because the change isn't that strong of a thing? Does that make sense at all? The idea of trying to standardize the border-radius of "card like UI elements" makes perfect sense to me, but at the same time (to argue against myself hahah), our current border radii don't feel overtly broken to me as is. 😵‍💫 🤷

[MelvinBot]

Done — pushed as 9d2b98e. The New rule cards are 12px now, and I found five other screens using that same card-option pattern.

The New rule page's cards come from styles.rulesNewMenuItem, which hardcoded borderRadius: 8. It has a near-identical sibling, styles.purposeMenuItem (also a hardcoded 8), plus two onboarding grid variants on the componentBorderRadiusNormal token. All four are the same thing visually: cardBG fill, icon/illustration, bold title, and a stack or grid of them. They now all use componentBorderRadiusCardAndTable.

Screens this changes:

Screen	Style
New rule ("What do you want to do?")	rulesNewMenuItem
Apply expense defaults type picker	rulesNewMenuItem
New rule → Agent → Suggestions tab	inline (see below)
Onboarding "What do you want to do today?"	purposeMenuItem
Onboarding personal track goal	purposeMenuItem
Issue new Expensify Card → Physical / Virtual	purposeMenuItem
Wallet → "What do you want to do with your bank account?"	purposeMenuItem
Onboarding "Which accounting software do you use?"	onboardingAccountingItem
Onboarding "interested features"	onboardingInterestedFeaturesItem

The Expensify Card type step and the bank-account purpose page are the closest twins of your screenshot — illustration + title + description + chevron, in a stack.

The agent-rule suggestion cards composed their radius inline from styles.borderRadiusComponentNormal, a generic 8px utility used by unrelated things, so I couldn't just retarget it. I added a matching styles.borderRadiusComponentCardAndTable utility next to the existing Normal / Large ones and pointed AddAgentRuleSuggestionsTab:146 at it.

Three option-card sets I deliberately left alone — your call

• Workspace → More features (workspaceSectionMoreFeaturesItem) is already 12px. That's the page you said felt really nice, and it's why the new cards should match it.
• Subscription "Annual / Pay-per-use" and Compare plans cards are outlined rather than filled, and they route through styles.borderedContentCard, which eight-plus unrelated surfaces also use. Retargeting it would sweep well past option cards.
• Settings → Agents → New agent template cards sit at 16px via the generic borderRadiusComponentLarge utility — same situation, and they're arguably content cards with an "Add" button rather than a one-of-N picker.

Also worth knowing: styles.sectionMenuItem is the most-used rounded MenuItem wrapper in the repo (Settings, Workspace and Domain initial pages, Search menus) and hardcodes borderRadius: 8, but it has no background — the corners only show on hover. If "cards everywhere" becomes the direction, that's the big one.

Checks run

• npm run typecheck — passed.
• npm test -- tests/ui/AddAgentRuleSuggestionsTabTest.tsx tests/ui/OnboardingPurpose.tsx tests/ui/OnboardingPersonalTrackGoal.tsx tests/ui/OnboardingAccountingAndInterestedFeatures.tsx — 27 tests passed across 4 suites.
• npm run gh-actions-unused-styles — passed, so the new utility is genuinely consumed.
• npm run spell-changed — passed.
• npx eslint on both changed files — 28 errors, all pre-existing no-raw-typography violations elsewhere in src/styles/index.ts, none on the changed lines.
• npm run react-compiler-compliance-check check on the changed component — passed.
• lint-changed and react-compiler-compliance-check check-changed both fail their git merge-base step in this environment, so I ran the underlying tools directly instead.

Not verified in a browser: the web session died during sign-in again this run (blank page, zero DOM nodes, same broken onboarding replay as before), so I couldn't read the computed radius off the live New rule page. Every screen above is driven by the four styles in the diff, but the visual check is still outstanding.

---

view run · no recording available

[github-actions]

🚧 shawnborton has triggered a test Expensify/App build. You can view the workflow run here.

[github-actions]

🧪🧪 Use the links below to test this adhoc build on Android, iOS, and Web. Happy testing! 🧪🧪
Built from App PR #101466.

Android 🤖	iOS 🍎
https://ad-hoc-expensify-cash.s3.us-east-1.amazonaws.com/rock-artifacts/ad-hoc/rock-android-Adhoc-9d2b98e-fed6c2d-d1c1330bd22f41f8d0408646643ad78eb8e1d09f/index.html	https://ad-hoc-expensify-cash.s3.us-east-1.amazonaws.com/rock-artifacts/ad-hoc/rock-ios-device-AdHoc-9d2b98e-fed6c2d-d401a6a1079ccbd59089b83afcc11bdf953071ef/index.html

Web 🕸️
https://101466.pr-testing.expensify.com

---

👀 View the workflow run that generated this build 👀